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