North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: router worms and International Infrastructure

  • From: Pekka Savola
  • Date: Thu Sep 22 04:41:20 2005 
On Thu, 22 Sep 2005, Christopher L. Morrow wrote:

Sorry, I'll restate my question. Based on this reading of the 7.3 docs on
junipers website (http://tinyurl.com/dodme):

The juniper documentation is notoriously bad...


feasible-paths: Consider all feasible paths during the unicast
reverse-path check.

I think if a packet enters an interface with this configuration set will
have it's source address checked for a path in the FIB... not a path back
down the same interface, just any path, say to china or your dsl link or
whatever. So, assuming the network above where 10/8 is in the FIB any
packet with a source inside 10/8 will pass this check, yes?
Not quite (feasible path check is different from loose RPF) -- I didn't understand the documentation myself at first we had to open a case to get this cleared :-(. I was not sure of your example, but I think what you're saying..

Let me try to clarify.

Let's assume you have a router with one interface to the customer with 1.1.1.0/24 and 10.1.1.0/30 on that link. If you enable strict uRPF towards the customer, only packets coming from 1.1.1.0/24 or 10.1.1.0/30 are accepted (except if you have a more specific route).

Now, let's consider you have the second interface to the customer (let's say on the same router, for simplicity) which has the same 1.1.1.0/24 but different 10.1.2.0/30. With simple strict uRPF, only one of the interfaces is active at the time. If the traffic is asymmetric, packets will get dropped coming from the wrong customer's interface.

Feasible RPF (or possibly manual tuning of route preferences to affect strict RPF) helps here. It allows packets from 1.1.1.0/24 from both interfaces no matter which one is active at the moment. So, you could consider feasible path RPF to be "strict RPF++".

The customer cannot send packets (on either interface) from any source address other than 1.1.1.0/24, 10.1.1.0/30, and 10.1.2.0/30 -- even if you have a route to one of these networks pointing somewhere else.

If you use 10.x.x.x internally in your backbone, you're fine because
that cruft shouldn't be coming at your direction from the customers.

why not? their hosts all can spoof sources, they SHOULD have filters on
their CPE to prevent spoofed sources out of their network, but that's not
widely deployed is it? (well not reliably deployed atleast)
By "shouldn't be coming" I meant "shouldn't be accepted if you use strict/feasible uRPF towards the customer". The packets may get there but they'll be dropped.

At your borders (upstream/peers), you will naturally block all of 10/8
at egress.

my border is very broad and it's not feasible to use acls on all equipment
that makes up that edge :( (for the sake of arguement, which is now far
afield from the original question: "Feasible path won't stop someone
spoofing space thats in my FIB, will it?"
If it's your customer, you can prevent them from spoofing.

If it's not your customer, you obviously can't do much. (FWIW, we drop all the packets at peering/upstream links with our source addresses, but it may not be an option for you.) One could run RPF on some such links but doing so is a bit risky as it assumes that the routing announcements are always sane.

Also, consider the cases where customers push packets your way (for uRPF
strict,  which isn't available for JunOS, but is for IOS depending on
platform/code/hardware-rev... ugh!)
Uhh? uRPF strict is definitely availabe for JunOS.. we've used it for 3-4 years towards all the customers..

and never send you a route for the
traffic back to them? Maybe they are just a transit and don't even hear
the routes for their customer who chose a 'cheaper' path that doesn't
include them nor me directly on this link in question?
For uRPF to work, you have to have a route toward the interface. With feasible path strict uRPF, the route doesn't need to be active (e.g., it can be prepended so that it's never used).

uRPF is not the be-all-end-all of the spoofing problem. It has some
significant implications for networks and customers. Simply blindly
saying: "turn on uRPF XXX-mode and all is good" is simply irresponsible.
Well, I think if you DO turn on uRPF strict, there WILL NOT be spoofing, but in many cases you break stuff if you're not careful so I agree in general that just there will need to be additional discussion.

But, back on the original question:

"does urpf feasible path stop a 'customer' from spoofing sources that are
in the FIB?"

Yes.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings