Some comments inline... <snip>
>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. [Ken] I do not think that checking one more bit adds too much additional complexity, compared with extracting the offsets and protocol Information from the header. It does provide compatibility for both encrypted and unencrypted traffic. If we add more extensions to WESP, then those need to be evaluated based on the cost / complexity Vs. benefit and that will be a separate debate. <snip> >ESP is extensible, but it just requires out of band communication to >negotiate those extensions. We currently already have ESP extensions >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. > [Ken] I think this is the whole point. All the work on ESP/IPsec this far has been considering a two party interaction (outside the multicast context!). Now there is a third party - the middle box, which would like to gain some additional information in order to provide valuable network services. The end boxes already know what is being negotiated, so just making changes to IKE to add additional capability is insufficient in certain scenarios (while perfectly sufficient in others). We need to provide additional information in the data path, hence the need for WESP. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
