Templin, Fred L wrote:
Hi Brian,
Responding in a slightly re-arranged order:
The problem is that you are asserting that middleboxes that a tunnel
passes through are expected to examine the complete header chain of
the encapsulated packet even if the encapsulated packet is a fragment.
Yes, but change "are expected to" to "should be able to".
I personally don't see this going anywhere.
Unless you specifically define what is a "tunnel" and you specifically
define a maximum depth of nesting.
The term Upper-Layer Protocol (ULP) is also itself a vague term IMHO
since the value of the "IPv6 next header" is taken from the same code
space as the ULP header values, and there's no specific marker or
"header length" field in IPv6 that explicitly marks a point as "This is
the end of the IPv6 header chain in all circumstances: stop header
parsing here."
Ok, there's a bunch of current code-points that are today considered as
valid ULP's or next-header values, but that is neither time invariant
nor exhaustive, so solving this issue via a registry means there will
always be middlebox code in the wild that lags any updates.
These middleboxes won't be able to differentiate between an unknown ULP,
and an unknown IPv6 next-header. That potentially makes a default pass
or drop decision awkward.
If it's so important to be able to differentiate between what is an ULP
and what is a next header, and we can't reliably do that today, maybe
that's a fundamental flaw in IPv6 that should be addressed.
I think that's an unreasonable expectation. A reasonable expectation
is that middleboxes should identify the encapsulated packet as
a payload that they cannot analyse, and let it go (unless they
have a policy setting to drop tunnelled packets, which is a
different discussion).
But why? If headers beyond the first IPv6 encapsulation header are
available in the clear, the middlebox should be able to parse them
if it wants to. Wireshark already does exactly that - it keeps on
parsing beyond the first encapsulation header up to and including
the true ULP header. And, if Wireshark can do it, so can any other
middlebox that believes security would be improved by continuing
to parse the entire chain - whether or not there is a standard
saying it must not do so.
Because it leaves open the possibility for an attacker to apply the
obfuscation we seek to limit.
Parsing the additional headers beyond the first encapsulation header
provides defense-in-depth. Perimeter middleboxes can then weed out
the bad stuff without either allowing the bad stuff to penetrate more
deeply into the organization or dropping good stuff that should be
allowed through.
There's also a myriad of tunneling technology out there.
Again, what is an ULP? Where do you stop parsing?
Is GRE a tunnel or an ULP? (GRE can run over almost anything)
Is SSH an ULP or a tunnel? (port tunneling)
Is Teredo a tunnel or is it an ULP (UDP) or both?
GRE/ LT2P over HTTP anyone?
The notion of "perimeter" is moveable in the presence of such tunnels.
Presumably there comes a point where the tunnel is terminated and the
transported packet is de-encapsulated, and that IMHO forms another
perimeter where you'd anyway have to apply further security checks.
I think the draft does what it can in a pragmatic manner, but might
benefit from some acknowledgement that this security approach of
applying parsing at a single perimeter can never ever catch all variants
of transporting FOO over BAR.
IMHO It's only at the moment of de-encapsulation that the full semantics
of the payload are revealed in these modern times of "everything
transported over HTTP".
Since the problem recurses as we tunnel tunnels, I don't see how any
finite limit can solve the problem. 1280 itself is a pragmatic choice
of "a bit shorter than 1500".
Agreed.
The 1280 is assuming that all links in the path have a 1500 MTU and
so RFC2460 allowed (1500 - 1280) = 220 bytes for additional IPv6
headers added by nested tunnels without incurring fragmentation.
I am asserting instead that we have to allow for paths that include
links with a 1280 MTU and so tunnels will have to fragment over
such paths.
That means that the first fragmenting tunnel would have room for
1240 in the first fragment, the second fragmenting tunnel would
have room for 1200 in the first fragment, etc. That is why I would
prefer that hosts limit the size of their header chains to 1024; so
that nested tunnels that fragment will still be highly likely to
have the entire header chain in the first fragment.
I understood that to be the basis on which the WG reached consensus.
Maybe the WG didn't understand that such a consensus would make
tunnels less reliable and less secure.
Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
Brian
--
Regards,
RayH