Grewal, Ken writes: > >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.
But without adding even more extensions there is no reason to ever use encrypted WESP instead of ESP. WESP just adds extra header without any benefit compared to normal encrypted ESP. > 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. The question is how many extensions we have which are such that they need to be understood by the middle boxes. Extensions for the end hosts can be done using standard ESP. > [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!). Yes, I and I think IPsec will stay that way... For example I do not think our OEM toolkit will include WESP as I do not really see any need for it. > 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. I am not sure WESP is right solution for that problem. It would be much better to provide authenticated protocol where the middlebox could connect to the end node and query the required parameters from the end node and the end node can give that information out without needing to waste extra bytes on each packet. Also that way end node could control who gets the information and who does not. There is no need that additional information needs to be on the data path, and in clear text, it could also be communicated using some other out of band method instead of WESP. Depending on what kind of additional information needs to be transmitted, the solutions can be quite different. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
