Hi, No and no.
I'm a little alarmed at the assumption by some that ESP would be deprecated (albeit "not for a long time"). AH does not really solve the problem supposedly solved by WESP because it doesn't work through a NAT. So if we're going to have a new protocol that needs to be implemented by end points why not just make a NAT-friendly version of AH and forget the whole idea of "wrapping" ESP packets. That would be architecturally cleaner, in my opinion. If you want to provide traffic visibility then negotiate <new protocol> for the traffic that is being protected, if you don't then negotiate ESP. And if ESP-NULL poses a problem for you then prohibit it by policy. Dan. On Mon, January 4, 2010 2:27 pm, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to > WG discussion. Well reasoned answers are certainly appreciated. But plain > "yes" or "no" would also be useful in judging the group's consensus. > > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. This > has been done to counter certain attacks, but it means that WESP is no > longer a simple wrapper around ESP - ESP itself is modified. Do you > support this design decision? > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. > But arguably, it positions WESP as an alternative to ESP. Do you support > this design decision? > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
