> > Do you support [the decision to include the WESP header in the ICV > > calculation]? > > . . . > > Do you support [the decision to allow the use of WESP for encrypted > > ESP flows]? > > Yes to both. > > Regardless of what the original work item specified, WESP as it is now > is an alternative to ESP. In the long run it makes no sense to have > them both, so one will get obsoleted (just as AH is getting there). > > I see no benefit in crippling WESP to either keep the old ESP > unchanged or to keep some functionality (like encryption) as ESP-only.
No to both, considering the initial scope of what this was trying to do. I don't think we have warrant for inventing a complete replacement to ESP and I haven't yet seen any hypothetical proposals for the use of WESP that convince me there is a strong case for scuttling and replacing ESP. However, if the ayes have it, then I think two things are advisable. First, it would be wise to rewind the clock a bit and think about designing a cleaner WESP. WESP would look different if it had started out as a complete replacement for ESP. (For example, we've missed the opportunity to move the encrypted protocol byte up to the front.) Second, because there is a deep divide over whether a full-featured WESP has value or will be embraced, it may be wise to change this from a standards-track document to an individual draft or to experimental. Alternatively, we could really rewind the clock and try to establish real warrant and consensus for a complete replacement to ESP. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir <y...@checkpoint.com> To: Yaron Sheffer <yar...@checkpoint.com> Cc: "ipsec@ietf.org" <ipsec@ietf.org> Date: 01/05/2010 02:56 AM Subject: Re: [IPsec] Traffic visibility - consensus call On Jan 5, 2010, at 12:27 AM, 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 Yes to both. Regardless of what the original work item specified, WESP as it is now is an alternative to ESP. In the long run it makes no sense to have them both, so one will get obsoleted (just as AH is getting there). I see no benefit in crippling WESP to either keep the old ESP unchanged or to keep some functionality (like encryption) as ESP-only. _______________________________________________ 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
