2009 Worldwide Infrastructure Security Report available for download.

Thu Jan 21 14:21:55 UTC 2010

Pekka Savola wrote:
> On Wed, 20 Jan 2010, Stefan Fouant wrote:
>> Completely agree on the disturbing observation of the increase in
>> rate-limiting as a primary mitigation mechanism for dealing with
>> DDoS.  I've
>> seen more and more people using this as a mitigation strategy, against my
>> advice.  For anyone interested in more information on the topic, and why
>> rate-limiting is akin to cutting your foot off, I highly recommend you
>> take
>> a look at the paper "Effectiveness of Rate-Limiting in Mitigating
>> Flooding
>> DoS Attacks" presented by Jarmo Molsa at the Third IASTED International
>> conference.
> 
> Thanks to Arbor for collecting the report and your observations.

Indeed.

> One thing I found extremely strange is that almost 50% report they use
> BCP38/Strict uRPF at peering edge, yet only about 33% use it in customer
> direction. (Figure 13, p20)
> 
> I wonder if peering edge refers to "drop your own addresses" or real
> strict uRPF (or the like)?

Depends. It can do that, BOGON, and any other prefix you want your edge
to discard. I would imagine that it would be difficult to use strict
uRPF on a peering interface though, as packets through that peer may be
received on a different interface than it was sent on (in a multi-homing
situation).

I do strict uRPF for any directly connected clients (SDSL, fibre,
collocation etc) that are single-homed. It's literally one command on a
router interface that is connected to the switch (subnet) of aggregated
clients.

For our clients that multi-home into two of our different edge gear via
BGP, I use loose uRPF. This allows fail-over without packets being dropped.

In some multi-homed client cases, I can get away with using strict. This
is possible in situations where a client has one high-bandwidth link and
one low-bandwidth link in a fail-over-only case. If BGP is set up
correctly, the secondary link will never be used until the primary goes
down. All packets are sent/received on the only interface in the network
that knows about the client prefix, so it works. If the primary fails,
the secondary takes over completely, so again, strict works.

Loose uRPF allows a packet to come into any valid interface (and you can
even allow default route). This seems counter-intuitive, however, the
important point to note is that once uRPF is enabled even in loose mode,
 it will effectively allow you to drop based on source address when
combined with RTBH on any interface it is configured on.

> If not I'm curious if this is for real, and how in earth they're doing
> it, especially given that in Fig 15 (p22) shows they don't implement BGP
> prefix filtering.  If you can't filter BGP, how could you filter
> packets? Based on my experience, even if you filter BGP, you may not be
> able to filter packets except in simple scenarios.

This isn't about packet 'filtering', it's about 'dropping' (or sinking).

Essentially, in a uRPF [S/]RTBH setup, your edge routers are configured
with routes that point to a special address that is destined
(eventually) to null (usually this is automated...the routes are sent to
the edge via a 'trigger' box).

When a packet comes in (or attempts to go out) of the interface
configured with uRPF, the system treats the null route as best-path, and
discards (or forwards) it.

This setup does not require you to have ANY eBGP whatsoever, and also
works in deployments where all of your eBGP peers are sending only
default. As long as you have iBGP to all edge devices, this setup is
pretty trivial to configure.

Throw in a Team Cymru route-server peering on your trigger box, and
you've automated BOGON management network-wide.

I don't think I explained this very clearly (hopefully it was
accurate... it is early in the morning ;). Here is a decent 'howto':

http://www.packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/

Steve