Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: router worms and International Infrastructure

  • From: Christopher L. Morrow
  • Date: Thu Sep 22 11:01:16 2005

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 (
> 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
> and on that link.  If you enable strict uRPF
> towards the customer, only packets coming from or
> 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
> but different  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 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,, and -- even if
> you have a route to one of these networks pointing somewhere else.

Meaning the customer also has 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 :)

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.