router worms and International Infrastructure

Thu Sep 22 08:39:53 UTC 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