IETF Logo Mail Archive

[IPsec] Traffic visibility - consensus call

"Sanchez, Mauricio (ProCurve)" <mauricio.sanchez@hp.com> Thu, 07 January 2010 00:04 UTC

Return-Path: <mauricio.sanchez@hp.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 58E4C3A683F for <ipsec@core3.amsl.com>; Wed, 6 Jan 2010 16:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Fg17rT7AIJdH for <ipsec@core3.amsl.com>; Wed, 6 Jan 2010 16:04:01 -0800 (PST)
Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 5F5FA3A659C for <ipsec@ietf.org>; Wed, 6 Jan 2010 16:04:01 -0800 (PST)
Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 8B1983868D for <ipsec@ietf.org>; Thu, 7 Jan 2010 00:03:59 +0000 (UTC)
Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jan 2010 00:03:20 +0000
Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 7 Jan 2010 00:03:20 +0000
From: "Sanchez, Mauricio (ProCurve)" <mauricio.sanchez@hp.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: Thu, 07 Jan 2010 00:03:18 +0000
Thread-Topic: [IPsec] Traffic visibility - consensus call
Thread-Index: AcqOAg6CNa7TzR2bQzOucpln3vnudwBKeuCA
Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C51B3D6A20C@GVW0671EXC.americas.hpqcorp.net>
References: <mailman.172.1262694268.4832.ipsec@ietf.org>
In-Reply-To: <mailman.172.1262694268.4832.ipsec@ietf.org>
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
Subject: [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: Thu, 07 Jan 2010 00:04:02 -0000

Responding to Yaron's request for group input on two questions pertaining to WESP draft

On question #1 (ICV calculation): I don't agree with design decision to include WESP header in ESP trailer's ICV.  I see it as unnecessary contamination of ESP protocol.  

On question #2 (Allowing WESP as alternative to ESP):  I support this design choice. On the whole I feel that the functionality described for WESP, even when perceived as an alternative to ESP,  is a step in the right direction for supporting several key use cases for us.  

Cheers,
MS

-------------------------------------------- 
Mauricio Sanchez
Chief Security Architect

HP ProCurve Networking
Hewlett-Packard
8000 Foothills Blvd.
M/S 5541
Roseville, CA 95747
tel: 916.785.1910
fax: 916.785.1749
mauricio.sanchez@hp.com
 
--------------------------------------------

----------------------------------------------------------------------

Message: 1
Date: Tue, 5 Jan 2010 00:27:26 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
Subject: [IPsec] Traffic visibility - consensus call
To: "ipsec@ietf.org" <ipsec@ietf.org>
Message-ID:
	<7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A845@il-ex01.ad.checkpoint.com>
	
Content-Type: text/plain; charset="us-ascii"

Hi,

We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus.

- The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision?

- The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision?

Thanks,
     Yaron

------------------------------

v2.23.0 | Report a Bug | By Email