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
- [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Scott C Moonen
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Merike Kaeo
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Daniel Migault
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Steven Bellovin
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Richard Graveman
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Venkatesh Sriram
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Steven Bellovin
- [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Dan McDonald
- Re: [IPsec] WESP - Roadmap Ahead Gregory Lebovitz
- Re: [IPsec] WESP - Roadmap Ahead Gregory Lebovitz
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Daniel Migault
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent