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

Paul Koning <pkoning@equallogic.com> Wed, 16 February 2005 23:05 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 SAA08126 for <ipsec-archive@lists.ietf.org>; Wed, 16 Feb 2005 18:05:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Y2I-00021J-EK; Wed, 16 Feb 2005 17:52:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XyZ-0008I0-By for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 17:48:55 -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 RAA06348 for <ipsec@ietf.org>; Wed, 16 Feb 2005 17:48:52 -0500 (EST)
Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YJt-0005iu-5H for ipsec@ietf.org; Wed, 16 Feb 2005 18:10:58 -0500
Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j1GMmM9S023803 for <ipsec@ietf.org>; Wed, 16 Feb 2005 17:48:22 -0500
Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j1GMmKGa023798; Wed, 16 Feb 2005 17:48:20 -0500
Received: from pkoning.equallogic.com ([172.16.1.139]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Feb 2005 17:48:19 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16915.52658.617227.384253@gargle.gargle.HOWL>
Date: Wed, 16 Feb 2005 17:48:18 -0500
From: Paul Koning <pkoning@equallogic.com>
To: msa@burp.tkv.asdf.org
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]> <200502162212.j1GMCXAQ024845@burp.tkv.asdf.org>
X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid
X-OriginalArrivalTime: 16 Feb 2005 22:48:19.0947 (UTC) FILETIME=[9C84BBB0:01C51479]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org, kent@bbn.com
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
Content-Transfer-Encoding: 7bit

>>>>> "Markku" == Markku Savela <msa@burp.tkv.asdf.org> writes:

 >> 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.

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

No... you don't shift the data, you change the start of data pointer.
Then you reference header fields relative to that pointer.

If the alignment requirement isn't satisfied, then you can end up in
situations where the original alignment lets you do nice efficient
aligned memory loads, but after adjusting the pointer past the ESP
header you have to use unaligned load sequences.  Either that, or you
don't realize this and your box crashes on an unaligned load
fault... :-( 

	 paul


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