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@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)