Re: [IPsec] WESP and reliability

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 04 January 2012 22:42 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A32C11E80E9 for <ipsec@ietfa.amsl.com>; Wed, 4 Jan 2012 14:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level:
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjD0aCuEouei for <ipsec@ietfa.amsl.com>; Wed, 4 Jan 2012 14:42:00 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BC90E11E80E8 for <ipsec@ietf.org>; Wed, 4 Jan 2012 14:42:00 -0800 (PST)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q04MfrUR028690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 16:41:56 -0600 (CST)
Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q04MfqcU005862 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jan 2012 04:11:52 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 5 Jan 2012 04:11:52 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: RJ Atkinson <rja.lists@gmail.com>, IPsec ME WG List <ipsec@ietf.org>
Date: Thu, 05 Jan 2012 04:11:18 +0530
Thread-Topic: [IPsec] WESP and reliability
Thread-Index: AczLEvjxPqJwNz2jTvKLTIW7mig3oQAHqjXg
Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2B25@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <F1B15794-3291-4E71-BE26-A3559F408B01@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <CAA1nO734gfXYJLeLU9iYxoArPZJ3Xo3MsXy0Rt9zgoTciBCZbQ@mail.gmail.com> <CAK3OfOg0Gsxxf8T66XNVLHtR1Tk9yHFDGw96tr0UkEh6x5uYpQ@mail.gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com>
In-Reply-To: <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.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 135.245.2.39
Subject: Re: [IPsec] WESP and reliability
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 04 Jan 2012 22:42:01 -0000

Ran, 

> Such packets have been encountered by prototype implementations in at least one firewall.  
> I will certainly encourage those folks to share a sample packet here, but they don't 
> usually show up at IETF and can be very shy.
>
> I think WESP was a valiant try, and it seems to work most of the time.  
> It is just sad that the result just doesn't work in all cases.  

As a co-author of WESP I can tell you that the design was whetted by several HW teams and it works *all* the time. The design was reviewed and approved by major silicon vendors and fortunately for you I am not speaking for a few shy people who refuse to be recognized, but some very audacious people who have sent their approval mails on this mailing list and have stood up and spoken in favor of the WESP design - multiple times.

The NIST Guidelines for Secure IPv6 deployment also refers to WESP as a protocol that can be used to disambiguate ESP-NULL from encrypted ESP packets. A SW division of NIST has already started working on supporting WESP.

Given this I would appreciate if you can stop your rant against WESP till you come up with a real technical reason of why you think WESP is unreliable and "just doesn't work in all cases".

Cheers, Manav