|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: router worms and International Infrastructure
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 :)
|