Hi Russ, > > - A standards-track mechanism that allows an intermediary > device, such > > as a firewall or intrusion detection system, to easily and reliably > > determine whether an ESP packet is encrypted with the NULL > cipher; and > > if it is, determine the location of the actual payload > data inside the > > packet. The starting points for this work item are > > draft-grewal-ipsec-traffic-visibility and > draft-hoffman-esp-null-protocol. > > I think the chartering discussion would have been very > different had the > charter said that the proposed WG would develop an alternative to ESP.
I don't think WESP is in any sense an alternative to ESP and I believe we did stick to the charter, which was to provide a *deterministic* way to disambiguate different ESP packets. I understand that the word "deterministic" is missing from the charter text, but it was obvious to everyone working in IPSec that WESP was to be a *deterministic* solution. Now, assume that we limit WESP for only ESP-NULL. If this is done, how can a middle box deterministically know that the ESP packet that it sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL payload. The middleboxes will now be forced to apply heuristics just to be sure that the packet is indeed an encrypted ESP packet. This would defeat the purpose of having WESP in the network. So, when including the encryption bit in the WESP header we never thought that it was out of the charter (as others have also noted in the mailing list) as it was really being used to provide a deterministic answer to whether the packet was encrypted or not. We really don't have a complete solution if we don't include the encryption bit in the WESP header. Cheers, Manav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
