Re: [IPsec] Traffic visibility - consensus call
"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 06 January 2010 01:56 UTC
Return-Path: <manav.bhatia@alcatel-lucent.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 EFFF23A67E1 for <ipsec@core3.amsl.com>; Tue, 5 Jan 2010 17:56:53 -0800 (PST)
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 3Q1qmYnJURi4 for <ipsec@core3.amsl.com>; Tue, 5 Jan 2010 17:56:53 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 1A7063A657C for <ipsec@ietf.org>; Tue, 5 Jan 2010 17:56:52 -0800 (PST)
Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o061uokG006983; Tue, 5 Jan 2010 19:56:50 -0600 (CST)
Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o061umvB007094; Tue, 5 Jan 2010 19:56:49 -0600 (CST)
Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id o06273CM027276; Wed, 6 Jan 2010 10:07:03 +0800
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 6 Jan 2010 07:26:46 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Russ Housley <housley@vigilsec.com>, gabriel montenegro <g_e_montenegro@yahoo.com>
Date: Wed, 06 Jan 2010 07:26:43 +0530
Thread-Topic: [IPsec] Traffic visibility - consensus call
Thread-Index: AcqOS6cAX0GumPDsRfmRZZ6tSIZRugAIxz7w
Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB33FDDD8@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A844@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com> <C49B4B6450D9AA48AB99694D2EB0A48361A819C5@rrsmsx505.amr.corp.intel.com> <378834.93787.qm@web82602.mail.mud.yahoo.com> <4B43AAF7.8030302@vigilsec.com>
In-Reply-To: <4B43AAF7.8030302@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28
X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Traffic visibility - consensus call
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: Wed, 06 Jan 2010 01:56:54 -0000
Hi Russ, > > - A standards-track mechanism that allows an intermediary > device, such > > as a firewall or intrusion detection system, to easily and reliably > > determine whether an ESP packet is encrypted with the NULL > cipher; and > > if it is, determine the location of the actual payload > data inside the > > packet. The starting points for this work item are > > draft-grewal-ipsec-traffic-visibility and > draft-hoffman-esp-null-protocol. > > I think the chartering discussion would have been very > different had the > charter said that the proposed WG would develop an alternative to ESP. I don't think WESP is in any sense an alternative to ESP and I believe we did stick to the charter, which was to provide a *deterministic* way to disambiguate different ESP packets. I understand that the word "deterministic" is missing from the charter text, but it was obvious to everyone working in IPSec that WESP was to be a *deterministic* solution. Now, assume that we limit WESP for only ESP-NULL. If this is done, how can a middle box deterministically know that the ESP packet that it sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL payload. The middleboxes will now be forced to apply heuristics just to be sure that the packet is indeed an encrypted ESP packet. This would defeat the purpose of having WESP in the network. So, when including the encryption bit in the WESP header we never thought that it was out of the charter (as others have also noted in the mailing list) as it was really being used to provide a deterministic answer to whether the packet was encrypted or not. We really don't have a complete solution if we don't include the encryption bit in the WESP header. Cheers, Manav
- [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Yoav Nir
- Re: [IPsec] Traffic visibility - consensus call Scott C Moonen
- [IPsec] Traffic visibility - consensus call Tero Kivinen
- Re: [IPsec] Traffic visibility - consensus call Dan McDonald
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Grewal, Ken
- Re: [IPsec] Traffic visibility - consensus call gabriel montenegro
- Re: [IPsec] Traffic visibility - consensus call Paul Hoffman
- Re: [IPsec] Traffic visibility - consensus call gabriel montenegro
- Re: [IPsec] Traffic visibility - consensus call Paul Hoffman
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Mark Vondemkamp
- Re: [IPsec] Traffic visibility - consensus call Russ Housley
- Re: [IPsec] Traffic visibility - consensus call gabriel montenegro
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Russ Housley
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Joseph Tardo
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Bhatia, Manav (Manav)
- Re: [IPsec] Traffic visibility - consensus call gabriel montenegro
- Re: [IPsec] Traffic visibility - consensus call Zhen Cao
- Re: [IPsec] Traffic visibility - consensus call Venkatesh Sriram
- Re: [IPsec] Traffic visibility - consensus call Scott C Moonen
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Dragan Grebovich
- Re: [IPsec] Traffic visibility - consensus call Russ Housley
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Paul Hoffman
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Paul Hoffman
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- [IPsec] What problem are we REALLY trying to solv… Dan McDonald
- Re: [IPsec] Traffic visibility - consensus call Dan Harkins
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Scott C Moonen
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Grewal, Ken
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Paul Koning
- Re: [IPsec] Traffic visibility - consensus call Bill Sommerfeld
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Nicolas Williams
- Re: [IPsec] Traffic visibility - consensus call Grewal, Ken
- [IPsec] Traffic visibility - consensus call Sanchez, Mauricio (ProCurve)
- Re: [IPsec] Traffic visibility - consensus call Dan Harkins
- Re: [IPsec] Traffic visibility - consensus call Joy Latten
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Grewal, Ken
- Re: [IPsec] Traffic visibility - consensus call Grewal, Ken
- Re: [IPsec] Traffic visibility - consensus call Dan Harkins
- Re: [IPsec] Traffic visibility - consensus call Charlie Kaufman
- Re: [IPsec] Traffic visibility - consensus call Yoav Nir
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Daniel Migault
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Grewal, Ken
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Dan Harkins
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- [IPsec] Traffic visibility - what are the assumpt… Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Yaron Sheffer
- Re: [IPsec] Traffic visibility - consensus call Dan Harkins
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent
- Re: [IPsec] Traffic visibility - consensus call Jack Kohn
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Joseph Tardo
- Re: [IPsec] Traffic visibility - consensus call Tero Kivinen
- Re: [IPsec] Traffic visibility - consensus call Tero Kivinen
- Re: [IPsec] Traffic visibility - consensus call Nicolas Williams
- Re: [IPsec] Traffic visibility - consensus call Brian Swander
- Re: [IPsec] Traffic visibility - consensus call Min Huang
- Re: [IPsec] Traffic visibility - consensus call Pasi.Eronen
- Re: [IPsec] Traffic visibility - consensus call Bhatia, Manav (Manav)
- Re: [IPsec] Traffic visibility - consensus call Dan Harkins
- Re: [IPsec] Traffic visibility - consensus call Bhatia, Manav (Manav)
- Re: [IPsec] Traffic visibility - consensus call Dan Harkins
- Re: [IPsec] Traffic visibility - consensus call Grewal, Ken
- Re: [IPsec] Traffic visibility - consensus call Stephen Kent