ietf
[Top] [All Lists]

RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

2013-10-16 12:24:25
Hi Fernando,

-----Original Message-----
From: fgont(_dot_)si6networks(_at_)gmail(_dot_)com 
[mailto:fgont(_dot_)si6networks(_at_)gmail(_dot_)com]
On Behalf Of Fernando Gont
Sent: Wednesday, October 16, 2013 10:05 AM
To: Templin, Fred L
Cc: Ole Troan; Ronald Bonica; Brian E Carpenter; 6man-
chairs(_at_)tools(_dot_)ietf(_dot_)org; Ray Hunter; 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

On Wed, Oct 16, 2013 at 1:54 PM, Templin, Fred L
<Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com> wrote:
On Wed, Oct 16, 2013 at 12:45 PM, Templin, Fred L
<Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com> wrote:
I disagree with the header chain terminating as soon as another
IPv6
header is encounter. That defeats defense-in-depth, since outer
perimeter middleboxes would be forced to admit packets with
unexamined
header chains inward to inner perimeter middleboxes. And, if the
unexamined header chains contain bad stuff inserted by an
attacker,
the attack is successful.

The same is true if the underlying encapsulation layer is IPv4.

We should not default to doing as badly as IPv4.

The point is that this is no worse than IPv4. And it is very likely
that one of underlying encapsulations will be IPv4.

If an underlying encapsulation is IPv4, there is a very good
chance that the IPv4 path MTU is at least 1280. Else, the
underlying link with MTU smaller than 1280 is very likely to
be low speed. That being the case, the middlebox would have to
perform IPv4 reassembly, yes. But, that is truly a corner case,
and only when IPv4 is involved. Again, we should be striving
to do better than IPv4.

Once
you're encapsulating, all bets are off in that respect. You should
do
defense-in-depth at the tunnel ingress or egress points. Or, if you
wish, a middle-box could reassemble-inspect/filter-re-fragment

If an outer perimeter middlebox connects to a 10Gbps link on its
outward facing interface and a 64Kbps link on its inward facing
interface, then the middlebox can allow a successful DOS attack
against its protected domain if it does not look at headers beyond
the outermost IPv6 header.

Is it me, or there are actually a plethora of attack vectors an
attacker would use (instead of this one) in such scenario?

Please don't discount this scenario as contrived or unlikely; there
are certainly such low-end data links in real deployments (civil
aviation networks, DoD networks, etc.) that need DOS protection.

Note that no matter what hardcoded limit you enforce, an attacker
willing to evade you're security controls can always add an
extra-layer of encapsulation (assuming he controls that).

Yes. With a 1024 limit on the amount of extension headers a
host can add, approximately 5-6 encapsulations can be added
before the tunnel headers cause the header chain to overflow
the IPv6 minMTU.

That depends on whether extension headers are employed in different
layer of encapsulation.

Most tunneling protocols I am aware of do not specify that additional
extension headers can be added (one exception is the Encapsulation Limit
option specified by RFC2473). So, it should be reasonable for a middlebox 
to drop an encapsulated packet with an unusually long encapsulation
extension header chain inserted by the purported tunnel ingress. 
 
Besides, what's the different between an attacker exceeding your
hardcoded limit and traffic resulting in tunnling packets failing to
include the entire header chain?

The hard-coded limit is 5-6 layers of encapsulation headers fitting
within the IPv6 minMTU but that does not stop tunnels from recursing
indefinitely. What it does do is provide a healthy number of layers
of defense in depth.

As noted off-list, this hard limit becomes a BCP, rather than a std
update: the larger your extension header chain, the higher the chances
that your packets get dropped. For instance, your harcoded 1000 (or
whatever) value means that there are still *lots* of boxes that will
not be able to handle those packets properly, and hence will get
dropped (check the 6man and/or v6ops discussions).

That's OK. Let the BCP for hosts be 1024, and I am happy.

Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

Thanks,
Fernando

<Prev in Thread] Current Thread [Next in Thread>