North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Blackholes and IXs and Completing the Attack.

  • From: Ben Butler
  • Date: Sat Feb 02 18:00:24 2008

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

Well then they wouldn't be peering with this route reflector in the
first place.

-----Original Message-----
From: Tomas L. Byrnes [mailto:[email protected]] 
Sent: 02 February 2008 20:39
To: Ben Butler; Paul Vixie; [email protected]
Subject: RE: Blackholes and IXs and Completing the Attack.

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:

USPTO App Number 20060031575 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf 
> Of Ben Butler
> Sent: Saturday, February 02, 2008 12:17 PM
> To: Paul Vixie; [email protected]
> Subject: RE: Blackholes and IXs and Completing the Attack.
> Hi,
> I was not proposing he Null routing of the attack source in the other 
> ISPs network but the destination in my network being Null routed as a 
> destination from your network out.
> This has no danger to the other network as it is my network that is 
> going to be my IP space that is blackholed in your network, and the 
> space blackholed is going to be an address that is being knocked of 
> the air anyway under DoS and we are trying to minimise collateral 
> damage.  I cant see where the risk to the large NSP is - given that 
> the route reflector will only reflect /32s that legitimately originate

> (as a destination not a source) in the AS announcing them as please 
> blackhole.
> For complete clarity: AS13005 announces and has its 
> route object in RIPE as being announced by AS13005.
> My router at IX - BENIX say - announces to the router

> reflector their, the announcement from my IX assigned address 
> is known to be my router on the exchange, and I am 
> announcing a /32 from my AS for a route object registered as being 
> announced by my AS - so the reflector accepts my announcement and 
> reflects it to any other members that choose to peer with this 
> reflector - effectively this is a please blackhole this destination in
> AS13005 - the other members that receive this announcement can then 
> deal with it in anyway they see fit from ignoring it to setting 
> next-hop -> Null0.
> The effect of this would be that any BotNet controlled hosts in the 
> other member network would now be able to drop any attack traffic in 
> their network on destination at their customer aggregation routers.
> I think you might have thought I was suggesting we blackhole sources 
> in other peoples networks - this is definatly not what I was saying.
> So, given we all now understand each other - why is no one doing the 
> above?
> At the end of the day if an IX member doesn't want the announcements 
> don't peer with the blackhole reflector, simple, and it will get Null 
> routed as soon as it hits my edge router at the IX - it would just 
> seem more sensible to enable people to block the traffic before it 
> traverses the IX and further back in their own networks.
> So?????
> Ben
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf 
> Of Paul Vixie
> Sent: 02 February 2008 17:32
> To: [email protected]
> Subject: Re: Blackholes and IXs and Completing the Attack.
> [email protected] ("Ben Butler") writes:
> > ...
> > This hopefully will ensure a relatively protected router
> that is only
> > accessible from the edge routers we want and also secured to only 
> > accept filtered announcements for black holing and in consequence 
> > enable the system to be trusted similar to Team Cymaru.
> > ...
> This sounds like another attempt to separate the Internet's control 
> plane from its data plane, and most such attempts do succeed and are 
> helpful (like NSP OOB, or like enterprise-level anycast of DNS).
> However, I'm not sure that remote triggered blackholes are a good 
> direction, worthy of the protection you're proposing, for three 
> reasons.
> First, because large NSP's simply cannot afford the risk associated 
> with letting a third party, automatically and without controls or 
> audits, decide in real time what sources or destinations shall become 
> unreachable.  With all respect (which is a lot) for spamhaus and cymru

> and even MAPS (which I had a hand in, back in the day), feeding BGP 
> null-routes to a multinational backbone is a privilege that ISO9000 
> and SarBox and liability insurance providers don't usually want to 
> extend.
> Second, because many backbone routers in use today can't do policy 
> routing routing (which is in this case dropping packets because their 
> source address, not their destination address, has a particular 
> community associated with it) at line speed.  Note, this is 
> many-not-all
> -- I'm perfectly aware that lots of backbone routers can do this but 
> not everybody has them or can afford them and those who have them tend

> to be the multinational NSPs discussed earlier.
> To prevent our DDoS protection reflexes from lowering an attacker's 
> cost (by automatically blackholing victims to protect the nonvictims),

> we have to be able to blackhole the abusive traffic by source, not by 
> destination.
> Third, because many OPNs (other people's networks) still don't filter 
> on source address on their customer-facing edge, and thus allow 
> spoofed-source traffic to exit toward "the core" or toward a victim's 
> NSP who cannot filter by source due to path ambiguities inherent in 
> "the core", any wide scale implementation of this, even if we could 
> get trusted automation of it at scale and even if everybody had 
> policy-routing-at-like-speed, would just push the attackers toward 
> spoofed-source.  That means a huge amount of work and money for the 
> world, without changing the endgame for attackers and victims at all.
> (See BCP38 and SAC004 for prior rants on this controversial topic.)