router worms and International Infrastructure

Thu Sep 22 06:15:26 UTC 2005

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