uPRF strict more

Adam Thompson athompson at merlin.mb.ca
Fri Oct 1 13:42:27 UTC 2021

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.  :-(

Get Outlook for Android<https://aka.ms/AAb9ysg>
From: Brian Johnson <brian.johnson at netgeek.us>
Sent: Friday, October 1, 2021 8:31:15 AM
To: Adam Thompson <athompson at merlin.mb.ca>
Cc: Amir Herzberg <amir.lists at gmail.com>; Randy Bush <randy at psg.com>; North American Network Operators' Group <nanog at 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 at merlin.mb.ca<mailto:athompson at 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 Thompson
Consultant, Infrastructure Services
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
From: NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org<mailto:nanog-bounces+athompson=merlin.mb.ca at nanog.org>> on behalf of Amir Herzberg <amir.lists at gmail.com<mailto:amir.lists at gmail.com>>
Sent: September 28, 2021 20:06
To: Randy Bush <randy at psg.com<mailto:randy at psg.com>>
Cc: North American Network Operators' Group <nanog at nanog.org<mailto:nanog at 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 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 at psg.com<mailto:randy at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211001/77beccb0/attachment.html>

More information about the NANOG mailing list