We agree, and tried to capture that in the current version at: http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-02
with text such as: Next Header, 8 bits: If using ESP-NULL, this field MUST be equal to the Next Header field in the ESP trailer. If using ESP in encryption mode, this field MUST be set to zero.. and in the security considerations section: ESP is end-to-end and it will be impossible for the intermediate devices to verify that all the fields in the WESP header are correct. It is thus possible to tweak the WESP header so that the packet sneaks past the firewall if the fields in the WESP header are set to something that the firewall will allow. The endpoint thus must verify the sanity of the WESP header before accepting the packet. In an extreme case, someone colluding with the attacker, could change the WESP fields back to the original values so that the attack goes unnoticed. However, this is not a new problem and it already exists IPSec. Perhaps we need more details on what exactly we mean by "the endpoint thus must verify the sanity of the WESP header before accepting the packet"? And the action to drop the offending packet? ----- Original Message ---- > From: Stephen Kent <k...@bbn.com> > To: "Bhatia, Manav (Manav)" <ma...@alcatel-lucent.com> > Cc: "ipsec@ietf.org" <ipsec@ietf.org>; gabriel montenegro > <g_e_montene...@yahoo.com>; Tero Kivinen <kivi...@iki.fi> > Sent: Tuesday, May 12, 2009 8:18:18 AM > Subject: Re: [IPsec] Next Header field in WESP header > > If we elect to keep the next header field, to help middle boxes quickly > locate > header fields of interest to them, then we MUST require the recipient of each > message to do a (well-defined) consistency check on the packet, for the > reasons > I cited in SF. > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
