Yes to both questions. But I'd also like to question the process being followed. We've discussed these points numerous times in f2f meetings, on the mailing list, at virtual interims, etc. So I'm surprised to see the already established consensus being questioned all over again. Some of the arguments claim lack of attention, whereas they have been intense and prolific discussions on WESP, and thankfully so (e.g., including but not limited to spawning of Tero's heuristics draft and the motivation for the modified ICV coverage to address Steve's comment). But even if folks had not paid attention, that is no excuse for derailing the process. I disagree that WESP encryption is out of scope. It certainly is. There is a need per the charter for a mechanism to "easily and reliably" determine the type of traffic. Within an organization, it would be much easier to use WESP encryption as an alternative to ESP. If one sees ESP packets, then one would have to run heuristics with all the pertaining issues as explained in Manav's recent message, and higher cost associated (particularly, in stateless high aggregation points). WESP with encryption support would allow an organization to simplify rules and inspection devices. Sure, the WESP header adds more bytes, but the tradeoff is that there is no need for costly heuristics throughout the network. Without WESP encryption, the charter item does not have a complete solution. Just to be clear: I'm not saying that WESP is a general replacement for ESP. As Steve Kent points out, where there are no trusted intermediary inspection devices (i.e., outside of medium to large organizations) there is no need for end-nodes to collaborate with the inspecting infrastructure, hence no need for WESP. ESP is fine. Perhaps this is the disconnect that is happening: traditionally, the focus of the IPsec WG has been on such external applications (VPN), whereas WESP and future potential extensibility is more valuable within organizations. Such value may not be as obvious to VPN folks. Gabriel
----- Original Message ---- > From: "Grewal, Ken" <ken.gre...@intel.com> > To: Yaron Sheffer <yar...@checkpoint.com>; "ipsec@ietf.org" <ipsec@ietf.org> > Sent: Tue, January 5, 2010 10:14:43 AM > Subject: Re: [IPsec] Traffic visibility - consensus call > > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
