On Thu, 22 Sep 2005, Pekka Savola wrote:
On Wed, 21 Sep 2005, Christopher L. Morrow wrote:
On Wed, 21 Sep 2005, Pekka Savola wrote:
Btw. Juniper's Feasible Path uRPF (mentioned in RFC3704) is your friend, even on multihomed/asymmetric links.
So, say I'm a large consumer broadband ISP, and I made the decision some years ago to use net-10 as my infrastructure space? How does 'feasible path' help block 10.x.x.x sources exactly?
Sorry, I don't understand the context to see the problem.
Sorry, I'll restate my question. Based on this reading of the 7.3 docs on junipers website (http://tinyurl.com/dodme): 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?
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)
If you also use 10.x.x.x to assign addresses to the CPE boxes (which is what I think you're saying), the customer can only spoof one /30
Nope, I'm saying all my infrastructure is numbered from 10/8 (my fictional networks infrastructure...). The customers might have real addresses in 24/8 or 168.157/16 or anyother legittimate ip range.
You may also consider using uRPF at the CPE box to disallow the customer from spoofing anything in that infrastructure space (particularly the /30).
Sure, but I don't run the CPE, the customer does... it's their decision though I may suggest strongly to them that it'd be a cost savings to them to do uRPF strict, or acls or something along those lines, they don't have to take my suggestions.
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?"
While uRPF might or might not be sufficient to protect *your* infrastructure from worms (if the customer happens to spoof "just the right way"), it should be useful in preventing spoofing affecting others' infrastructure.
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!) 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? 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. But, back on the original question: "does urpf feasible path stop a 'customer' from spoofing sources that are in the FIB?" My reading of the documentation suggest not :( So, what does it accomplish? (extend the use of net-10 to perhaps other private or unallocated ranges used for other purposes...) It may stop some portion of spoofed packets from the customer, but likely not anything of consequence, certainly not if they use tried-and-true juno2.c :( or others of it's ilk. -Chris