Brian Swander writes: > 0 - option data does not change en-route. This option is > included in the WESP ICV computation. > > We'll be using this flag, so this option will always be integrity > protected.
One of the things that disturb me here is that AH was not acceptable because of the complexity and because it didn't go through NATs, and now we are thinking of adding lots of complexity to the WESP (perhaps even more than what AH had by looking at some of the discussion). Perhaps it would be better to go back and say use AH instead, at least for that we would have some implementations and even when there is perhaps much less testing done on the AH than to ESP, it has still lots of more testing and experience than what we have from WESP... I still think that extending WESP in any ways is very bad idea, and if it is to be done, we need to first start from the exact scenarios where those extensions are needed, not make any generic framework or protocol document before we know what problems we are solving. This same thing was problematic for WESP. I am still not sure what problem we are solving, even when I am author of the another draft solving same "problems" than WESP. Every time someone starts discussing about the problems, it seems the problem is completely different... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
