North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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 (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
> 126.96.36.199/24 and 10.1.1.0/30 on that link. If you enable strict uRPF
> towards the customer, only packets coming from 188.8.131.52/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
> 184.108.40.206/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
> Feasible RPF (or possibly manual tuning of route preferences to affect
> strict RPF) helps here. It allows packets from 220.127.116.11/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 18.104.22.168/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 22.214.171.124/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
> > But, back on the original question:
> > "does urpf feasible path stop a 'customer' from spoofing sources that are
> > in the FIB?"
excellent! learned something new today :)