Hi Ray,
-----Original Message-----
From: Ray Hunter [mailto:v6ops(_at_)globis(_dot_)net]
Sent: Friday, October 11, 2013 9:59 AM
To: Templin, Fred L
Cc: brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com;
ietf(_at_)ietf(_dot_)org; 6man Mailing List
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>
11 October 2013 17:33
Hi Ray,
-----Original Message-----
From: Ray Hunter [mailto:v6ops(_at_)globis(_dot_)net]
Sent: Friday, October 11, 2013 12:49 AM
To: Templin, Fred L; brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org; 6man Mailing List
Subject: Re: RE: Last Call: <draft-ietf-6man-oversized-header-chain-
08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed
Standard
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?
The middlebox stops parsing when it decides it has seen enough.
Which AFAIK is undefined in practical terms. Especially in the presence
of jumbo payload extension headers or fragments.
Middleboxes should be able to parse as far as they want to
without hitting a hard stop as is the case if the header
chain extends into multiple packets.
So are you saying the current draft has no value?
I am saying that it is unfriendly to tunnels that fragment, and a
simple fix is for the host to limit its header chain length to
1024 bytes.
With
Wireshark at least, it blasts right through encapsulating IP headers
and continues up to and including the ultimate TCP/UDP/ICMP etc.
header inserted by the original host.
I like wireshark.
But how would that parsing model work in a live network without
maintaining state between frames (and leaving your middlebox open to
DoS
or other resource depletion abuse)?
I don't understand the "maintaining state between frames". I am
talking about examining individual header chains within a single
packet independently of any other packets.
We may not yet know how smart middleboxes may become in this
regards. But, they will certainly never become smart enough if
they don't have the entire header chain in the first fragment.
IMHO "ultimate TCP/UDP/ICMP etc." is not defined. The IETF does not
define standard protocol stacks as a totality. HTTP over TCP over IPv6
over L2TP over GRE over PPTP VPN over IPv6 over IPv6 is not illegal. So
this would seem to require far tighter specs on packet formats than the
IETF would ever publish (and rightly so).
Not at all. This is about allowing middleboxes to parse through all
of the headers included by the host and any tunnel endpoints that
may have interposed themselves between the host and the middlebox.
How the middlebox parses is its own business.
The goal is to give the
middlebox enough information so that it can parse as deeply into
the headers as it wants to.
If that is the goal then we probably need to deprecate IPv6
fragmentation as well as a whole bunch of tunnel / encryption protocols
IMHO, and specify that the entire packet has to fit in a single frame.
Which I feel is unrealistic.
Not at all. The proposal is to ask the host to limit its header
chain to 1024 bytes to allow for up to 256 bytes of encapsulation
headers before the header chain would be susceptible to
fragmentation.
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.
We will want for middleboxes at outer perimeters to be able to parse
as many headers as they want to before releasing the packet to
middleboxes at inner perimenters. Otherwise, bad stuff can get past
the outermost perimeters and waste bandwidth and/or cause havoc
within the protected zone.
Right. But if your firewall (which now has to maintain state, or which
is forced to parse right to the end of a packet) itself becomes the
bottleneck and the DoS target, what have you gained?
No inter-packet state - I never said or implied that. And, no one
is *forcing* the middlebox to do anything. This is about *allowing*
the middlebox to do whatever it wants.
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.
Nested tunnels give you perimeters within perimeters, yes. But, we
will want the outer perimeters to be able to parse as deeply as
they want to before passing on to an inner perimeter.
I think my customers will have to start thinking in terms of an onion
skin model, rather than a single outer perimeter and a single "trusted"
zone.
Maintaining state, or full-packet-depth parsing, at the point where the
enterprise hits the Internet is probably not going to fly.
Onion skin, yes, with each layer of the onion doing what it can
to enhance security. That is what I mean by defense in depth.
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.
I guess I will have to repeat myself from what I said several
months ago. The 1280 came from a desire to have multiple nested
tunnels without requiring the tunnels to fragment since the
underlying links presumably all configure a 1500 MTU. But, what
would that look like in real life?
- The first tunnel would have to configure a 1280 MTU so that its
encapsulated packets emerged as 1320
- the second tunnel would have to configure a 1320 MTU so that its
encapsulated packets emerged as 1360
- the third tunnel would have to configure a 1360 MTU so that its
encapsulated packets emerged as 1400
- etc.
But, in real life, it is not possible to assume that we can lay
hands on all tunnel endpoints so as to carefully set MTUs that
satisfy the nesting level - and, when multiple administrative
domains are involved, it can't be done at all.
Please go back in the archives to where I posted the derivation
of the 1280 minMTU (circa 1997):
http://www.ietf.org/mail-archive/web/ipv6/current/msg18462.html
My conclusion is that the 1280/1500 was well intentioned, but
unfortunately not very well thought out.
Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
It doesn't matter what number you pick, and 1280 is probably as good as
it gets. The point from Brian (if I understood it correctly) was that
any fixed number can never be sufficient, as there's no dedicated
portion of the IPv6 MTU specifically assigned to tunneling, and no
defined max tunnel nesting depth.
A fixed number does not limit the number of tunnel nestings, but
it does limit how many nestings can be applied before the header
chain might wrap into a second fragment. But, how many nestings
do you want? If you want up to 6 or so, then the 1024 gives adequate
space. If you want something like 10 or more, then the extension
header chain could theoretically wrap into second fragments.
Remember that the 1280/1500 was to "allow extra room" for tunnels
to add encapsulation headers without causing fragmentation. That
goal also had a fixed upper bound of 220 bytes of room so the
number of nested tunnels was limited by that action as well
(even assuming you could get the tunnel endpoints to cooperate
and make efficient use of the 220). For better or worse, 1280
gave us a fixed number that we will be stuck with forever.
Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
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
---------------------------------------------------------------------
---
--
Regards,
RayH