Re: [Ipsec] Minor comment/question on draft-ietf-ipsec-esp-v3-09.txt

Markku Savela <msa@burp.tkv.asdf.org> Wed, 16 February 2005 22:26 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04402 for <ipsec-archive@lists.ietf.org>; Wed, 16 Feb 2005 17:26:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XWk-0005Cr-Sx; Wed, 16 Feb 2005 17:20:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XPX-0001qP-PG for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 17:12:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03025 for <ipsec@ietf.org>; Wed, 16 Feb 2005 17:12:40 -0500 (EST)
Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Xkr-0004g7-7z for ipsec@ietf.org; Wed, 16 Feb 2005 17:34:46 -0500
Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1GMCXQS024848; Thu, 17 Feb 2005 00:12:33 +0200
Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1GMCXAQ024845; Thu, 17 Feb 2005 00:12:33 +0200
Date: Thu, 17 Feb 2005 00:12:33 +0200
Message-Id: <200502162212.j1GMCXAQ024845@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: kent@bbn.com
In-reply-to: <p06210203be392fa38c95@[10.1.190.35]> (message from Stephen Kent on Wed, 16 Feb 2005 12:22:18 -0500)
Subject: Re: [Ipsec] Minor comment/question on draft-ietf-ipsec-esp-v3-09.txt
References: <200502161359.j1GDx5SK016618@burp.tkv.asdf.org> <p06210203be392fa38c95@[10.1.190.35]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ipsec@ietf.org
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

> From: Stephen Kent <kent@bbn.com>

> Inside the ESP payload, after the optional IV, is the "next layer 
> protocol header." It is referred to as "rest of payload data" in 
> Figure 2. Typically, for transport mode this will be TCP or UDP. For 
> tunnel mode, it is IP. This text is part of a discussion reminding 
> folks that the IV, if present, must preserve the 4 or 8 byte 
> alignment requirements for the relevant IP version. We assume that 
> the ESP payload, overall, started on an appropriate boundary, so the 
> addition of the 8 bytes of SPI plus sequence number preserved this 
> alignment. But the IV, if present, could break the alignment.

I knew that, but I assumed the removal of the ESP headers from the
packet required shifting of data within the packet anyway, so the
aligment requirement seemed unnecessary.

I suppose, it might make some optimizations in the shifting
possible. However, this is a new requirement compared to RFC-2406? Can
it be "MUST"?


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec