Re: 6to4 security questions

[Brian E Carpenter <brian@hursley.ibm.com>]

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

Christian Huitema wrote:
> 
> 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