Re: draft-nakibly-v6ops-tunnel-loops review

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2010-07-16 02:48, Fred Baker wrote:
> Could I interest you in doing a thorough review of draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\

Summary
-------

This draft proposes mitigation techniques for malicious loops formed
using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms.

The draft doesn't recommend a choice of technique. I think that for the
work to go forward, the WG would need to agree on a recommendation.
Otherwise, the world will shrug its shoulders.

Details
-------

Several IPv6 transition aids rely on automatic tunneling of IPv6 in
IPv4. If an attacker succeeds in making two such methods link up
with each other head-to-tail, a loop will form, and will consume all
available resources. With manually configured tunnels, such a loop
will be excluded by construction, but with automatic tunnels, an attacker
can (under certain conditions) create a packet that a tunnel egress
will feed back into regular IPv6 routing such that it ends up back
in the tunnel again, until its hop limit expires.

Section 2 describes the attack scenario. I find the terminology
rather confusing:

1. For each tunnel, there is an object called "the tunnel router".
I assume this is supposed to be the encapsulating ingress router.
But it isn't stated clearly.

2. Tunnels have egress decapsulators. Their role is not described
very clearly, but is assumed to be understood.

3. There's a reference to destination hosts being "in" the tunnel.
("The attack is ... initiated by sending an
   IPv6 packet (packet 0 in Figure 1) destined to an end point in T2...")

But hosts aren't in tunnels. They are outside the tunnel, beyond the
egress router. [OK, some hosts do their own decapsulation, but then one
can separate their decapsulator from their IPv6 stack, and anyway such
hosts are not routers and will not forward packets back into the network.]

So does this mean  "destined to a fictitious end point that appears
to be reached via T2"?

There's a similar problem in the very first sentence of section 2:

" In this section we shall denote an IPv6 address of a tunnel's node by
   the prefix of the tunnel and the IPv4 address of the node, i.e.,
   Addr(Prefix, IPv4). "

Does that mean

" In this section we shall denote an IPv6 address of a node reached via
   a given tunnel by the prefix of the tunnel and the IPv4 address of the node, i.e.,
   Addr(Prefix, IPv4). " ?

4. The description in section 2 then states that a packet to IPv6 address
(Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as the
tunnel egress, but that R1 erroneously treats it as if it came from tunnel T1.
It isn't made very clear that this happens *because* the whole of the IPv4
Internet acts as a shared link layer as far as these automatic tunneling
techniques are concerned. Therefore, R1 can only rely on the (dubious)
addresses in the packet headers to figure out what to do next, and what it
does is send the packet back to R2, because that's what the IPv6 prefix tells
it to do.

As far as I can see, the return packet from R1 to R2 could be sent by
native IPv6 if such connectivity exists, but is more likely to be sent
via tunnel T1, which is what R1 probably uses to provide global v6 access.
The draft should make this point clear, anyway.

Section 3 of the draft describes three possible mitigation strategies.

1. Checking the embedded IPv4 addresses explicitly in the tunnel end points.
This is fairly straightforward and would fix the problem in most cases, but
creates some overhead. Configuration would be needed to deal with 6rd
and with RFC1918-based tunnels.

2. Checking that the end point exists, by various techniques. I am more
pessimistic about these options than the author seems to be.

3. Use different protocol numbers for different tunnel types. This would
be hard to deploy - in fact I think it's hopeless, since backwards
compatibility with proto 41 would have to be kept.

By the way, is it sufficient if either R1 or R2 makes the checks?

   Brian Carpenter