|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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 213.170.128.0/19 and has its route object in RIPE as being announced by AS13005. My router at IX - BENIX say - announces 213.170.128.1/32 to the router reflector their, the announcement from my IX assigned address 212.121.34.30 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 192.0.2.1 -> 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.)
|