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
Ok, I'm a bit late to the party but... On Fri, 18 Oct 2002, Saku Ytti wrote:
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.
Interesting idea. However, if people still don't bother to implement filters that make sure spoofed source addresses don't escape their network, will they do this?
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.
Also interesting. I've been thinking about something similar for traffic engineering: a more specific announcement could disappear after 3 AS hops or so.
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.
Wouldn't it be enough to have this null route community in effect in your upstream network? The big disadvantage is that you're giving in to the DoS attack because the target address becomes unreachable. I've been thinking about a more advanced way of doing this where you redirect the traffic towards an affected host to some "filter box" that would then clean it up. See http://www.bgpexpert.com/antidos.php Iljitsch van Beijnum
At 09:12 AM 22-10-02 +0200, Iljitsch van Beijnum wrote:
Ok, I'm a bit late to the party but...
On Fri, 18 Oct 2002, Saku Ytti wrote:
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.
Interesting idea. However, if people still don't bother to implement filters that make sure spoofed source addresses don't escape their network, will they do this?
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.
Also interesting. I've been thinking about something similar for traffic engineering: a more specific announcement could disappear after 3 AS hops or so.
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.
Wouldn't it be enough to have this null route community in effect in your upstream network?
The big disadvantage is that you're giving in to the DoS attack because the target address becomes unreachable.
I've been thinking about a more advanced way of doing this where you redirect the traffic towards an affected host to some "filter box" that would then clean it up. See http://www.bgpexpert.com/antidos.php
This is essentially the concept behind Riverhead Networks (www.riverhead.com) - diverting the traffic to a specialized hardware box on the side, clean out the DDOS traffic and reinject the cleaned traffic back into the normal data path. -Hank Nussbacher hank@riverhead.com Consultant Riverhead Networks
Iljitsch van Beijnum
participants (3)
-
Hank Nussbacher -
Iljitsch van Beijnum -
Saku Ytti