As I recall, folks expressed that if one were to use WESP for ESP-NULL, it would be good to be able to use it for encryption as well to be able to use a consistent packet format.
This was issue 84: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/84 Discussed at IETF 74 and 75 as well as on the list: http://tools.ietf.org/wg/ipsecme/minutes?item=minutes74.html http://tools.ietf.org/wg/ipsecme/minutes?item=minutes75.html And (just saw Jack's other message), yes "wrapped" does not correctly describe it any more given changes to the ICV calculation. Gabriel ----- Original Message ---- > From: Jack Kohn <[email protected]> > To: Russ Housley <[email protected]> > Cc: [email protected]; [email protected] > Sent: Wed, December 16, 2009 3:33:14 PM > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > My two bits on this and I'll let the authors/chairs explain in detail .. > > On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley wrote: > > Discuss: > > The primary motivation for this work is to allow a middlebox to peek > > into integrity protected (but not encrypted) IPsec packets. Some > > integrity-check algorithms use an IV, a middlebox cannot alway know > > where the payload starts. Unlike the IPsec peer that negotiated the > > algorithm in the IKE exchange, the middlebox does not know which > > integrity-check algorithm is in use, and thus doe s not know if an IV > > is present or how long it might be. > > > > The document allows the encapsulation of encrypted IPsec traffic. > > Why? I cannot see the justification for the use if WESP at all if > > the IPsec traffic is encrypted. > > This was discussed and i think the idea was not to limit WESP for just > ESP-NULL. One does not lose anything by defining WESP for encrypted > packets (besides the additional bytes in the header). However, by > keeping provisions for this, we are free to define other extensions > which might later work for encrypted packets. > > I think its a good idea to keep WESP flexible and see how it evolves > in the wild. In the worst case, no one would use it for encrypted > packets .. > > Jack > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
