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?
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?
as ye sow, so shall ye reap
when you shoot yourself in the foot, just because you are so neurally
broken that the signal takes years to register in your brain, it does
not mean that your foot does not have a hole in it.
randy
somewhat agreed 
At the time I'd think that the providers in question
(lots of other normal network people made the same 'decision' I might add)
didn't think it'd be a good idea to get a /8 allocation from *RIR for
internal infrastructure that they never planned on being reachable from
the outside world.
anyway, I just don't want folks to get the wrong impression about either
uRPF or 'feasible path'. They are tools, they have implications when used,
if you don't understand them you will be making holes in someone's feets
anyway, I just don't want folks to get the wrong impression about either
uRPF or 'feasible path'.
you were quite right there. sorry not to make that clear.
randy
Sorry, I don't understand the context to see the problem.
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.
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 from 10/8 (or whatever has been assigned on the CPE and/or the point-to-point link).
You may also consider using uRPF at the CPE box to disallow the customer from spoofing anything in that infrastructure space (particularly the /30).
At your borders (upstream/peers), you will naturally block all of 10/8 at egress.
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.
>> 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
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...
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.
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)
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.
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
afield from the original question: "Feasible path won't stop someone
spoofing space thats in my FIB, will it?"
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.
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..
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).
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.
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
afield from the original question: "Feasible path won't stop someone
spoofing space thats in my FIB, will it?"
The solution is a double border, possibly with VRF and inter-VRF routing
Internal border sees 10/8 and 10/8 is in the FIB. 10/8 packets can be spoofed here, Infrastructure connects her
External border doesn't see 10/8, 10/8 is NOT in the FIB, 10/8 packets can't be spoofed. Internet connects here.
Internal <-> External links use routable IP space to not infect external with infrastructure routes.
External border cannot talk to infrastructure IPs but it doesn't need to.
External can route through infrastructure to customer CPE
10/8 can still be spoofed on the infrastructure but it will have to come from a customer, not from the Internet.
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?
This sounds like a broken design. Why have one way links? If a customer pushes packets my way and they don't announce that route to me I will drop the packets at my edge. If they want to send me those packets they need to announce. They can announce with AS path prepend x 1000 so I don't send them any traffic but the route needs to exist.
"does urpf feasible path stop a 'customer' from spoofing sources that are
in the FIB?"
No, but you don't use feasible path on links aimed at your customer, you use strict. If your router doesn't support strict then talk to your purchasing department.
oh the joys of urpf
> 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
<snip making networking more complicated than required>
> 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?This sounds like a broken design. Why have one way links? If a
I didn't say I endorsed it, just that it happens, often. It's not a one
way link either, the link may have thousands of routes advertised up it,
just not a few key ones which are sources of traffic.
Like I said earlier this morning, I have no idea why customers don't just
send a prepended-to-hell route along this path for backup, but they
don't... often.
customer pushes packets my way and they don't announce that route to
me I will drop the packets at my edge. If they want to send me those
and you are breaking them... that's bad.
packets they need to announce. They can announce with AS path
prepend x 1000 so I don't send them any traffic but the route needs
to exist.
Sure, and every customer knows bgp/route-maps/policy as well as you... my
point wasn't that it was a good or bad thing, just that it is.
> "does urpf feasible path stop a 'customer' from spoofing sources
> that are
> in the FIB?"No, but you don't use feasible path on links aimed at your customer,
great now we have conflicting answers perhaps I'll ask on j-nsp for
clarification.
you use strict. If your router doesn't support strict then talk to
your purchasing department.
The problem isn't the router, it's the cards in the router often Also,
it's supposed to work according to the vendor, until you test and verify
it doesn't doh! hint, don't by Engine-3 cards for your 12000's unless
you don't care about urpf strict.
hurray!
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.
No, I just described here the simple case. The feasible path strict uRPF works if the customer connects to two routers as well. It's just required that all the prefixes are routed towards the customer's each interface (even if the routes would not be active). In the case of BGP, it requires that the customer advertises all the prefixes on each link, and that's it.
What *isn't* supported, however, that forwards traffic to the ISP on a link without proper advertisements (when using BGP or a routing protocol) on *all* links.
As said, the preferences can be adjusted in any suitable manner (this is different from plain strict uRPF), but the consistent advertisement must be there.
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
just 'active' and 'feasible'.
The configuration is done at two different places: under the forwarding options, you configure whether you want "plain" or "feasible". Under interfaces where you activate uRPF, you configure strict (the default) or loose.
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.
Yeah, this is one of the things that cannot be fixed other than by educating the user. For example, smuggle it in the contract, and when the packets get dropped, explain the situation 