[IPsec] Relating the two ESP-null documents

Yaron Sheffer <yaronf@checkpoint.com> Tue, 11 August 2009 13:04 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CECDD3A70E9 for <ipsec@core3.amsl.com>; Tue, 11 Aug 2009 06:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7bb6quni3J0 for <ipsec@core3.amsl.com>; Tue, 11 Aug 2009 06:04:47 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 169203A715D for <ipsec@ietf.org>; Tue, 11 Aug 2009 06:04:42 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E1C2F29C02D; Tue, 11 Aug 2009 16:04:08 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9B44229C008 for <ipsec@ietf.org>; Tue, 11 Aug 2009 16:04:08 +0300 (IDT)
X-CheckPoint: {4A816A2E-0-14201DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n7BD3l3d002403 for <ipsec@ietf.org>; Tue, 11 Aug 2009 16:03:47 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 11 Aug 2009 16:03:47 +0300
From: Yaron Sheffer <yaronf@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: Tue, 11 Aug 2009 16:03:44 +0300
Thread-Topic: Relating the two ESP-null documents
Thread-Index: AcoaCU7flAIQ2SPQSLGtPDsGLRShMgAO5ZnQAA+IIRA=
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80158E120A922@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00BC_01CA1A9D.4D8B6890"
MIME-Version: 1.0
Subject: [IPsec] Relating the two ESP-null documents
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2009 13:04:47 -0000

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