<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><font face="arial, helvetica, sans-serif"><span style="font-size: 10pt;">"</span><span style="font-size: 13.3333px;">Reverse path filtering literally says don't accept a packet from</span></font><div><font face="arial, helvetica, sans-serif"><span style="font-size: 13.3333px;">somewhere that isn't currently the next hop for that packet's source</span></font></div><div><font face="arial, helvetica, sans-serif"><span style="font-size: 13.3333px;">address."<br><br>FIB or RIB?</span></font></div><div><br></div><div>I knew of uRPF as available over an interface, per the routing table, not best path available. Or is that implementation dependent?</div><br><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 10pt;"><span name="x"></span><br><br>-----<br>Mike Hammett<br>Intelligent Computing Solutions<br>http://www.ics-il.com<br><br>Midwest-IX<br>http://www.midwest-ix.com<span name="x"></span><br></div><br><hr id="zwchr" style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 10pt;"><div style="color: rgb(0, 0, 0); font-family: Helvetica, Arial, sans-serif; font-size: 12pt; font-weight: normal; font-style: normal; text-decoration: none;"><b>From: </b>"William Herrin" <bill@herrin.us><br><b>To: </b>"Grant Taylor" <gtaylor@tnetconsulting.net><br><b>Cc: </b>nanog@nanog.org<br><b>Sent: </b>Tuesday, November 8, 2022 2:01:49 PM<br><b>Subject: </b>Re: BCP38 For BGP Customers<br><br>On Tue, Nov 8, 2022 at 8:40 AM Grant Taylor via NANOG <nanog@nanog.org> wrote:<br>> Maybe it's the lack of caffeine, but would someone please remind /<br>> enlighten me as to why uRPF is a bad idea on downstream interfaces?<br><br>Hi Grant,<br><br>Two words: asymmetric routing.<br><br>If the downstream network is architected in such a way that there's<br>more than one path in and out of their network then there's no way to<br>guarantee that any particular router believes the forward path to that<br>network goes to a particular next hop. It can currently map to any<br>next hop that goes in the direction of one of the valid paths. That<br>routing is completely independent of how next hops are selected in the<br>other direction. Packets can travel in one path and out another.<br><br>Reverse path filtering literally says don't accept a packet from<br>somewhere that isn't currently the next hop for that packet's source<br>address. When it's possible for the forward route to point a different<br>direction than the one from which valid packets are received, that is<br>the wrong thing to do. In fact, it breaks the network.<br><br>Useful automated reverse path filtering can ONLY be used when there is<br>exactly ONE valid path to which and from which packets can be<br>received. This is where strict mode uRPF actually works.<br><br><br>> N.B. Maybe I'm thinking more a varient of uRPF wherein if I have a route<br>> to the source from the interface in question. Thus not uRPF-strict<br>> (active route) nor uRPF-loose (route on any interface).<br><br>Even if a particular router happens to have RIB entries for all the<br>valid paths to a host (a sketchy proposition at best), only one such<br>entry will be stored in the FIB where uRPF looks to make its filtering<br>decision.<br><br>As for loose mode, it's basically useless in a BCP38 discussion. Loose<br>mode only filters bogons. It doesn't prevent impersonation of any IP<br>address currently routed in the system and doesn't do anything at all<br>on a router with a default route.<br><br>Regards,<br>Bill Herrin<br><br><br><br><br>-- <br>For hire. https://bill.herrin.us/resume/<br></div><br></div></body></html>