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... Steve

On Jan 20, 2010, at 8:32 AM, Stefan Fouant wrote:

I'm wondering if you can clarify why 'Figure 1' only goes up to 2008 and states in key findings "This year, providers reported a peak rate of only 49 Gbps". I happen to personally recall looking at ATLAS sometime last year and seeing an ongoing attack that was on orders of magnitude larger than that.

That was an error in the chart (which has since been corrected), it should have illustrated that 2009 respondents indicated 49 Gbps was the largest observed attack. FWIW, I've seen empirical evidence supporting much larger attacks (~82 Gbps), and the Akamai folks indicated recently they'd seen attacks on the order of 120Gbps towards a single target. However, these attacks were NOT reflected in survey feedback expressly, and were therefore not included in the report.

An interesting observation was the decrease in the use of flow-based tools, and the corresponding increase in the use of things like SNMP tools, DPI, and customer calls for attack detection. Surely this must have been a factor of a larger respondent pool... I'd really like to think people aren't opting not to use flow-based tools in favor or receiving customer calls :(

Yep, I think this is simply an artifact of a larger respondent pool size, with many smaller respondents being represented. -danny