Hi Ray, > -----Original Message----- > From: Ray Hunter [mailto:v6ops@xxxxxxxxxx] > Sent: Tuesday, October 15, 2013 9:30 AM > To: Templin, Fred L > Cc: Ronald Bonica; Brian E Carpenter; Fernando Gont; 6man Mailing List; > ietf@xxxxxxxx > 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:Fred.L.Templin@xxxxxxxxxx> > > 15 October 2013 15:55 > > Hi Ray, > > > >> -----Original Message----- > >> From: Ray Hunter [mailto:v6ops@xxxxxxxxxx] > >> Sent: Monday, October 14, 2013 2:07 PM > >> To: Templin, Fred L > >> Cc: Ronald Bonica; Brian E Carpenter; Fernando Gont; 6man Mailing > List; > >> ietf@xxxxxxxx > >> 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:Fred.L.Templin@xxxxxxxxxx> > >>> 14 October 2013 19:39 > >>> Hi Ron, > >>> > >>>> -----Original Message----- > >>>> From: Ronald Bonica [mailto:rbonica@xxxxxxxxxxx] > >>>> Sent: Saturday, October 12, 2013 7:07 PM > >>>> To: Brian E Carpenter; Templin, Fred L > >>>> Cc: Fernando Gont; 6man Mailing List; ietf@xxxxxxxx; 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 > >>> fred.l.templin@xxxxxxxxxx > >> 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 fred.l.templin@xxxxxxxxxx > > Thanks - Fred > > fred.l.templin@xxxxxxxxxx > > > > > >> 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 > >