Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

[Brian E Carpenter <[e-mail]>]

Fred,

See below...

On 10/10/2013 06:42, Templin, Fred L wrote:
> Hi Ole,
> 
>> -----Original Message-----
>> From: Ole Troan [mailto:[e-mail]]
>> Sent: Wednesday, October 09, 2013 10:31 AM
>> To: Templin, Fred L
>> Cc: Ronald Bonica; [e-mail]; [e-mail]
>> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
>> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
>>
>> Fred,
>>
>>>>>> -----Original Message-----
>>>>>> From: Ronald Bonica [mailto:[e-mail]]
>>>>>> Sent: Tuesday, October 08, 2013 5:46 PM
>>>>>> To: Ole Troan; Templin, Fred L
>>>>>> Cc: [e-mail]; [e-mail]
>>>>>> Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-
>>>> 08.txt>
>>>>>> (Implications of Oversized IPv6 Header Chains) to Proposed
>> Standard
>>>>>> I agree with Ole.
>>>>> How so? A tunnel that crosses a 1280 MTU link MUST fragment
>>>>> in order to satisfy the IPv6 minMTU. If it must fragment, then
>>>>> an MTU-length IPv6 header chain would not fit within the first
>>>>> fragment, and we have opened an attack vector against tunnels.
>>>>> This is not a matter to be agreed or disagreed with - it is
>>>>> a simple fact.
>>>> right, and RFC2460 has this to say about it:
>>>>
>>>>   IPv6 requires that every link in the internet have an MTU of 1280
>>>>   octets or greater.  On any link that cannot convey a 1280-octet
>>>>   packet in one piece, link-specific fragmentation and reassembly
>> must
>>>>   be provided at a layer below IPv6.
>>> Very true. In this case, the "link" is the tunnel and the "link-
>> specific
>>> fragmentation" is IPv6 fragmentation. Which places the first part of
>> an
>>> MTU-length IPv6 header chain in the first fragment and the remainder
>> of
>>> the header chain in the second fragment.
>> indeed. which would violate the MUST in oversized-header-chain.
>>
>> what do we do?
>> a) ignore this particular corner case
>> b) suggest the tunnel head end to drop the packet
>> c) develop a new tunnel segmentations scheme that doesn't depend on
>> IPv6 fragmentation. :-)
> 
> You know I have an interest in alternative c), but that does not
> address the issue of splitting the header chain across multiple
> fragments. So, my choice is:
> 
> d) limit the size of the IPv6 header chain so that the chain will
> fit within the first fragment by having the host limit the chain
> to the MTU size minus 256 bytes.
> 
> Actually, I would be even happier if we just asked the host to limit
> the size of the header chain to 1024 bytes regardless of the path MTU.

Since the problem recurses as we tunnel tunnels, I don't see how any
finite limit can solve the problem. 1280 itself is a pragmatic choice
of "a bit shorter than 1500".

The problem is that you are asserting that middleboxes that a tunnel
passes through are expected to examine the complete header chain of
the encapsulated packet even if the encapsulated packet is a fragment.
I think that's an unreasonable expectation. A reasonable expectation
is that middleboxes should identify the encapsulated packet as
a payload that they cannot analyse, and let it go (unless they
have a policy setting to drop tunnelled packets, which is a
different discussion).

I understood that to be the basis on which the WG reached consensus.

    Brian