Re: [IPsec] WESP - Roadmap Ahead

Scott C Moonen <smoonen@us.ibm.com> Wed, 11 November 2009 21:06 UTC

Return-Path: <smoonen@us.ibm.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 308E33A6A7C; Wed, 11 Nov 2009 13:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 U4+dlYcrZVG1; Wed, 11 Nov 2009 13:06:32 -0800 (PST)
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id CA86A3A6864; Wed, 11 Nov 2009 13:06:32 -0800 (PST)
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nABKxpP2029087; Wed, 11 Nov 2009 13:59:51 -0700
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nABL6enk080704; Wed, 11 Nov 2009 14:06:41 -0700
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nABL6aFx011286; Wed, 11 Nov 2009 14:06:37 -0700
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nABL6aTO011282; Wed, 11 Nov 2009 14:06:36 -0700
In-Reply-To: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com>
To: Jack Kohn <kohn.jack@gmail.com>
MIME-Version: 1.0
X-KeepSent: F6A67C78:1AD019EA-8525766B:00727DFC; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
From: Scott C Moonen <smoonen@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/11/2009 04:04:31 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/11/2009 04:04:31 PM, Serialize complete at 11/11/2009 04:04:31 PM, S/MIME Sign failed at 11/11/2009 04:04:31 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/11/2009 14:06:35, Serialize complete at 11/11/2009 14:06:35
Message-ID: <OFF6A67C78.1AD019EA-ON8525766B.00727DFC-8525766B.0073F530@us.ibm.com>
Date: Wed, 11 Nov 2009 16:06:34 -0500
Content-Type: multipart/alternative; boundary="=_alternative 0073C5508525766B_="
Cc: ipsec@ietf.org, ipsec-bounces@ietf.org
Subject: Re: [IPsec] WESP - Roadmap Ahead
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, 11 Nov 2009 21:06:34 -0000

Jack, I'm not sure it's clear yet whether WESP will be widely adopted. 
There's disagreement between end-node and middle-node folks as to whether 
WESP or heuristics are the best approach for inspection of ESP-NULL 
traffic.  I think that end-node vendors will be very reluctant to adopt 
WESP widely until there is broad customer demand for it, and I'm not sure 
that this demand will ever materialize.

This is all my personal opinion, of course.  But it seems to me that 
heuristics will have to be adopted by competitive middle-node vendors, and 
therefore (barring any extensions to WESP that make it attractive for 
other reasons) the use of heuristics will probably always be more 
widespread and will dampen the demand for WESP.  Additionally, ESP-NULL 
itself has rather narrow applicability in an environment where end-to-end 
encryption is increasingly common, which further limits the cases where 
there will be an absolute need for WESP.  Furthermore, there will always 
be valid reasons to use AH (reduced overhead compared to WESP).

For reasons like these, I believe it's premature to call for deprecation 
of AH and even more premature to start preferring WESP to ESP.

What status will the WESP RFC have?  Experimental, informational, 
standards track, etc.?


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen



From:
Jack Kohn <kohn.jack@gmail.com>
To:
ipsec@ietf.org
Date:
11/11/2009 11:06 AM
Subject:
[IPsec] WESP - Roadmap Ahead



Hi,

From operational perspective if we are supporting both v4 and v6 (and we 
will) then having different protocols ESP and AH is and will be a 
nightmare.  Common denominator is ESP-Null. However, there were issues 
with ESP-Null as it couldnt be deep inspected which has now been solved 
with WESP.

In short, the argument that "Oh, but we can inspect AH packets" is not 
relevant anymore.

Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate 
it? 

WESP is ESP++, and it offers everthing that ESP offers plus more. What is 
our stance for ESP moving forward?

Also, I see that a lot of work done in other WGs is still using ESP 
(primarily for data integrity). Shouldn’t they be moving to WESP, as WESP 
offers more flexibility?

Jack
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec