Re: [IPsec] Ensuring future extensibility for WESP

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Fri, 20 November 2009 10:28 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 4CC3C3A690D for <ipsec@core3.amsl.com>; Fri, 20 Nov 2009 02:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.951
X-Spam-Level:
X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6]
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 yTHbJP-AHwrN for <ipsec@core3.amsl.com>; Fri, 20 Nov 2009 02:28:40 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 1B9033A6AA7 for <ipsec@ietf.org>; Fri, 20 Nov 2009 02:28:39 -0800 (PST)
Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id nAKASX3b014432; Fri, 20 Nov 2009 04:28:33 -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 nAKASUns018899; Fri, 20 Nov 2009 04:28:31 -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 nAKAWNAB012528; Fri, 20 Nov 2009 18:32:24 +0800
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 20 Nov 2009 15:58:29 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Yaron Sheffer <yaronf@checkpoint.com>, IPsecme WG <ipsec@ietf.org>
Date: Fri, 20 Nov 2009 15:58:27 +0530
Thread-Topic: Ensuring future extensibility for WESP
Thread-Index: AcpoFSLc1kth/nrBQ1azCQhwolsjHABtrruQ
Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2F637DD@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350AB2F637DDINBANSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27
X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133
Subject: Re: [IPsec] Ensuring future extensibility for WESP
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: Fri, 20 Nov 2009 10:28:45 -0000

Hi Yaron,

I am fine with these changes and i think we must have them to keep WESP extensible!

Thanks, Manav

________________________________
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Wednesday, November 18, 2009 1.00 PM
To: IPsecme WG
Subject: [IPsec] Ensuring future extensibility for WESP

Hi,

The recent draft on extending WESP which was presented in Hiroshima, explains why the current WESP is *not* extensible, and we would need a new version number if we are to add any extensions in the future.

It is up to the WG to decide whether or not we want to adopt the draft, given that many people were skeptical about the specific extensions proposed. But regardless of that, it would be a mistake to publish WESP today with no facility for extensibility. After consulting with Pasi (the draft is at a very late stage, having been through IESG review), I would like to make a simple proposal to add this extensibility, with (almost) no change to the current draft. This will leave us with future options, at virtually no cost. I am basically just changing the semantics of the Padding field. Specifically:

1. Rename IPv6Padding to "Padding (Reserved for Future Use)", and allow it to be any length <256, subject to the IPv4 and IPv6 alignment constraints.
2. If P=1 (Padding Present flag), the first octet of the Padding field will hold the padding's length. [Hardware implementations can check that it is 4 for IPv6, otherwise move the packet to the slow path]. All other Padding octets are sent as zero, and ignored by the receiver.

Note that there are barely any changes on the wire, as long as we don't have extensions. In particular the length remains unchanged.

Thanks,
            Yaron