Re: [IPsec] Ensuring future extensibility for WESP

[Yaron Sheffer <[e-mail]>]

Hi Min,

Thanks for your (correct) comment.

	Yaron

> -----Original Message-----
> From: Min Huang [mailto:[e-mail]]
> Sent: Saturday, November 28, 2009 11:57
> To: Yaron Sheffer
> Cc: [e-mail]
> Subject: Re: [IPsec] Ensuring future extensibility for WESP
> 
> 
> 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
> 
> 
> 
> Scanned by Check Point Total Security Gateway.