North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Blackholes and IXs and Completing the Attack.
ben.butler@xxxxxxxxxxxxxx ("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.)