701 has a blackhole community, 701:9999, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start. -----Original Message----- From: Saku Ytti [mailto:saku+nanog@ytti.fi] Sent: Thursday, October 17, 2002 5:23 PM To: nanog@merit.edu Subject: attacking DDOS using BGP communities? How feasible would these ideas be? 1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on. -would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes 2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party. -just think about the amount of route-maps :> -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating. 3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore. -the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti
Interesting -- I was actually having a conversation about this very same thing with a friend of mine a few days ago. The problem we had, was that he had next-hop-self on all of his ibgp mesh routers. Does that not make it difficult to put an ip next-hop in? Also, would that ip next-hop be propagated throughout his mesh or would that same route-map have to be present on all the edge routers? The other thing we were toying with was a setting the administrative distance for said black-holed route to be less than that of his igp and having his IGP route to 127.0.0.1 or something. The whole goal was to try and kill the route as close to the source as possible so as not to have the traffic traverse the core. The question is, how to? -- "AFAIK, I'm a BOFH for continually bashing you with a clue-by-four. OTOH, if you would just RTFM every once in a while, my life would suck *much* less."
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Frank Scalzo Sent: Friday, October 18, 2002 9:52 AM To: Saku Ytti; nanog@merit.edu Subject: RE: attacking DDOS using BGP communities?
701 has a blackhole community, 701:9999, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start.
-----Original Message----- From: Saku Ytti [mailto:saku+nanog@ytti.fi] Sent: Thursday, October 17, 2002 5:23 PM To: nanog@merit.edu Subject: attacking DDOS using BGP communities?
How feasible would these ideas be?
1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on.
-would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes
2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party.
-just think about the amount of route-maps :> -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating.
3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore.
-the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti
Inline comments below... --Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ####################################################### On Fri, 18 Oct 2002, Jason Lixfeld wrote:
Interesting -- I was actually having a conversation about this very same thing with a friend of mine a few days ago. The problem we had, was that he had next-hop-self on all of his ibgp mesh routers. Does that not make it difficult to put an ip next-hop in? Also, would that ip next-hop be propagated throughout his mesh or would that same route-map have to be present on all the edge routers?
Not difficult at all, I'll post out sample config bits before NANOG in Eugene :) (they are about half done... I'm just lazy)
The other thing we were toying with was a setting the administrative distance for said black-holed route to be less than that of his igp and having his IGP route to 127.0.0.1 or something.
Yikes... Just go with the simple solution :) Blackhole routes work just fine in bgp, sample blackhole route server configs exist at: http://www.secsup.org/Tracking/ for both Juniper and Cisco... and someone was going to forward me Foundry configs at one point too :)
The whole goal was to try and kill the route as close to the source as possible so as not to have the traffic traverse the core. The question is, how to?
Once you look beyond your ASN it gets very difficult to determine where the traffic is originating, unless the next ASN is terminal... Anyway, I'll get some configs at: http://www.secsup.org/CustomerBlackHole/ In the coming days.
-- "AFAIK, I'm a BOFH for continually bashing you with a clue-by-four. OTOH, if you would just RTFM every once in a while, my life would suck *much* less."
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Frank Scalzo Sent: Friday, October 18, 2002 9:52 AM To: Saku Ytti; nanog@merit.edu Subject: RE: attacking DDOS using BGP communities?
701 has a blackhole community, 701:9999, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start.
-----Original Message----- From: Saku Ytti [mailto:saku+nanog@ytti.fi] Sent: Thursday, October 17, 2002 5:23 PM To: nanog@merit.edu Subject: attacking DDOS using BGP communities?
How feasible would these ideas be?
1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on.
-would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes
2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party.
-just think about the amount of route-maps :> -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating.
3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore.
-the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti
Interesting -- I was actually having a conversation about this very same thing with a friend of mine a few days ago. The problem we had, was that he had next-hop-self on all of his ibgp mesh routers. Does that not make it difficult to put an ip next-hop in? Also, would that ip next-hop be propagated throughout his mesh or would that same route-map have to be present on all the edge routers?
The other thing we were toying with was a setting the administrative distance for said black-holed route to be less than that of his igp and having his IGP route to 127.0.0.1 or something.
Again, by doing this you are denying service since you are dropping all the packets addressed to the target. Such protection mounts another DOS attack on the target, this time by preventing any packets traveling though your network from reaching the targets, as opposite to preventing DDOS from using your network. If such system is implemented, the DOS attacks will become a lot harder to trace and chase after, since the attackers will simply trigger target blackholing. Alex
701 has a blackhole community, 701:9999, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start.
Brilliant solution - lets stop DDOS attack on the customer by denying service to the customer is a non-distributed way. Alex
participants (4)
-
alex＠yuriev.com -
Christopher L. Morrow -
Frank Scalzo -
Jason Lixfeld