unicast RPF for peers viable?

Richard A Steenbergen ras at e-gerbil.net
Sun May 5 17:18:35 UTC 2002


On Sun, May 05, 2002 at 12:10:36PM +0200, Iljitsch van Beijnum wrote:
> 
> In a perfect world, there would be no need to do uRPF on peering
> interfaces, because peers make sure they don't send packets with spoofed
> source addresses. Unfortunately, in the real world many networks STILL
> don't bother and thereby allow hard to trace and filter DDoS attacks to be
> launched from inside their networks.
> 
> So what is the collective wisdom on the NANOG list? Is uRPF on peering
> interfaces a viable option and if it breaks esoteric customer
> configurations, too bad; or is it something that should be discouraged
> because it breaks legitimate customer needs?

This is not an all or nothing proposition. Some people argue that because 
they can't filter everyone perfectly, they shouldn't filter anyone at all. 
This is nonsense, if you can take the *30 SECONDS* of your time to take 
care of the 95% of your customers who aren't doing anything complex and 
who aren't going to have problems, both you and the entire internet are 
better off than if you spent the next 3 years trying to figure out how to 
do it for everyone.

I personally would NOT try to filter peers this way, there are just too
many legitimate chances for asymmetric routing at that level. Consider the
simplest one of all: You buy transit from provider A and peer with
provider B, destination C buys transit from provider B and peers with
provider A. Obviously by localpref dest C is going to be sending traffic
to you via provider A and you are going to be sending to them via provider
B. Asymmetric routing is not evil, it is simply how the internet works. 

What we should be doing is encouraging the people with the 95% easy 
customers (or maybe even 100% depending on thier business) to start 
filtering. I've had a transit provider *coughinternapcough* refuse to 
apply RPF to my single homed port when I ASKED for it (how many of your 
customers will do this? :P), because they thought it would place too much 
load on their routers. And then we have Foundry, who in their infinite 
wisdom decided that an access-list should be sufficient for statically 
routed customers, so the RPF they finally came up with is only accessable 
as a BGP neighbor statement. Lots of people have their boxes for customer 
aggregation (because it'll be a cold day in hell before they're doing L3 
in a core :P), and they decided to make it apply only to BPF neighbors, 
the one place you probably DON'T need it. These people need to be beaten 
with the clue stick on a regular basis until something finally sinks in, 
because obviously the first round didn't take.

This is a situation similar to smurf, a mass education of people who don't
read nanog (though I doubt most of the people here do) is required. The
problem is, you can't make it a default configuration because of
asymmetric routing (so someone actually has to think, not just type), and
you can't run probes and tell if someone has RPF setup on a remote network
(the only people with the resources to tell are the people with DDoS nets,
and I don't think they're going to help) so you can publicly shame them.
Until someone solves one of the above two, I don't think much work is
going to be done. Making RPF where reasonable a requirement for peering is
a place to start, but I don't see that as being enforcable.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)



More information about the NANOG mailing list