[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: another padding question ...
Steve, Bill, et. al.,
In Message-Id: <v03007813afb35859102d@[128.89.0.110]>
of Date: Thu, 29 May 1997 17:40:52 -0400
you say
> However, in the ESP context, we're just talking about the position of the
> Auth Data field at the end of the packet. In some sense, it's just another
> field within ESP, and not all the ESP (or AH) fields can be 8-byte aligned.
This may be one point of discussion, but it is not the only point
about alignment and ESP.
You asked:
> Can you cite a specific IPv6 document that indicates the granularity
> at which 64-bit alignment must be maintained?
In Message-Id: <3.0.1.32.19970529201906.0097c4b0@ranier.altavista-software.com>
of Date: Thu, 29 May 1997 20:19:06 -0400
Matt Thomas responded
> RFC 1883. All IPv6 headers must be aligned on 8 byte boundaries.
>
> What about encryption-less ESP? It would be foolish to make the
> unencrypted data unaligned since that might force a data copy.
I would like to get the other ESP alignment issue resolved. Can the
working group agree that the ESP IV field MUST be padded to a multiple
of 64 bits to preserve the IPv6 alignment requirements required by RFC
1883?
To save folk time searching the archives, in my message
of Date: Fri, 16 May 97 18:25:50 EDT
> Third, based on the email that I have seen, most folks agree with moving
> the IV out of the ESP header and into the beginning of the Payload
> Data area. I agree that this is a reasonable thing to do. But it
> has a hidden cost for IPv6. In IPv6 tunnel mode, the inner IPv6
> header, which must be aligned on a 64-bit boundary, follows the
> 64-bit aligned ESP header and the algorithm dependent and negotiated
> IV. (Some have argued that this alignment is not strictly required.
> Others that it is. The "be conservative in what you send and liberal
> in what you accept" argues we follow the strict viewpoint.) Thus the
> space occupied by the IV field has to be a multiple of 64 bits to
> meet the IPv6 requirements. It seems this requires that, if the size
> of the IV is a function of the algorithm or is negotiated, then the
> negotiation protocol would have to be aware during the negotiation
> process of the IP version being protected. That seems rather
> complicated to me. I would instead suggest the architecture or ESP
> doc require that IV field size MUST be a multiple of 64 bits, and
> also specify how to pad IVs of other sizes to a multiple of 64 bits.
> Since most algorithms that I am aware of already use 64-bit IVs, this
> would not cause any additional processing. It would make it so that
> (some vendor's) deployed software would not suddenly break when a new
> algorithm which uses other sized IVs is deployed in the future. What
> do others think about making this a requirement?
As this was not clear to all, I amplified in response to a question
in Message-Id: <199705170503.BAA19674@relay.hq.tis.com>
of Date: Sat, 17 May 97 0:42:31 EDT
> > I'm puzzled by this. Why wouldn't the standard padding at the end of
> > the ESP payload be enough to handle alignment problems ?
>
> No. Maybe a picture would help.
>
> 64-bit boundaries (not to scale)
> | | | | | | | | |
> +-------+-------+-------+---- +-------+-------+------------+-------+
> |IP6 Hdr|Rtg Hdr|ESP Hdr| IV |IP6 Hdr|Rtg Hdr|User Payload|ESP Pad|
> +-------+-------+-------+---- +-------+-------+------------+-------+
>
> When the decapsulating system gets this packet, it will "strip off"
> the headers before the (IV and) inner IPv6 header, and then have to
> process that header and possibly others beyond it (inner Rtg Hdr in
> this example). It is expected that the outer IPv6 base header and
> extension headers are aligned so those systems that demand data
> alignment can process the packet. But this system has to also process
> the inner headers. Maybe the inner routing header needs to be
> advanced, and IPv6 addresses shuffled around. If the IV field is not
> a multiple of 64 bits, it breaks the alignment between the outer and
> inner headers, then the vendor is stuck realigning the the packet,
> which is a good way to reduce performance. Some have argued that the
> encrypted portion (IV through ESP Pad) would have to be copied anyway
> so it doesn't really matter. In some cases that argument works. But
> requiring the IV field to be a multiple of 64 bits would make it work
> in all cases, allowing the vendors to simplify their implementations.
> Given current technology, it only costs a few words, and would nail
> things down unambiguously. I think it is a reasonable requirement.
> If others feel otherwise, we should know so that the working group
> documents can warn vendors not to make "assumptions".
Charlie