Re: [IPsec] Ensuring future extensibility for WESP

[Min Huang <[e-mail]>]

I like this as well.
This is the minimal change to add extensilibity to WESP.

Howerver, there is a small problem here.
As Yaron suggested:
>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.

According to draft-ietf-ipsecme-traffic-visibility-10,Section 2, Page 6 
   HdrLen, 8 bits: Offset from the beginning of the WESP header to
   the beginning of the Rest of Payload Data (i.e., past the IV, if
   present) within the encapsulated ESP header, in octets. HdrLen
   MUST be set to zero when using ESP with encryption. When using
   integrity-only ESP, the following HdrLen values are invalid: any
   value less than 12; any value that is not a multiple of 4; any
   value that is not a multiple of 8 when using IPv6. The receiver
   MUST ensure that this field matches with the header offset
   computed from using the negotiated SA and MUST drop the packet
   in case it does not match.

It might be conflicted according to these two definitions.
The Padding field is 256 octets at most with the first octet holding the
padding's
length.The Hdrlen is also 8 bits and the whole WESP header is 256 octets at
most.
But the header fielder with 4 octets more than the Padding field.
So the padding field SHOULD be any length<252.  

Thanks,
Min Huang


Sat, 21 Nov 2009 05:54:33 +0530, Jack Kohn <kohn.jack at gmail.com> wrote:
>I support this as well.
>
>Jack
>
>On Fri, Nov 20, 2009 at 10:34 PM, Grewal, Ken <ken.grewal at 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 at ietf.org [mailto:ipsec-bounces at 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