Works for me too! Cheers, Manav
> -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Grewal, Ken > Sent: Tuesday, August 18, 2009 10.03 PM > To: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Relating the two ESP-null documents > > Works for me! > > Thanks, > - Ken > > > >-----Original Message----- > >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf > >Of Yaron Sheffer > >Sent: Tuesday, August 11, 2009 6:04 AM > >To: ipsec@ietf.org > >Subject: [IPsec] Relating the two ESP-null documents > > > >Hi, > > > >As we near publication of the WESP and Heuristics drafts, > we'd like to > >make > >sure that the WG consensus is clearly expressed in both > documents. So we > >propose to include the following note as a section in both documents. > >Please > >let us know if this works for you: > > > >-- begin text > > > >Applicability: Heuristic Traffic Inspection and Wrapped ESP > >----------------------------------------------------------- > > > >There are two ways to enable intermediate security devices to > >distinguish > >between encrypted and unencrypted ESP traffic: > > > >- The heuristics approach [heuristics I-D] has the intermediate node > >inspect > >the unchanged ESP traffic, to determine with extremely high > probability > >whether or not the traffic stream is encrypted. > > > >- The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP > >endpoints to be modified to support the new protocol. WESP allows the > >intermediate node to distinguish encrypted and unencrypted traffic > >deterministically, using a simpler implementation for the > intermediate > >node. > > > >Both approaches are being documented simultaneously by the IPsecME > >Working > >Group, with WESP being put on Standards Track while the heuristics > >approach > >is being published as an Informational RFC. While endpoints are being > >modified to adopt WESP, we expect both approaches to coexist > for years, > >because the heuristic approach is needed to inspect traffic where at > >least > >one of the endpoints has not been modified. In other words, > intermediate > >nodes are expected to support both approaches in order to > achieve good > >security and performance during the transition period. > > > >-- end text > > > >[Note: both references are non-normative.] > > > >Currently both documents have direct or indirect references to one > >another, > >but they are not exactly in line with the consensus we have > reached. In > >both > >cases the emphasis is on the two solutions competing with > one another, > >rather than complementing each other. > > > >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
