Subject: RE: (ngtrans) Using Shipworm servers as UDP DoS reflectors

From: "Christian Huitema" <[email-masked]>
Date: Mon, 13 Aug 2001 12:58:51 -0700

The normal check in 6to4 (and shipworm) is that the source IPv6 address
in the tunneled packet should be consistent with the source IPv4 address
in the external envelope. The problem is that one has to waive this
check when the packet comes from a 6to4 relay router or a shipworm
router. The 6to4 spec does not provide a way to distinguish routers,
which means that one has to basically waive the check for everybody. In
shipworm, however, we require that packets originating from shipworm
servers use the shipworm ipv4 anycast address as the source address. I
believe that this gives us a reasonable protection: if ISPs are doing
checks of the source address, then only authorized routers will be able
to use the anycast address as a source address.

Indeed, we could envisage applying the same check in "6to4", i.e.
requesting that packets sent from relay routers originate from the 6to4
anycast address.

-- Christian Huitema

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 3:21 PM
> To: [email-masked]
> Subject: (ngtrans) Using Shipworm servers as UDP DoS reflectors
> 
> Hi,
> 
> As was pointed out at IETF51 ngtrans meeting, there is a reflector
> denial
> of service attack in 6to4 relay router functionality.
> 
> Similar attacks, though even more severe, are also possible with
> Shipworm.
> 
> I pointed this out very briefly on the list on Jul 18.
> 
> 
> Here is a little more verbose how-to:
> 
> Attacker on IPv6 network sends a native packet to the Shipworm relay:
> 
> src = [real ipv6 source, spoofed or whatever]
> dst = 2003:1122:3344:1234::1 (2003 is assumed to be the shipworm
> prefix)
> data = whatever
> 
> Now, the relay will send IPv4 UDP packet to:
> 
> srcv4 = [ipv4 shipworm anycast address]
> dstv4 = 17.34.51.68 (victim, does not even run ipv6)
> dstv4_port = (hex)1234
> data -- encapsulated ipv6:
>  srcv6 = src from above, easily spoofed
>  dstv6 = dst from above
>  ...
> 
> Issue here is that you can use shipworm not only as a reflector
> sending
> traffic using ipip (proto 41, as with 6to4), but to send very specific
> traffic to udp ports.  Protocol 41 can be filtered by sites that have
> never even heard of IPv6 if someone is mounting a DoS attack, but
> reflected attacks against real UDP services cannot be distinguished
> (unless the victim's firewall is decapsulating the packets, see
> below).
> 
> (afternote: you could filter out udp with source port of "Shipworm
> Relay
> Port")
> 
> Good candidates for dstv4_ports might be e.g. dns, portmapper, several
> dynamic rpc ports or whatever.
> 
> Effectively, you can mount DoS attack apparently coming from:
> 
> srcv4 = [ipv4 shipworm anycast address]
> dstv4 = host
> dstv4_potr = port being DoS'ed
> data -- encapsulated ipv6 packet:
> 
>  srcv6 = spoofed ipv6 address or the attacker
>  dstv6 = 2003:1122:3344:1234::1
> 
> So, there's nothing of real value (..to trace) there.  ipv4 anycast
> address may be very difficult to backtrace (possible asymmetry and bgp
> policy), and even then, the relay would only know of the spoofed ipv6
> address.
> 
> So this appears to be a "double-safe" (from attacker's point of view)
> reflector.
> 
> Sure, you can spoof source and send junk to UDP ports as it is, but
> you
> are much easier to get the blame for it.  This appears to be almost
> bulletproof method of not getting caught..
> 
> How to protect against this?  Very difficult.  You could make a MUST
> that
> the representation of 'port' would have to be non-privileged, thus
> minimizing the chance of tunneling into a port where you should not
> ever
> go. However, some NAT's _might_ use privileged ports right after
> bootstrapping, but I don't think this should ever happen.  I recall
> that
> at least some implementations use port ranges like 49000-60000 for NAT
> but
> not sure if this is a global phenomenon.  This might be configurable.
> 
> In any case, some consideration of the problem is probably required
> prior
> to deployment. :-)
> 
> --
> 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: Pekka Savola <[email-masked]>
Date: Tue, 14 Aug 2001 12:59:40 +0300 (EEST)

On Mon, 13 Aug 2001, Christian Huitema wrote:
> in the external envelope.

I believe the check would also fail if you have two interfaces with ipv4
addresses, and 6to4 pseudointerface wouldn't be bound to a specific one?

The same applies to Shipworm, though dual-interface behind NAT doesn't
seem like an awfully common configuration..

> The problem is that one has to waive this

One problem with this is that the check must be done by the receiving
client.  The bandwidth is already wasted then.  Some control of this
should be doable in the Shipworm server too, which brings me back to my
previous question: would it be acceptable to accept only unprivileged
ports (or some configured port range) ?

> requesting that packets sent from relay routers originate from the 6to4

Indeed, but currently there are zero 6to4 anycast relay router
advertisements in the Internet.  This makes me believe that ipv4 anycast
for this specific purpose isn't used that much.

Also, install base of 6to4 supported mechanisms is already rather large;
you could modify the behaviour, but you could only enable it when you know
the relay routers you're using have been updated to use anycast.