Hi Tero, Thanks for approving this text. I was expecting each draft's editor team to decide where to add it into their draft.
Best,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:[email protected]]
> Sent: Monday, August 24, 2009 15:51
> To: Yaron Sheffer
> Cc: [email protected]
> Subject: [IPsec] Relating the two ESP-null documents
>
> Yaron Sheffer writes:
> > 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:
>
> I think that applicability statement is good, and acceptable.
>
> Sorry about the delay for answering, but I wanted to re-read the
> draft-ietf-ipsecme-traffic-visibility draft once more before answering
> (my comments to it will follow).
>
> > 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.
>
> So would this text be added to both documents or what? If so where
> (between section 2 and 3 in esp-null-heuristics and after or replacing
> section 1.2 of traffic-visibility draft)?
> --
> [email protected]
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
