Yes to both, based on arguments already discussed numerous times in the WG via presentations, 12 iterations of the draft and multiple WG last calls + AD reviews!
The main motivation for extending the ICV was to counter some of the issues originally raised by Steve Kent - malicious entities modifying portions of the WESP header to bypass legitimate parsing of the packet by Trusted Intermediary (TI) devices such as IDS/IPS/etc. This can be addressed by the recipient explicitly validating the WESP header before accepting the packet or implicitly by including the WESP header as part of the ICV check. The motivation for allowing WESP to be used for encrypted data was brought up as a consistency argument and also allows for future extensibility in a uniform manner. I agree that this was not part of the original charter, as shown in the earlier revisions of the WESP drafts. BUT, this was discussed numerous times within the WG (including an open ticket on scope) and it was agreed that this would be a useful bit to include in the flags, hence introduced in the latter revisions of the draft. Note that this does not mandate using WESP for encrypted traffic, but allows it as optional and can be dictated as part of the session setup based on local policy. Another benefit may be that in running mixed mode environments (encrypted + ESP_NULL traffic), it allows for an explicit distinction from the packet that certain traffic is encrypted and other traffic is not. Otherwise, one would use ESP and WESP in these mixed mode environments and to be absolutely sure if ESP traffic is encrypted or not, would need to fall back to heuristics, which somewhat defeats the object of having this spec. I am certainly not a fan of heuristics, as it is complex, non-deterministic, will require updates for new algorithms added into ESP, as well as other arguments already cited numerous times, so would like to see a consistent deterministic way to identify the traffic. Thanks, - Ken >-----Original Message----- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >Of Yaron Sheffer >Sent: Monday, January 04, 2010 2:27 PM >To: ipsec@ietf.org >Subject: [IPsec] Traffic visibility - consensus call > >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
