Blackholes and IXs and Completing the Attack.

Paul Vixie vixie at isc.org
Sat Feb 2 17:31:45 UTC 2008


ben.butler at c2internet.net ("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.)



More information about the NANOG mailing list