Subject: RE: 6to4 security questions

From: "Christian Huitema" <[email-masked]>
Date: Fri, 22 Nov 2002 18:33:03 -0800

Reading this thread, it seems that many people are confusing several
aspects of the 6to4 security issue. Maybe we should start by writing a
complete security analysis, something a bit more detailed than the
current draft. In any case, let's look at the reflection attack.

The attack to which we kept being pointed is the following: a random
host sends a packet to an IPv6 server listening to a 6to4 address
through a 6to4 router (not to a 6to4 relay); the IPv6 server sends a
response packet to the (forged) IPv6 source address of the incoming
packet.

The vulnerability is that, with this mechanism, a DOS attacker can use
an IPv6 server listening on a 6to4 address to "launder" a DOS attack
launched against an IPv6 site: the IPv6 packets will not contain any
trace of the original IPv4 address from which the attack was launched.
Clearly, that is bad. There are however a number of mitigating factors:

1) The attack does not include a multiplier effect; the amount of
traffic directed at the target will be about equal to the amount of
traffic sent by the attacker.

2) The attack packets go through a choke point, the 6to4 relay between
the laundering site and the target.

3) The packets received by the target contain the address of the
relaying 6to4 site.

4) The payload of the packets received by the target will be a response
generated by the laundering server, which limits any "magic packet"
issue.

5) The attack only provides value if the attacker's IPv4 connection was
subject to ingress filtering, which is alas not a very common case.

Because of the absence of a magic packet effect, this attack is only
really powerful if it is practiced by a "fleet of zombies" using a large
number of reflectors. I personally don't think that fleets of zombies
can be practically eliminated by simply observing their IPv4 addresses.
I also don't think that the attacker whose virus managed to enslave a
large number of zombies particularly cares that these zombies will be
eventually discovered; in practice, the zombies are expandable. I
suspect that the attacker will rather forgo the reflection exercise,
because an attack in which the content of packets can be chosen is more
powerful than an attack in which the source of packets can be hidden. In
any case, given a large enough fleet of zombies, it is statistically
likely that many zombies will not be submitted to IPv4 ingress
filtering; those who are can very often randomize at least some bits of
their source address, mimicking another fellow on the same LAN.

In short, yes it is a vulnerability, but it is not a terribly dangerous
one, and it is a vulnerability that will in any case disappear with
6to4, when sites receive native IPv6 connectivity. So, yes, a fix is
welcome; however, the fix should not be so drastic as to impede the
"autonomous deployment" advantage of 6to4.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Nov 2002 10:09:29 +0100

Thanks Christian, that articulates what I have been feeling.

In fact, it suggests that rate-limiting mechanisms in 6to4 relays
would strongly mitigate the attack - i.e. don't allow more than
N new flows per unit time to a given native IPv6 destination via
a given relay. I think we are going to see rate-limiting defences
anyway, not just in this context.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Nov 2002 11:34:31 +0200 (EET)

On Fri, 22 Nov 2002, Christian Huitema wrote:
> aspects of the 6to4 security issue. 

Indeed.

> Maybe we should start by writing a
> current draft. 

I agree.

I intend to try to do a proper threat analysis as one section of the
draft.  It could very well be a separate draft too.

[...]

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alain Durand <[email-masked]>
Date: Tue, 26 Nov 2002 15:02:52 -0800

Christian Huitema wrote:

>There are however a number of mitigating factors:
>
Not necessarely. It depend on the protocol used on the reflectors.
If you can find a UDP protocol that echos n packets to an original
short incoming packet, you have a multiplier effect.

>the laundering site and the target.
Not necessarely. If thousands of refletors are used, they will used
different relays.

>3) The packets received by the target contain the address of the
If (many) thousands of reflectors are used, each reflector can be
exercized only once and still create a massive DDOS.
Such an attack will be even harder to detect using packet sampling 
techniques.

>generated by the laundering server, which limits any "magic packet"
If many reflectors are exercised, depending on the protocol used,
each DDOS packet may be different.

>subject to ingress filtering, which is alas not a very common case.
True. But this will create disincentive for ISP to put ingress filtering
in place and ruin the effort of those who did.

>number of reflectors.
Not really, you can use only a limited number of zombies (even a well
connected one is enough) if you can discover thousands of valid 6to4 
addresses.
As the packets will be 'landered' by the 6to4 routers, it will be very hard
to trace the attack back to the zombie.

>"autonomous deployment" advantage of 6to4.
See my comment in the other thread on 6to4 & Teredo vs Tunnel Broker.

- Alain.