Hi, On Mon, Jan 4, 2010 at 11:27 PM, Yaron Sheffer <yar...@checkpoint.com>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? > Motivations for including the WESP header in the ICV calculation were to counter WESP header modifications. An alternative is to explicitly check WESP header fields. On my opinion both are fine. Checking WESP's header values makes WESP to be a Wrapper that do not change ESP. If this design issue makes implementation easier, that's even better. I may not understand all discussions on transition from ESP to WESP, and still consider WESP and ESP as two distinct protocols designed for different purposes. So my answer is YES I 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? > As mentioned above WESP and ESP have been designed for two different purposes. ESP has been designed for end-to-end communications, WESP is based on ESP but has been designed to provide traffic visibility to middle boxes. One scenario considers bypassing ESP_NULL traffic and discarding -or having different policies -- for encrypted and/or unspecified traffic. This means that targeted traffic is ESP_NULL. Traffic management may also target NON_NULL_ESP traffic. If a node has multiple interfaces it can choose to forward NON_NULL_ESP traffic on a non-protected network, and has different policies for the rest of the traffic. We (Orange) do request, for traffic management purpose, that flows can explicitly specify whether they are encrypted or not-encrypted. The WESP header seems to me the proper place for that specification. We are not considering WESP as ESPv4, but we think that WESP (resp. ESP) will be used because WESP (resp. ESP) traffic will have better QoS then ESP. This will mainly depend on security and traffic management policies. So here again my answer is YES I support this design decision. Regards, Daniel > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
