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 Ray,

> -----Original Message-----
> From: Ray Hunter [mailto:[e-mail]]
> Sent: Monday, October 14, 2013 2:07 PM
> To: Templin, Fred L
> Cc: Ronald Bonica; Brian E Carpenter; Fernando Gont; 6man Mailing List;
> [e-mail]
> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> 
> > Templin, Fred L <mailto:[e-mail]>
> > 14 October 2013 19:39
> > Hi Ron,
> >
> >> -----Original Message-----
> >> From: Ronald Bonica [mailto:[e-mail]]
> >> Sent: Saturday, October 12, 2013 7:07 PM
> >> To: Brian E Carpenter; Templin, Fred L
> >> Cc: Fernando Gont; 6man Mailing List; [e-mail]; Ray Hunter
> >> Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain-
> 08.txt>
> >> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> >>
> >> +1
> >>
> >> Is there a way to decouple this discussion from draft-ietf-6man-
> >> oversized-header-chain? I would be glad to discuss it in the context
> of
> >> a separate draft.
> >
> > I don't know if there is a way to decouple it. I believe I have shown
> > a way to not mess up tunnels while at the same time not messing up
> your
> > draft. That should be a win-win. In what way would imposing a 1K
> limit
> > on the IPv6 header chain not satisfy the general case?
> >
> > Thanks - Fred
> > [e-mail]
> 
> This draft may not go as far as you'd like (e.g. specifying a hard
> limit
> on header length as some proportion of MTU), and I'm also aware of the
> issue of MTU fragmentation and nested tunnels, but I'm still not clear
> on how this draft specifically "messes up tunnels."
>
> Can you explain what specific text in the current draft you consider
> harmful?

That hosts would be permitted to send MTU-sized header chains.

> And why that couldn't be dealt with in a later draft (that imposes
> additional limits on header chains in specific scenarios)?

Once a spec says that a host is permitted to send MTU-sized header
chains the die is cast and no later draft will be able to undo it.
The host has no idea that there may be one or more tunnels in the
path, and so has no way of knowing to alter its behavior to be
kind to tunnels.

That, plus the fact that attackers will be able to craft packets
intended to fool middleboxes by sending a fragmented tunneled
packet with the "good" part of the header chain in the first
fragment and the "bad" part of the header chain in the second
fragment.

Thanks - Fred
[e-mail]


> Thanks.
> 
> 
> >
> >>                                                              Ron
> >>
> >>
> >>>> So, it wasn't necessarily the case that 1280 was a product of
> >>>> "thoughtful analysis" so much as the fact that **they were rushing
> >> to
> >>>> get a spec out the door**. So now, 16 years later, we get to put
> it
> >>>> back on the 6man charter milestone list.
> >>> We could have that discussion in 6man, sure, but I don't believe
> that
> >>> it's relevant to the question of whether draft-ietf-6man-oversized-
> >>> header-chain
> >>> is ready. This draft mitigates a known problem in terms of the
> >> current
> >>> IPv6 standards.
> >>>
> >
> >
> 
> --
> Regards,
> RayH