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.
Actually would it matter if it wouldn't be additive change? Since it
would be diagnostic/special case. But of course it would be trivial for the
vendors to add support for changing the communities this way, if
this could be performed as a additive change you could offer your
customers automaticly partial visiblity under DOS attack until it's
resolved rather than 0 visibility.
Not to mention how much it would ease pinpointing faulty/aggressive parties
thus in long run it could have very positive effect for things like proper
anti-spoofing configurations.
You receive a prefix with the communities 1111:1 2222:2 3333:3 and
TTL-COMM:2. You need to decrement the TTL-COMM value while leaving the
other 3 communities unchanged.
Yes this would need change in IOS/JunOS but it wouldn't actually be
hard to code this feature. But I still think it would be beneficial
if green elves would configure it as non-additive change to all routers
globally. Yes, you couldn't use it as offering partial visibility since
it would most propably break few things here and there but it would
increase your possibility in finding out which AS# is/are originating the
attack.
I'm just waiting for the green elves. But in the mean time, would
anyone configure decrement of TTL-COMM if JunOS and IOS
would magically start to support such feature in hopes of reaching
some time large enough cover to actually do anything good.
Unless *ALL* vendors change their code to compare AS-PATH length for
prefixes against the TTL-COMM value, decrementing the value as the route
is passed from peer to peer is the only way to make this work that I can
think of. Doing that without nixing the other communities that may need
to be passed as well becomes a serious challenge.
Yes, it's quite optimistic and naive to think such concensus could be
achieved when much more modest changes which would require global
co-operation never happen.
Heck, the route-map to do this without regard for other communities would
still be pretty hairy.
Am I missing something here?
No, thanks for the comments.
Ok, I'm a bit late to the party but...
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
Ok, I'm a bit late to the party but...
> 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