RE: 6to4 security questions

["Christian Huitema" <huitema@windows.microsoft.com>]

> >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.
> >
> 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 problem there is with the applications, not with 6to4. Deploying a
protocol that is ready to blast packets without some form of initial
handshake is a truly bad idea. Let's face it: as an application, you can
never trust that the source address is not forged.

> >2) The attack packets go through a choke point, the 6to4 relay
between
> >the laundering site and the target.
> >
> Not necessarely. If thousands of refletors are used, they will used
> different relays.

Well, it is still mitigation: it forces the attacker to find thousand of
relays, and thousands of applications.

> >3) The packets received by the target contain the address of the
> >relaying 6to4 site.
> >
> 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.

I am not sure that we cannot use packet sampling techniques, actually.
Suppose that each 6to4 router, with a low probability of e.g. 1%, sends
an ITRACE or equivalent to the IPv6 source of the encapsulated packet,
and that the ITRACE contains the indication of the actual IPv4 source.
If thousands of relays are used, tens of them will send an ITRACE packet
towards the target of the attack, thus exposing the IPv4 origin. I guess
we ought to study this ITRACE idea further.

> >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.
> >
> If many reflectors are exercised, depending on the protocol used,
> each DDOS packet may be different.

No, that is not true in practice. Even if they are different, they
cannot be "chosen". The "magic packet" terminology refers to attacks
such as "ping of death", in which a carefully crafted packet triggers an
abnormal condition in the receiving host. In a reflection attack, the
packet received by the target is a response packet, produced by a
normally behaving server. Such packets are likely to be discarded
without much processing, since the target did not initiate the
transaction and is not expecting a response; they are also very unlikely
to be crafted in the specific way that may trigger a software bug. For
example, you cannot mount a SYN attack using a reflector: the target
will receive a SYN ACK, that will be immediately discarded since there
is no corresponding half-open connection.

The consequence is that a reflected attack has to be brute force, aiming
simply at the bandwidth of the target. Such attacks require massive
amounts of packets, and are thus much more susceptible to detection
using ITRACE.

> >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.
> >
> True. But this will create disincentive for ISP to put ingress
filtering
> in place and ruin the effort of those who did.

Uh? If you are saying that the ISP can somehow guarantee to their
customers that all source addresses are genuine, you are seriously
misguided. For example, an attacker could hack into a router, from were
it can send packets from virtually any source addresses. There are
thousands of routers in the Internet; are you willing to assume that
none of them will ever be cracked?

> >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.
> >
> 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.

If you have a limited number of zombies, then the ITRACE approach will
work.

> >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.
> >
> See my comment in the other thread on 6to4 & Teredo vs Tunnel Broker.

I believe that 6to4 and tunnel broker have some very different
characteristics. Opposing one to the other as the ultimate solution is
probably a bad idea. It is much more reasonable to acknowledge the
difference and let the market sort it out.

-- Christian Huitema