Templin, Fred L <mailto:Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com>
15 October 2013 15:55
Hi Ray,
-----Original Message-----
From: Ray Hunter [mailto:v6ops(_at_)globis(_dot_)net]
Sent: Monday, October 14, 2013 2:07 PM
To: Templin, Fred L
Cc: Ronald Bonica; Brian E Carpenter; Fernando Gont; 6man Mailing List;
ietf(_at_)ietf(_dot_)org
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(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com>
14 October 2013 19:39
Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:rbonica(_at_)juniper(_dot_)net]
Sent: Saturday, October 12, 2013 7:07 PM
To: Brian E Carpenter; Templin, Fred L
Cc: Fernando Gont; 6man Mailing List; ietf(_at_)ietf(_dot_)org; 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(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
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(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
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