North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: router worms and International Infrastructure
- From: Pekka Savola
- Date: Thu Sep 22 04:41:20 2005
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...
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..
feasible-paths: Consider all feasible paths during the unicast
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?
Let me try to clarify.
Let's assume you have a router with one interface to the customer with
22.214.171.124/24 and 10.1.1.0/30 on that link. If you enable strict uRPF
towards the customer, only packets coming from 126.96.36.199/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
188.8.131.52/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 184.108.40.206/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 220.127.116.11/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.
By "shouldn't be coming" I meant "shouldn't be accepted if you use
strict/feasible uRPF towards the customer". The packets may get there
but they'll be dropped.
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 it's your customer, you can prevent them from spoofing.
At your borders (upstream/peers), you will naturally block all of 10/8
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?"
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.
Uhh? uRPF strict is definitely availabe for JunOS.. we've used it for
3-4 years towards all the customers..
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
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).
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?
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
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?"
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings