Yaron Sheffer writes: > I agree with you regarding some of the proposals that have been > floating around re: exposing bits and pieces of encrypted data.
I am really concerned about some of those late proposals for WESP extensions, and if someone would have mentioned any of those earlier when we were discussing whether WESP should allow encrypted ESP also, I would have been even more against allowing encrypted WESP. > I disagree though that WESP should not be used for encrypted data: > > - It is simpler for implementations and architecturally cleaner for > WESP to support both flavors. It does make more complexity for the middle boxes as they need to cope with both encrypted WESP and ESP-NULL WESP, thus they still cannot use just the WESP protocol number to indicate this packet is clear text. Now they also need to check the bit in the header, and if we add more extensions to WESP, they need to start doing even more processing etc, and quite soon WESP is more complex than what AH is now. > - WESP provides for (secure) extensibility, which unfortunately we > have not had with ESP. Indeed we should be wise about picking such > extensions. ESP is extensible, but it just requires out of band communication to negotiate those extensions. We currently already have ESP extesions like extended sequence numbers (ESN), Explicit Congestion Notification (ECN), Traffic Flow Confidentiality (TFC), and Combined mode algorithms. Those were added after initial ESP was created, and they are negotiated using IKEv2 (or some other method). ESP does not offer extensibility that can be done without out of band communication, and as that out of band communication is normally encrypted (inside IKEv2) that means middle boxes cannot process it. I do not think WESP should be used as generic extensible ESP. That was not what the ipsecme wg was chartered to do. We were chartered to do: - 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
