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. The document says: > > ... by preserving the body of the existing ESP packet format, a > compliant implementation can simply add in the new header, without > needing to change the body of the packet. > The figures in Section 2.2.1 and 2.2.2 show otherwise. The ESP ICV is replaced by a WESP ICV. ESP processing is changed, and I cannot see the justification for it. This is explained by: > > In the diagrams below, "WESP ICV" refers to the ICV computation as > modified by this specification. Namely, the ESP ICV computation is > augmented to include the four octets that constitute the WESP header. > Otherwise, the ICV computation is as specified by ESP [RFC4303]. > So, in fact, WESP is not an optional encapsulation of ESP. It is an alternative to ESP with some duplicated fields (such as Next Header) and pointers into the actual integrity-protected payload. When talking about IKEv2 negotiation, the document says: > > The notification, USE_WESP_MODE (value TBD) MAY be included in a > request message that also includes an SA payload requesting a > CHILD_SA using ESP. > USE_WESP_MODE MUST be included if one wants to use WESP, right? The use of MAY here leads me to think that there are other ways to select the use of WESP in the IKEv2 exchange. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
