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: Tuesday, October 15, 2013 9:30 AM
> 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]>
> > 15 October 2013 15:55
> > 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.
> 
> They can do that today. In fact they can legally send n* MTU-sized
> header chains, as long as the total length of an IPv6 packet is not
> exceeded.

Sure, but this draft is about setting healthy limits where there were
previously none.

> >> 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.
> 
> Why not? If this is a "maximum", there may always be scenarios where
> less than a maximum is appropriate.

This draft is intending to update RFC2460. Once updated, the
maximum header size requirements are cast in stone.

> > 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.
> 
> RFC 2473 is pretty explicit about how to handle fragmentation (in the
> presence of nested IPv6 tunnels).
> 
> Once a packet is encapsulated in a tunnel it becomes a new "original
> packet" for the next tunnel in any nested tunnel scenario.
> 
> And PMTUD on the originating host (whether that's the original host, or
> the tunnel entry point at the previous nesting level) should receive a
> signal if the current tunnel entry node cannot handle encapsulation due
> to MTU issues (Section 7 of RFC 2473). So the originating host should
> always be informed of the MTU issue, and be able to alter its behavior
> accordingly.

We would have to go back into the long discussions on PMTUD brokenness
to show why you can't always rely on it. Hosts are *guaranteed* 1280,
but they *expect* 1500. Absent signaling from the network, that is
all they know. 

> So again, I don't see what's new in this draft.
> > 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.
> IMHO They can do that today (and worse).

Sure. That's because there are currently no healthy limits set. This
draft is about setting healthy limits; I am saying that as long as
we are making the effort we should get it right.

Thanks - Fred
[e-mail]

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