Yes to both. To elaborate on what Ken said, here's an explicit scenario that requires the encrypted bit for WESP, fully within the current charter of enabling ESP-NULL inspection.
Transport policies for within an organization that want to enable intermediary inspection of ESP-NULL non-heurisitically. Organization has a mix of version of systems. Sample policy: When talking to/from non-WESP capable machines: must do ESP-NULL only When both peers are WESP capable: do WESP/ESP-NULL most places. However, where policy requires encryption, do WESP/ESP. Only with the WESP encrypt bit can intermediaries distinguish what is going on here, and still enable the uplevel systems to do full encryption where needed. I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then they must leverage the encrypt bit to see what to do. Hence we need to keep the encrypted bit to satisfy the current WESP charter item. bs -----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
