Next message: Sean Donelan: "Re: Sicily to Egypt undersea cable disruption"
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: [mailto:] On Behalf Of
Paul Vixie
Sent: 02 February 2008 17:32
To:
Subject: Re: Blackholes and IXs and Completing the Attack.
("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.)
