[102247] in North American Network Operators' Group
RE: Blackholes and IXs and Completing the Attack.
daemon@ATHENA.MIT.EDU (Tomas L. Byrnes)
Sat Feb 2 15:41:37 2008
Date: Sat, 2 Feb 2008 12:39:22 -0800
In-Reply-To: <F9181128E9584B40B5A04C43800604B40F8457@anyanka.c2internet.net>
From: "Tomas L. Byrnes" <tomb@byrneit.net>
To: "Ben Butler" <ben.butler@c2internet.net>, "Paul Vixie" <vixie@isc.org>,
<nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
You could achieve the exact same result simply by not advertising the
network to your peers, or by advertising a bogus route (prefixing a
known bogon AS for the addresses you want null-routed). I realize you
would have to subnet/deaggregate your netblocks, and therefore could
wind up with a prefix-length issue for peers who won't accept routes
longer than a certain mask, in some cases, but if you are already being
DDOSed, this should represent SOME improvement.
If you're trying to do it on a /32 basis, I doubt you'd find too many
border router operators interested in accepting a route that small, but
I may be wrong.
The bigger issue with all these approaches is that they run afoul of a
patent applied for by AT&T:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D=
1&u
=3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&d=3D=
PG01&s1=3D200
60031575&OS=3D20060031575&RS=3D20060031575
USPTO App Number 20060031575=20
> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On=20
> Behalf Of Ben Butler
> Sent: Saturday, February 02, 2008 12:17 PM
> To: Paul Vixie; nanog@merit.edu
> Subject: RE: Blackholes and IXs and Completing the Attack.
>=20
>=20
> Hi,
>=20
> I was not proposing he Null routing of the attack source in=20
> the other ISPs network but the destination in my network=20
> being Null routed as a destination from your network out.
>=20
> This has no danger to the other network as it is my network=20
> that is going to be my IP space that is blackholed in your=20
> network, and the space blackholed is going to be an address=20
> that is being knocked of the air anyway under DoS and we are=20
> trying to minimise collateral damage. I cant see where the=20
> risk to the large NSP is - given that the route reflector=20
> will only reflect /32s that legitimately originate (as a=20
> destination not a source) in the AS announcing them as please=20
> blackhole.
>=20
> For complete clarity: AS13005 announces 213.170.128.0/19 and=20
> has its route object in RIPE as being announced by AS13005. =20
> My router at IX - BENIX say - announces 213.170.128.1/32 to=20
> the router reflector their, the announcement from my IX=20
> assigned address 212.121.34.30 is known to be my router on=20
> the exchange, and I am announcing a /32 from my AS for a=20
> route object registered as being announced by my AS - so the=20
> reflector accepts my announcement and reflects it to any=20
> other members that choose to peer with this reflector -=20
> effectively this is a please blackhole this destination in=20
> AS13005 - the other members that receive this announcement=20
> can then deal with it in anyway they see fit from ignoring it=20
> to setting next-hop 192.0.2.1 -> Null0.
>=20
> The effect of this would be that any BotNet controlled hosts=20
> in the other member network would now be able to drop any=20
> attack traffic in their network on destination at their=20
> customer aggregation routers.
>=20
> I think you might have thought I was suggesting we blackhole=20
> sources in other peoples networks - this is definatly not=20
> what I was saying.
>=20
> So, given we all now understand each other - why is no one=20
> doing the above?
>=20
> At the end of the day if an IX member doesn't want the=20
> announcements don't peer with the blackhole reflector,=20
> simple, and it will get Null routed as soon as it hits my=20
> edge router at the IX - it would just seem more sensible to=20
> enable people to block the traffic before it traverses the IX=20
> and further back in their own networks.
>=20
> So?????
>=20
> Ben
>=20
>=20
>=20
> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On=20
> Behalf Of Paul Vixie
> Sent: 02 February 2008 17:32
> To: nanog@merit.edu
> Subject: Re: Blackholes and IXs and Completing the Attack.
>=20
>=20
> ben.butler@c2internet.net ("Ben Butler") writes:
>=20
> > ...
> > This hopefully will ensure a relatively protected router=20
> that is only=20
> > accessible from the edge routers we want and also secured to only=20
> > accept filtered announcements for black holing and in consequence=20
> > enable the system to be trusted similar to Team Cymaru.
> > ...
>=20
> This sounds like another attempt to separate the Internet's=20
> control plane from its data plane, and most such attempts do=20
> succeed and are helpful (like NSP OOB, or like=20
> enterprise-level anycast of DNS).
> However, I'm not sure that remote triggered blackholes are a=20
> good direction, worthy of the protection you're proposing,=20
> for three reasons.
>=20
> First, because large NSP's simply cannot afford the risk=20
> associated with letting a third party, automatically and=20
> without controls or audits, decide in real time what sources=20
> or destinations shall become unreachable. With all respect=20
> (which is a lot) for spamhaus and cymru and even MAPS (which=20
> I had a hand in, back in the day), feeding BGP null-routes to=20
> a multinational backbone is a privilege that ISO9000 and=20
> SarBox and liability insurance providers don't usually want to extend.
>=20
> Second, because many backbone routers in use today can't do=20
> policy routing routing (which is in this case dropping=20
> packets because their source address, not their destination=20
> address, has a particular community associated with it) at=20
> line speed. Note, this is many-not-all
> -- I'm perfectly aware that lots of backbone routers can do=20
> this but not everybody has them or can afford them and those=20
> who have them tend to be the multinational NSPs discussed earlier.
> To prevent our DDoS protection reflexes from lowering an=20
> attacker's cost (by automatically blackholing victims to=20
> protect the nonvictims), we have to be able to blackhole the=20
> abusive traffic by source, not by destination.
>=20
> Third, because many OPNs (other people's networks) still=20
> don't filter on source address on their customer-facing edge,=20
> and thus allow spoofed-source traffic to exit toward "the=20
> core" or toward a victim's NSP who cannot filter by source=20
> due to path ambiguities inherent in "the core", any wide=20
> scale implementation of this, even if we could get trusted=20
> automation of it at scale and even if everybody had=20
> policy-routing-at-like-speed, would just push the attackers=20
> toward spoofed-source. That means a huge amount of work and=20
> money for the world, without changing the endgame for=20
> attackers and victims at all.
> (See BCP38 and SAC004 for prior rants on this controversial topic.)
>=20
