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 -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com> wrote:
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
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. On Wed, 29 Sept 2021 at 04:10, Amir Herzberg <amir.lists@gmail.com> wrote:
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 -- Amir Herzberg
Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook
On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com> wrote:
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
-- ++ytti
Saku Ytti wrote on 29/09/2021 07:03:
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
On 9/29/21 11:12, Nick Hilliard wrote:
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.
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.
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
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.
On 9/29/21 08:03, Saku Ytti wrote:
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.
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 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 9/28/2021 8:06 PM, Amir Herzberg wrote:
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 -- Amir Herzberg
Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home <https://sites.google.com/site/amirherzberg/home> `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote:
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
On 9/29/21 16:21, Blake Hudson wrote:
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.
On 9/29/2021 9:27 AM, Mark Tinka wrote:
On 9/29/21 16:21, Blake Hudson wrote:
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 :-).
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) ...
----- On Sep 29, 2021, at 8:03 AM, Blake Hudson blake@ispn.net wrote: Hi Blake,
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)
These could perhaps be ICMP host unreachables transmitted by your peers' infrastructure? I've seen my share of production networks running on RFC1918 space while routing public blocks. Thanks, Sabri
On 9/29/2021 5:30 PM, Sabri Berisha wrote:
----- On Sep 29, 2021, at 8:03 AM, Blake Hudson blake@ispn.net wrote:
Hi Blake,
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) These could perhaps be ICMP host unreachables transmitted by your peers' infrastructure? I've seen my share of production networks running on RFC1918 space while routing public blocks.
That's entirely possible, wouldn't even need to be one of my peers. It could be from the remote end or one of it's peers (a host unreachable would likely come from the remote end, I suppose a net unreachable could come from anywhere in the path). Not sure I want to change anything on my end to accommodate someone's use of RFC-1918 addresses on the public internet.
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 Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Amir Herzberg <amir.lists@gmail.com> Sent: September 28, 2021 20:06 To: Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more 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 -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: 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
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 From: NANOG <nanog-bounces+bedard.phil=gmail.com@nanog.org> on behalf of Adam Thompson <athompson@merlin.mb.ca> Date: Wednesday, September 29, 2021 at 1:08 PM To: Amir Herzberg <amir.lists@gmail.com>, Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more 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 Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Amir Herzberg <amir.lists@gmail.com> Sent: September 28, 2021 20:06 To: Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more 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 -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: 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
On Wed, Sep 29, 2021 at 06:14:21PM +0000, Phil Bedard wrote:
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
Phil
From: NANOG <nanog-bounces+bedard.phil=gmail.com@nanog.org> on behalf of Adam Thompson <athompson@merlin.mb.ca> Date: Wednesday, September 29, 2021 at 1:08 PM To: Amir Herzberg <amir.lists@gmail.com>, Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more 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
Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Amir Herzberg <amir.lists@gmail.com> Sent: September 28, 2021 20:06 To: Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more
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 -- Amir Herzberg
Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: 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
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 -----Original Message----- From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of brad dreisbach Sent: September 29, 2021 2:35 PM To: Phil Bedard <bedard.phil@gmail.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more On Wed, Sep 29, 2021 at 06:14:21PM +0000, Phil Bedard wrote:
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
Phil
From: NANOG <nanog-bounces+bedard.phil=gmail.com@nanog.org> on behalf of Adam Thompson <athompson@merlin.mb.ca> Date: Wednesday, September 29, 2021 at 1:08 PM To: Amir Herzberg <amir.lists@gmail.com>, Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more 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
Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Amir Herzberg <amir.lists@gmail.com> Sent: September 28, 2021 20:06 To: Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more
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 -- Amir Herzberg
Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook<http s://sites.google.com/site/amirherzberg/applied-crypto-textbook>
On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: 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
On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
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 Jean
-----Original Message----- From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of brad dreisbach Sent: September 29, 2021 2:35 PM To: Phil Bedard <bedard.phil@gmail.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more
On Wed, Sep 29, 2021 at 06:14:21PM +0000, Phil Bedard wrote:
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
Phil
From: NANOG <nanog-bounces+bedard.phil=gmail.com@nanog.org> on behalf of Adam Thompson <athompson@merlin.mb.ca> Date: Wednesday, September 29, 2021 at 1:08 PM To: Amir Herzberg <amir.lists@gmail.com>, Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more 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
Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Amir Herzberg <amir.lists@gmail.com> Sent: September 28, 2021 20:06 To: Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more
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 -- Amir Herzberg
Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook<http s://sites.google.com/site/amirherzberg/applied-crypto-textbook>
On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: 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
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 -----Original Message----- From: brad dreisbach <bradd@us.ntt.net> Sent: September 29, 2021 3:33 PM To: Jean St-Laurent <jean@ddostest.me> Cc: 'brad dreisbach' <bradd@us.ntt.net>; 'Phil Bedard' <bedard.phil@gmail.com>; 'North American Network Operators' Group' <nanog@nanog.org> Subject: Re: uPRF strict more On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
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
This is not true for all ASICs. Some ASICs choose to incur the penalty in a different way, e.g., by halving the prefix tables. The prefix table is then duplicated so that uRPF SA and forwarding DA lookups can happen in parallel. What kind of penalty is incurred is a question worth asking the equipment vendor. On Wed, Sep 29, 2021 at 1:10 PM Jean St-Laurent via NANOG <nanog@nanog.org> wrote:
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
-----Original Message----- From: brad dreisbach <bradd@us.ntt.net> Sent: September 29, 2021 3:33 PM To: Jean St-Laurent <jean@ddostest.me> Cc: 'brad dreisbach' <bradd@us.ntt.net>; 'Phil Bedard' < bedard.phil@gmail.com>; 'North American Network Operators' Group' < nanog@nanog.org> Subject: Re: uPRF strict more
On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
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
On 9/29/21 23:36, Anoop Ghanwani wrote:
This is not true for all ASICs. Some ASICs choose to incur the penalty in a different way, e.g., by halving the prefix tables. The prefix table is then duplicated so that uRPF SA and forwarding DA lookups can happen in parallel. What kind of penalty is incurred is a question worth asking the equipment vendor.
Agree with this - the implementation can vary between vendors and between hardware. Best to test your specific platform, to be sure. Mark.
On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG <nanog@nanog.org> wrote:
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.
Full rate small packets would be an attack of some kind and could only realistically arrive at your transit and peering ports. The customers usually have slower (relatively) ports and a single customer could not produce a rate of small packets that would be a concern. Therefore uRPF at customer ports should not be a problem in this regard. Regards, Baldur
On Wed, Sep 29, 2021 at 11:38:19PM +0200, Baldur Norddahl wrote:
On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG <nanog@nanog.org> wrote:
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.
Full rate small packets would be an attack of some kind and could only realistically arrive at your transit and peering ports. The customers usually have slower (relatively) ports and a single customer could not produce a rate of small packets that would be a concern. Therefore uRPF at customer ports should not be a problem in this regard.
every network is different of course, and admittedly i am a couple generations of hw from having tested this. the problem was indeed exacerbated by also having a ddos scrubbing service, but i still encourage my competitors to run urpf. -b
Regards,
Baldur
On 9/29/21 20:14, Phil Bedard wrote:
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.
If you don't plan to run a full BGP table on a device, don't enable uRPF, even loose-mode. Mark.
On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka <mark@tinka.africa> wrote:
If you don't plan to run a full BGP table on a device, don't enable uRPF, even loose-mode.
At least in Ciscoland, loose URPF checks will pass if you have a default route. So I do not think it could result in inadvertent blackholing of traffic. What it does allow is for *deliberate* blackholing for traffic; if you null-route a prefix, you now block incoming traffic from that subnet as well. This can be useful and it is how we are using URPF. -- Hunter Fuller (they) Router Jockey VBH M-1A +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering
On 9/30/21 17:56, Hunter Fuller wrote:
On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka <mark@tinka.africa> wrote:
If you don't plan to run a full BGP table on a device, don't enable uRPF, even loose-mode. At least in Ciscoland, loose URPF checks will pass if you have a default route. So I do not think it could result in inadvertent blackholing of traffic.
What it does allow is for *deliberate* blackholing for traffic; if you null-route a prefix, you now block incoming traffic from that subnet as well. This can be useful and it is how we are using URPF.
Agreed. I should have said "If you don't plan to run a full BGP table on a device without a default a route as well, don't enable uRPF, even loose-mode". Principally, we don't run default on any of our service routers. Technically, we point default to the bin on all our service routers, as that's the fastest way for the router to handle illegal traffic it "could" receive. Mark.
On Thu, 30 Sep 2021 18:12:51 +0200, Mark Tinka said:
I should have said "If you don't plan to run a full BGP table on a device without a default a route as well,
Am I insufficently caffienated, or is uRPF the least of your problems if you don't have a full table *and* don't have a default route?
On 10/1/21 01:51, Valdis Klētnieks wrote:
Am I insufficently caffienated, or is uRPF the least of your problems if you don't have a full table *and* don't have a default route?
A partial table with no default is perfectly fine for a peering router. As long as your peering router knows how to get to your prefixes and those of your customers, as well as the prefixes of the networks you peer with, you're good to go. Mark.
A partial table with no default is perfectly fine for a peering router.
As long as your peering router knows how to get to your prefixes and those of your customers, as well as the prefixes of the networks you peer with, you're good to go.
in fact, this seems to be the modern conservative style for some years. i sometimes wonder if it is worth the config pain. randy
IMHO, no, it's not worth it... at least, not unless you have a larger budget than mine, a larger department than mine, and possibly more skilled operators than I am. I don't even grok how this is supposed to work - the only place I "peer" in the classical sense is my local IX; all my other "peers" are ALSO either downstream or upstream networks for me. (e.g. my NREN regional affiliate, who is a lateral peer for many prefixes, but also an upstream access network to reach the national, and then global, REN[s]) If a router doesn't have a default route, and also doesn't have full tables, I can't use it for downstream customers even if they're BGP peers; they're expecting me to either provide full tables, or act as a default gateway. Do people in other parts of the world have access (both physical and logical) to enough bilateral peering (and budgets...) that it makes sense to deploy a router per peer? For the NREN case, it's not full tables, and it's not default routes, but it's still a pretty big table. And they're the location of the "triangle" routing where I have several downstream clients who also peer directly with them. I'm both a lateral "peer" AND a downstream customer to them... so they tried to turn on uRPF on the L3 interfaces towards me and, well, bad things happened to our mutual customers' traffic. Admittedly this was triggered by the downstream customer doing questionable things with different-length prefixes, but the fact remains uRPF causes (sometimes partial) outages anywhere you have multi-path "downstream" clients. And based on the topology, I cannot conceive of any set of ACLs that I could feasibly apply to inbound traffic on the peering link with my NREN affiliate, which makes it... more difficult to be BCP/MARNS-compliant. Commercial traffic regularly transits R&D unexpectedly, and vice-versa: path asymmetry is common here. -Adam P.S. the topology in question was as simple as this. Cust. advertised /N to me, but /N+1 to the R&D side, so traffic started taking an unanticipated detour via the R&D side. IRR/RPKI does not solve this: it was a legitimate advertisement. ┌─────┐ ┌───┐ ┌────────►│MRnet├────►│R&D│ │ └─────┘ └───┘ │ ▲ │ │ ┌─┴───┐ ┌──┴───┐ ┌──────────┐ │Cust.├────►│MERLIN├───►│Commercial│ └─────┘ └──────┘ └──────────┘ Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Randy Bush <randy@psg.com> Sent: October 1, 2021 12:28 To: Mark Tinka <mark@tinka.africa> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: [External] Re: uPRF strict more
A partial table with no default is perfectly fine for a peering router.
As long as your peering router knows how to get to your prefixes and those of your customers, as well as the prefixes of the networks you peer with, you're good to go.
in fact, this seems to be the modern conservative style for some years. i sometimes wonder if it is worth the config pain. randy
Hey Adam, Peer is homonym, in this context peer refers to a BGP session with whom you exchange your customer routes with, and it implies absence of customers and transit in the same router. Whereas you interpreted peer in its wider meaning of any BGP session. On Fri, 1 Oct 2021 at 21:21, Adam Thompson <athompson@merlin.mb.ca> wrote:
IMHO, no, it's not worth it... at least, not unless you have a larger budget than mine, a larger department than mine, and possibly more skilled operators than I am.
I don't even grok how this is supposed to work - the only place I "peer" in the classical sense is my local IX; all my other "peers" are ALSO either downstream or upstream networks for me. (e.g. my NREN regional affiliate, who is a lateral peer for many prefixes, but also an upstream access network to reach the national, and then global, REN[s]) If a router doesn't have a default route, and also doesn't have full tables, I can't use it for downstream customers even if they're BGP peers; they're expecting me to either provide full tables, or act as a default gateway.
Do people in other parts of the world have access (both physical and logical) to enough bilateral peering (and budgets...) that it makes sense to deploy a router per peer?
For the NREN case, it's not full tables, and it's not default routes, but it's still a pretty big table. And they're the location of the "triangle" routing where I have several downstream clients who also peer directly with them. I'm both a lateral "peer" AND a downstream customer to them... so they tried to turn on uRPF on the L3 interfaces towards me and, well, bad things happened to our mutual customers' traffic. Admittedly this was triggered by the downstream customer doing questionable things with different-length prefixes, but the fact remains uRPF causes (sometimes partial) outages anywhere you have multi-path "downstream" clients. And based on the topology, I cannot conceive of any set of ACLs that I could feasibly apply to inbound traffic on the peering link with my NREN affiliate, which makes it... more difficult to be BCP/MARNS-compliant. Commercial traffic regularly transits R&D unexpectedly, and vice-versa: path asymmetry is common here.
-Adam
P.S. the topology in question was as simple as this. Cust. advertised /N to me, but /N+1 to the R&D side, so traffic started taking an unanticipated detour via the R&D side. IRR/RPKI does not solve this: it was a legitimate advertisement. ┌─────┐ ┌───┐ ┌────────►│MRnet├────►│R&D│ │ └─────┘ └───┘ │ ▲ │ │ ┌─┴───┐ ┌──┴───┐ ┌──────────┐ │Cust.├────►│MERLIN├───►│Commercial│ └─────┘ └──────┘ └──────────┘
Adam Thompson Consultant, Infrastructure Services
100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca www.merlin.mb.ca ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Randy Bush <randy@psg.com> Sent: October 1, 2021 12:28 To: Mark Tinka <mark@tinka.africa> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: [External] Re: uPRF strict more
A partial table with no default is perfectly fine for a peering router.
As long as your peering router knows how to get to your prefixes and those of your customers, as well as the prefixes of the networks you peer with, you're good to go.
in fact, this seems to be the modern conservative style for some years. i sometimes wonder if it is worth the config pain.
randy
-- ++ytti
On 10/1/21 20:17, Adam Thompson wrote:
Do people in other parts of the world have access (both physical and logical) to enough bilateral peering (and budgets...) that it makes sense to deploy a router per peer?
Certainly not a router per peer, but a peering router per city, where it may connect to one or more exchange points. This is what we do. Granted, it does increase your budgeting complexity, but in our case, over time, the delineation has actually simplified operations that the architecture has paid itself back many times over. In the real world, this is not always possible, and I understand that a peering router for some networks may also be providing transit as well as edge functions. This is quite normal, even though it can create other complexities depending on whom the eBGP session is with - which then lends itself to running parts or all of the Internet in VRF's and all that hocus pocus. When we tried this sort of thing at a previous job some 14 years ago, it was just simpler to have separate routers each handling transit, peering and customer edge. Mark.
On 10/1/21 19:28, Randy Bush wrote:
in fact, this seems to be the modern conservative style for some years. i sometimes wonder if it is worth the config pain.
If having routers dedicated to peering, transit or edge functions is worth the extra pain, in lieu of doing it all on one box? Mark.
In Ciscoland, you do have to explicitly state that the default route is eligible for URPF verification, otherwise you'll get unexpected traffic drops. ip verify unicast source reachable-via any allow-default And yes, it's main purpose is for implementing source-based remotely-triggered blackhole (SRTBH). On Thu, Sep 30, 2021 at 10:58 AM Hunter Fuller via NANOG <nanog@nanog.org> wrote:
On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka <mark@tinka.africa> wrote:
If you don't plan to run a full BGP table on a device, don't enable uRPF, even loose-mode.
At least in Ciscoland, loose URPF checks will pass if you have a default route. So I do not think it could result in inadvertent blackholing of traffic.
What it does allow is for *deliberate* blackholing for traffic; if you null-route a prefix, you now block incoming traffic from that subnet as well. This can be useful and it is how we are using URPF.
-- Hunter Fuller (they) Router Jockey VBH M-1A +1 256 824 5331
Office of Information Technology The University of Alabama in Huntsville Network Engineering
----- On Sep 30, 2021, at 9:13 AM, Andrew Smith andrew.william.smith@gmail.com wrote: Hi,
In Ciscoland, you do have to explicitly state that the default route is eligible for URPF verification, otherwise you'll get unexpected traffic drops.
ip verify unicast source reachable-via any allow-default
Customer: We need a way to prevent spoofing. Dev: Sure, I created a new feature: "ip verify unicast" Customer: We're dropping legitimate traffic! Dev: Oops, sorry about that. Here, a new feature: "ip verify unicast source reachable-via any" Customer: But but but, we don't have a full BGP table! Dev: Oh well... <clickety-click> "ip very unicast source reachable via any allow-default" Thanks, Sabri
On Thu, 30 Sept 2021 at 19:00, Hunter Fuller via NANOG <nanog@nanog.org> wrote:
What it does allow is for *deliberate* blackholing for traffic; if you null-route a prefix, you now block incoming traffic from that subnet as well. This can be useful and it is how we are using URPF.
I don't think it is implied here, but just for clarification this is implementation detail. Loose and blackhole route does not imply this behaviour, It might, it might not, depending on vendor/implementation. JunOS by default considers null route as loose path satisfied, and you need 'set forwarding-options rpf-loose-mode-discard family X' to behave like you explain. -- ++ytti
Hi
What it does allow is for *deliberate* blackholing for traffic; if you null-route a prefix, you now block incoming traffic from that subnet as well. This can be useful and it is how we are using URPF.
I don't think it is implied here, but just for clarification this is implementation detail. Loose and blackhole route does not imply this behaviour, It might, it might not, depending on vendor/implementation. JunOS by default considers null route as loose path satisfied, and you need 'set forwarding-options rpf-loose-mode-discard family X' to behave like you explain.
Yes even in cisco land for Ios XR SBRTBH you need set next-hop discard in route policy. You cannot use recursive lookup to null in urpf Brian
On 9/29/21 19:07, Adam Thompson wrote:
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.
That's not exactly true, unless that other provider is not carrying a full table on the device your traffic toward your customer was transiting. Generally, we only run uRPF on boxes that carry a fully BGP table. The lack of a full table, even with loose-mode uRPF, will lead to blackholing. Mark.
For strict-mode... Completely agree. As has been previously said, this is a tool that all players involved need to understand. This is no different than everyone correctly using BGP in their application for their outcomes.
On Sep 29, 2021, at 12:07 PM, Adam Thompson <athompson@merlin.mb.ca> wrote:
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
Adam Thompson Consultant, Infrastructure Services
100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca <mailto:athompson@merlin.mb.ca> www.merlin.mb.ca <http://www.merlin.mb.ca/> From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Amir Herzberg <amir.lists@gmail.com> Sent: September 28, 2021 20:06 To: Randy Bush <randy@psg.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more
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 -- Amir Herzberg
Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home <https://sites.google.com/site/amirherzberg/home> `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote: 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
Yeah, but loose mode is inherently useless on any router carrying full tables. (Ok, it can spot bogons, but that's a side effect and I have other ways to catch those.) Point being that MANRS implementation in the "simple" case is (or, at least, CAN be) almost trivially easy, but in the "complex" case is quite difficult - I'm still not even sure I know how to do it 100% correctly with multi-homed downstreams clients. "Just turn on RPF" is starting to feel more like an article of faith rather than genuine technical guidance. :-( -Adam Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Brian Johnson <brian.johnson@netgeek.us> Sent: Friday, October 1, 2021 8:31:15 AM To: Adam Thompson <athompson@merlin.mb.ca> Cc: Amir Herzberg <amir.lists@gmail.com>; Randy Bush <randy@psg.com>; North American Network Operators' Group <nanog@nanog.org> Subject: Re: uPRF strict more For strict-mode... Completely agree. As has been previously said, this is a tool that all players involved need to understand. This is no different than everyone correctly using BGP in their application for their outcomes. On Sep 29, 2021, at 12:07 PM, Adam Thompson <athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca>> wrote: 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 Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org<mailto:nanog-bounces+athompson=merlin.mb.ca@nanog.org>> on behalf of Amir Herzberg <amir.lists@gmail.com<mailto:amir.lists@gmail.com>> Sent: September 28, 2021 20:06 To: Randy Bush <randy@psg.com<mailto:randy@psg.com>> Cc: North American Network Operators' Group <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: uPRF strict more 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 -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: 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
On 9/29/21 02:47, Randy Bush wrote:
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.
On Tue, 28 Sep 2021 17:47:41 -0700 Randy Bush <randy@psg.com> wrote:
do folk use uPRF strict mode?
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
participants (20)
-
Adam Thompson -
Amir Herzberg -
Andrew Smith -
Anoop Ghanwani -
Baldur Norddahl -
Barry Greene -
Blake Hudson -
brad dreisbach -
Brian Johnson -
Brian Turnbow -
Hunter Fuller -
Jean St-Laurent -
John Kristoff -
Mark Tinka -
Nick Hilliard -
Phil Bedard -
Randy Bush -
Sabri Berisha -
Saku Ytti -
Valdis Klētnieks