IETF Logo Mail Archive

Re: [IPsec] Ensuring future extensibility for WESP

Jack Kohn <kohn.jack@gmail.com> Sat, 21 November 2009 00:24 UTC

Return-Path: <kohn.jack@gmail.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 9F6423A67E4 for <ipsec@core3.amsl.com>; Fri, 20 Nov 2009 16:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, 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 8AJvJSdz1ulE for <ipsec@core3.amsl.com>; Fri, 20 Nov 2009 16:24:49 -0800 (PST)
Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id B7BE63A67BE for <ipsec@ietf.org>; Fri, 20 Nov 2009 16:24:49 -0800 (PST)
Received: by ywh13 with SMTP id 13so4450942ywh.29 for <ipsec@ietf.org>; Fri, 20 Nov 2009 16:24:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9A+9s3WxdKop+2uF+SoJnpazql3ll7tRGa5qlsVAlH0=; b=rx0mkZEGTGSRYJuq5WeY9vIMlD71gKLFVnuKWIo0xfWlBmcu1bVsnCOmp7vzLRNtDX PbKFpyYswEF+p+C7kqHbARtXnybppPeblVd7IaExWbEbX6sAgG4GItzeBrTczC/jYVms csDfrQ7kHgw0ZKWXbpMEA7MYEHC4ZYJy2lgng=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=caJS5/KTyTE+JSIvKAvO/ouDfozCvqN06RU/C3WuCdMC/4E8jISJd/hdYQsLc/wwfi /ZS8coiW2zZbgJmwPZ+pbrZTFDm/eARfVeuZiQ0PK0QMpTXMOWEcHkxRjERgCEI0aQa5 0iU+BLxr22r9IGsKMdEDgVjT5x9E4WbFhr83s=
MIME-Version: 1.0
Received: by 10.90.14.13 with SMTP id 13mr3301525agn.117.1258763074082; Fri, 20 Nov 2009 16:24:34 -0800 (PST)
In-Reply-To: <C49B4B6450D9AA48AB99694D2EB0A483382B3294@rrsmsx505.amr.corp.intel.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com> <C49B4B6450D9AA48AB99694D2EB0A483382B3294@rrsmsx505.amr.corp.intel.com>
Date: Sat, 21 Nov 2009 05:54:33 +0530
Message-ID: <dc8fd0140911201624u225e0f4fq4381a4cca13578e7@mail.gmail.com>
From: Jack Kohn <kohn.jack@gmail.com>
To: "Grewal, Ken" <ken.grewal@intel.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: IPsecme WG <ipsec@ietf.org>
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: Sat, 21 Nov 2009 00:24:50 -0000

I support this as well.

Jack

On Fri, Nov 20, 2009 at 10:34 PM, Grewal, Ken <ken.grewal@intel.com> wrote:
> I support this change to ensure future compatibility with the base draft.
>
> As Yaron indicates, the extension header size is as per the current draft
> and we are just adding some semantics to the pad field.
>
>
>
> There is also minimal textual change in the document.
>
>
>
> Thanks,
>
> - Ken
>
>
>
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
> Yaron Sheffer
> Sent: Tuesday, November 17, 2009 11:30 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
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

v2.23.0 | Report a Bug | By Email