Pekka Savola wrote:
Completely agree on the disturbing observation of the increase in
rate-limiting as a primary mitigation mechanism for dealing with
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
a look at the paper "Effectiveness of Rate-Limiting in Mitigating
DoS Attacks" presented by Jarmo Molsa at the Third IASTED International
Thanks to Arbor for collecting the report and your observations.
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
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
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':