Erik Nordmark <[EMAIL PROTECTED]> writes:
> > Every extension header has a Next Header field somewhere, and that
> > field has some offset from the start of the packet, so what's the
> > problem?
>
> I think the stated problem is that extension headers past an ESP header
> it offset might not be well defined. For instance, ESP + destination options
> where the dstops header has an unknown next header field.
I believe it should be possible to define a sensible value for the
offset, where "sensible" means that it should make some sense to the
sender of the packet.
> Imagine an ESP algorithm that does compression (and encryption).
> Is the implementation supposed to determine at what offset
> the offending next header value "lived" in the packet that was received
> (i.e. in the encrypted and compressed packet).
In this case, one way to define the offset is as the length of the
packet up to and including the ESP header, plus the offset into the
cleartext (i.e. *after* decryption and decompression) data protected
by ESP. You could end up with an offset larger than the actual packet
as it appeared on the wire, but that should not necessarily be a
problem?
> Or is the implementation supposed to derive some pseudo offset from
> the begining of the decrypted packet?
One way to do that would be to keep track of the total length of the
headers already processed, and let each module handling a particular
header, on error, return an offset into the data that module was
supposed to handle, which the ip engine can add to the total when
building a icmp error message.
> Similar things might appear (but less severe) when there is a
> fragment header before the header which has an unknown next header
> field.
>
> I suspect many implementations remove the fragment header when the reassembly
> is done, which means that the next header offset the implementations
> return in ICMP errors would be off by the size of the fragmentation header.
> However, if the offending next header field doesn't fit in the first fragment
> then what should the correct offset be in an ICMP payoad type unknown?
Hmm.
Is it possible to apply ESP first and then fragment the resulting
encrypted packet? If so, you might end up with a first fragment
containing an ESP header and (after decryption) some partial but valid
additional headers, and then the next fragment, after decryption,
contains a bad header that should result in an ICMP error packet. That
seems to make things more complicated.
It seems that one needs some way to indicate if the offset is relative
to an individual fragment or to some "logical" reassembled packet.
> My assumption is that the offset is undefined both past ESP headers and
> when it doesn't fit in the first fragment.
I think it should be possible to define a reasonable offset value in
all cases, but it might be simpler to make it possible to say "oops, I
can't deal with this packet, but I won't go to the effort to tell you
the offset of the header or data I'm having trouble with.".
/Niels
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
