[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
- [IPsec] Relating the two ESP-null documents Yaron Sheffer
- Re: [IPsec] Relating the two ESP-null documents Grewal, Ken
- Re: [IPsec] Relating the two ESP-null documents Bhatia, Manav (Manav)
- [IPsec] Relating the two ESP-null documents Tero Kivinen
- Re: [IPsec] Relating the two ESP-null documents Yaron Sheffer
- Re: [IPsec] Relating the two ESP-null documents Paul Hoffman
- Re: [IPsec] Relating the two ESP-null documents Tero Kivinen