Bhatia, Manav (Manav) writes: > Yes, this was discussed in the WG > (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea > was this: > > We could have some malicious entity that could modify the offsets to > ensure that the intermediaries don't parse a portion of the payload > (which could contain malicious content) or inspect it differently > than what it would have done otherwise. A way to protect against > such attacks is to let the end node validate the WESP header by > including this as a part of the ESP ICV. If the computed ICV does > not match, the packet is dropped (usual IPSec processing).
As all current fields in the WESP header for ESP-NULL traffic is already verified by the recipient to be matching their authenticated values, there is no need to extend ESP ICV to cover WESP header. Fo example the Next Header field in the WESP header is copy of the Next Header field in the ESP header, and the current draft already mandates that "The receiver MUST ensure that the Next Header field in the WESP header and the Next Header field in the ESP trailer match when using ESP in the Integrity only mode. The packet MUST be dropped if the two do not match." This same goes with HdrLen and TrailerLen etc fields. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
