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

["Templin, Fred L" <[e-mail]>]

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.

Thanks - Fred
[e-mail]

> cheers,
> Ole