Agreed. Thanks, Ken
>-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf >Of Jack Kohn >Sent: Wednesday, December 16, 2009 3:33 PM >To: Russ Housley >Cc: [email protected]; [email protected] >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 <[email protected]> >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
