|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Blackholes and IXs and Completing the Attack.
"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: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u =%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=200 60031575&OS=20060031575&RS=20060031575 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 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.) >
|