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 <hous...@vigilsec.com> 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
