Subject: RE: first widely published relay as a dos issue

From: "Christian Huitema" <[email-masked]>
Date: Sat, 12 Jul 2003 05:30:26 -0700

How is that a "publshed relay DoS issue"? It seems that all these packets had the same source and destination addresses, and that the address could be traced. A plausible explanation is a bug in some brand new software, without malicious intent; it is not necessarily a DoS attack. It is also not specifically a relay attack. If those two addresses were both native addresses, then we would have the same attack against every IPv6 router on the path, it would just not use the relay.

________________________________

From: [email-masked] on behalf of Randy Bush
Sent: Sat 7/12/2003 5:05 AM
To: [email-masked]
Subject: first widely published relay as a dos issue

From: Alexander Gall <[email-masked]>
To: [email-masked]
Subject: [6bone] DoS attacks through 6to4 anycast relay
Date: Thu, 10 Jul 2003 11:43:42 +0200

We (SWITCH) are running one of the (still few) 6to4 anycast relays.
Normally, traffic rates are very low (last month's average input was a
little over 200kbps) but there were some spikes of several Mbps in the
past week.  On Tuesday and Wednesday, the traffic was enough to
severely disrupt our 7206VXR that serves as relay and terminates some
6bone tunnels as well.

We are currently testing an IOS image with IPv6 netflow support on
that router, so I was able to see what was going on yesterday evening
(17:00 - 18:30 UTC+2).  The number of active flows climbed to almost
3000 (from a normal 100-300).  This was due to short UDP flows with
random source and destination ports from 2002:3ED3:10C:: to
3FFE:8171:61::11 like these

SrcAddress        InpIf    DstAddress       OutIf    Prot SrcPrt DstPrt Packets
2002:3ED3:10C::   Tu2      3FFE:8171:61::11 Gi4/0    0x11 0x203D 0x8032 150
2002:3ED3:10C::   Tu2      3FFE:8171:61::11 Gi4/0    0x11 0x043D 0x9432 180
2002:3ED3:10C::   Tu2      3FFE:8171:61::11 Gi4/0    0x11 0xAA89 0x8A8E 60
2002:3ED3:10C::   Tu2      3FFE:8171:61::11 Gi4/0    0x11 0xCE89 0xDE8E 160
2002:3ED3:10C::   Tu2      3FFE:8171:61::11 Gi4/0    0x11 0xF289 0x328E 160

Netflow made this easy to spot but the large number of flows is
probably also the main reason why the router performed very badly
during the event :-(

Traffic peaked at 18Mbps before I blocked packets from 62.211.1.12 to
192.88.99.1 at the upstream router.

The source points to

inetnum:      62.211.1.0 - 62.211.1.255
netname:      TIN
descr:        Telecom Italia S.p.A
descr:        [email-masked] ADSL service OSPF Area 1
descr:        Wholesale service for ISP
country:      IT
admin-c:      BS104-RIPE
tech-c:       BS104-RIPE
status:       ASSIGNED PA
remarks:      Please send abuse notification to [email-masked]
notify:       [email-masked]
mnt-by:       TIWS-MNT
changed:      [email-masked] 20020801
source:       RIPE

but that may well be spoofed.

The destination resloves to an interesting name (with only a AAAA RR):
rootk.it :-)

I take this as a good sign that IPv6 is finally catching on ;-)

--
Alex
SWITCH-NOC

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Jul 2003 14:40:38 +0200

> How is that a "publshed relay DoS issue"? It seems that all these packets
> had the same source and destination addresses, and that the address could
> be traced.

that's why i said dos, not ddos

---

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jul 2003 15:47:55 +0300 (EEST)

On Sat, 12 Jul 2003, Christian Huitema wrote:
> How is that a "publshed relay DoS issue"? It seems that all these
> packets had the same source and destination addresses, and that the
> address could be traced. A plausible explanation is a bug in some brand
> new software, without malicious intent; it is not necessarily a DoS
> attack. It is also not specifically a relay attack. If those two
> addresses were both native addresses, then we would have the same attack
> against every IPv6 router on the path, it would just not use the relay.

A plausible assumption seems to be that the attack was not targeted at the 
relay in particular, it just happened to be on the harm's way.

If it had been, it would probably have been nastier.

But still, I think there's something to learn from this case.  For 
example:

- even relatively low traffic counts can harm at least some of the 
deployed base

- (not mentioned here, but an issue in some other scenarios) IPv6 traffic
may be free (for some), but IPv4 is not.  So, some operators may be
hesitant to deploy or at least advertise a 6to4 relay -- this could mean
they'd get in the harm's way because 6to4 relay would be doing
encapsulation (esp. if it would be a full fledged relay)

-  the fewer 6to4 relays there are, the more probable it is *your* relay 
gets in the way of a DoS attack.. :-/

- others ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alexander Gall <[email-masked]>
Date: 12 Jul 2003 18:42:51 +0200

On Sat, 12 Jul 2003 05:30:26 -0700, "Christian Huitema" <[email-masked]> said:

> address could be traced. A plausible explanation is a bug in some
> brand new software, without malicious intent; it is not necessarily
> a DoS attack. 

I can't rule that out but it doesn't seem plausible to me.  It looked
like a typical UDP flood with random source and destination addresses.

BTW, there were two other such incidents on Tuesday and Thursday with
traffic rates up to 70-80Mbps (most of it was dropped by our relay).
Apparently, most traffic came from the same IPv4 address, but there
were also a few large flows from other sources, so it might have even
been a DDoS (in which case some of the other anycast relays could have
been hit as well).  Unfortunately we don't know what the destinations
were in those cases (we only have information on the IPv4 flows
towards 192.88.99.1), so we can't make any statement about that.

> It is also not specifically a relay attack. If those
> two addresses were both native addresses, then we would have the
> same attack against every IPv6 router on the path, it would just not
> use the relay.

I'm fairly sure that the relay was not the intended victim.  The black
hats might not have realized yet that there are still lots of
bottlenecks in the 6bone.

--
Alex
SWITCH-NOC