do folk use uPRF strict mode? i always worried about the multi-homed
customer sending packets out the other way which loop back to me; see
RFC 8704 §2.2
do vendors implement the complexity of 8704; and, if so, do operators
use it?
clue bat please
randy
Randy, great question. I’m teaching that it’s very rarely, if ever, used (due to high potential for benign loss); it’s always great to be either confirmed or corrected…
So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum up and send to list or me - thanks!)
Amir
Vast majority of access ports are stubby, with no multihoming or
redundancy. And uRPF strict is indeed used often here, but answer very
rarely if ever applies for non-stubby port.
Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind
the port, if you do, you can do ACL, and ACL is significantly lower
cost in PPS in a typical modern lookup engine.
urpf has its place if your network config build processes aren't automated to the point that it's no longer necessary. It would be a net security loss to the internet not to have it widely implemented on access devices.
Nick
Hi,
Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind the
port, if you do, you can do ACL, and ACL is significantly lower cost in PPS in a
typical modern lookup engine.
uRPF still has it's place in access.
We use it in single homed customers and one of the reasons is the limit to the number of acls.
Asr 1ks are 4k unique acls IIRC , but you can put a lot more users on them.
Maybe things have changed since I last looked but this was the main driver for us to use uRPF when we started with 1ks.
Brian
do folk use uPRF strict mode? i always worried about the multi-homed
customer sending packets out the other way which loop back to me; see
RFC 8704 §2.2
We do loose-mode for BGP customers, regardless of whether they are single- or multi-homed.
We do loose-mode on transit routers, as they hold a full table.
We do strict-mode for stub DIA customers.
We do loose-mode for multi-homed DIA customers.
We don't do uRPF on peering routers, as they don't hold a full table.
do vendors implement the complexity of 8704; and, if so, do operators
use it?
Juniper support Feasible Paths, and we use it with no issue.
We don't use Cisco in this role anymore, so not sure.
Mark.
I tend to agree that ACL's will cost less in the data plane. But the only issue, if you feel either uRPF or ACL's are an option, is that for large customers who have tons of (especially dis-contiguous address space that they may not own), the potential for mistakes can happen where some space may either be missed, or incorrectly configured, when ACL's are a chosen alternative to uRPF.
Mark.
As little as 12 months ago, many vendors either had no or a delayed roadmap to support uRPF due to lack of support on usually Broadcom chips, or just a lack of interest in developing code if the Broadcom chip they had supported it.
This was typically the case for new vendors entering the game, or existing ones who were starting to build a merchant chip product line.
I had this issue with Nokia's new IXR line last year. I think they may have implemented it on some of their boxes, but not sure yet.
Mark.
uRPF Strict mode was always suppose a widget for source address validation (SAV). Just like DHCP Lease Query (DOCSIS), the TR-69 ACLs, general ACLs, and other vendor specific widgets. Like all widgets, there are places where it works and other place were it does not. The key principle is to deploy on the customer - provider edge (with provider = to ISPs, CSPs and cloud providers).
Which widget you select is an engineering decision. As Saku points out, some vendors PPS with uRPF is worse than a simple ACLs. But then the PPS hit might be OK if uRPF Strict mode cuts down the operational logistics maintaining the customer ACLs. No right or wrong, just engineering choices for SAV deployment.
Presumably you mean uRPF. As of a few months ago, the .edu I was doing
netops at, Juniper's 'rpf-check' option was set on all the edge
interfaces where there were only end hosts. This is strict mode. The
Cisco counterpart devices would use ' ip verify unicast source
reachable-via rx'. Also strict mode.
More complicated inter-router links would not use this, but some had
form ingress filter that performed roughly the equivalent where
necessary.
John
As an eyeball network operator (Cable, DSL, Fiber) we use uRPF strict mode on customer facing ports on the BRAS gear. Our access gear also tends to include source address verification via DHCP snooping (as well as limits on the number of DHCP leases and/or MAC addresses each customer is allowed) so there are a couple layers of protection.
I do not use uRPF on upstream/transit/IX links or with multi-homed customers - or anywhere else where traffic could be asymmetrical; I prefer to use stateless ACLs at these locations.
On peering and transit routers, on ports facing the remote side, we apply ACL's to drop traffic inbound from reserved space, as well as our own (as we shouldn't see it coming in from the outside).
It's amazing how many matches we see, for all space, both IPv4 and IPv6. Tells just how open some of the "major" networks are :-).
Mark.
Ditto. And ditto.
Extended IP access list ACL-TRANSIT-IN
...
160 deny ip host 0.0.0.0 any
170 deny ip 127.0.0.0 0.255.255.255 any
180 deny ip 224.0.0.0 15.255.255.255 any
190 deny ip 240.0.0.0 15.255.255.255 any
200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
220 deny ip 192.168.0.0 0.0.255.255 any (18325538 matches)
230 deny ip 169.254.0.0 0.0.255.255 any (146523 matches)
...
We just ran into a typical case where uRPF caused a partial outage for one of my customers: the customer is multi-homed, with another provider that I’m also connected to. Customer advertised a longer-prefix to the other guy, so I started sending traffic destined for Customer to the Other Provider… who then promptly dropped it because they had uRPF enabled on the peering link, and they were seeing random source IPs that weren’t mine. Well… yeah, that can happen (semi-legitimately) anytime you have a topological triangle in peering.
I’ve concluded over the last 2 years that uRPF is only useful on interfaces pointing directly at non-multi-homed customers, and actively dangerous anywhere else.
-Adam
Disclosure I work for Cisco and try to look after some of their peering guidelines.
Agree with Adam’s statement, use uRPF on edge DIA customers. Using it elsewhere on the network eventually is going to cause some issue and its usefulness today is almost nil. That being said we still see large providers who have it turned on for peering/transit interfaces either out of legacy configuration or other reasons. The vast majority do not use it for those interface roles.
Phil
Disclosure I work for Cisco and try to look after some of their peering guidelines.
Agree with Adam’s statement, use uRPF on edge DIA customers. Using it elsewhere on the network eventually is going to cause some issue and its usefulness today is almost nil. That being said we still see large providers who have it turned on for peering/transit interfaces either out of legacy configuration or other reasons. The vast majority do not use it for those interface roles.
uRPF incurs a quite severe pps penalty on all of the NPUs i've ever tested.
we have dabbled with it many times over the years and always eventually
end up turning it off(for good this last time, probably).
-b
Hi Brad,
I'd be interested to hear more about this pps penalty. Do we talk about 5% penalty or something closer to 50%?
Let me know if you still have some numbers close to you related to PPS with uRPF loose.
Thanks
Jean
Hi Brad,
I'd be interested to hear more about this pps penalty. Do we talk about 5% penalty or something closer to 50%?
Let me know if you still have some numbers close to you related to PPS with uRPF loose.
iirc, strict vs loose doesnt matter, its still an extra lookup which effects
the performance. i was able to find some numbers to give an example.
the 4x100G tomahawk card was able to pass min frame size(which iirc on ixia is
80B) at line rate with no features enabled. turn on uRPF and it is only able to
pass 208B frames at line rate.
similar results were seen with several generations of cisco and juniper
line cards(if i tested nokia i cant recall, we had stopped doing urpf
when they were introduced into the network).
-b
Thanks a lot for sharing.
So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
100 Gbps at line rate with 208B frames is about ~60 Mpps.
It's a significant penalty.
Jean
I understand better why some prefer acl vs uRpf.
For sure, forwarding 400 Gbps of 80B frames is a sign that something bad is happening. 
Jean