Re: router worms and International Infrastructure

["Christopher L. Morrow" <christopher.morrow () mci com>]

oh the joys of urpf :(

On Thu, 22 Sep 2005, Pekka Savola wrote:

> 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...

you don't say? :)

> > 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.

Meaning the customer also has 23.23.23.0/24 which they have routed into
your network on some other router on your network, that traffic isn't
accepted on the 2 links above... which is much more like 'strict' mode.

> 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.

This has proven very untrue :(

> > 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..

the documentation again is probably lacking :( it doesn't mention strict,
just 'active' and 'feasible'.

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

often it's never sent on this link at all, I don't pretend to understand
why a customer would do this, they just do.

> > 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.

excellent! learned something new today :)