Yes and Yes. I supported WESP from the beginning, because it allows intermediate systems to perform DPI on ESP-NULL packets. I was not in favor of heuristics - not because it is a bad solution (on the contrary) - but because many products we have/make today could not be upgraded to support it. Manav gave an excellent summary the other day.
I also view that the extensibility of the protocol as it stands in the WESP today allows a smooth evolution path for fixing an obvious problem and allowing support of new services. I would not deprecate ESP for a long time because there is a wide customer base that cannot be ripped out. I would work within the present charter, if possible. If it takes a new charter to codify ESPv4, I am fine with that too, and let's use WESP as a base. There is always going to be equipment mix of multiple vintages and capabilities. Systems capable of supporting (extensible) WESP should be able to take advantage of that. Some systems may not be able to support encrypted WESP and would work with ESP-NULL only. Legacy systems (non-WESP capable) must be able to perform as they do today (ignoring WESP packets and forwarding them uninspected). Dragan -----Original Message----- Date: Tue, 5 Jan 2010 00:27:26 +0200 From: Yaron Sheffer <yar...@checkpoint.com> Subject: [IPsec] Traffic visibility - consensus call To: "ipsec@ietf.org" <ipsec@ietf.org> 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
