<div dir="ltr">Am I correct in assuming loose mode RPF only drops packets from unannounced address space in the global routing table? And the downside of doing so is that sometimes we do receive packets from that address space, usually back scatter from traceroute or other ICMP messages.<div><br></div><div>Currently about 25% of the routable address space is not advertised in the DFZ. Loose mode RPF could filter this. Is there any data on how much traffic actually arrives from this space?</div><div><br></div><div>Regards,</div><div><br></div><div>Baldur</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 10:07 PM William Herrin <<a href="mailto:bill@herrin.us">bill@herrin.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson <<a href="mailto:brian.johnson@netgeek.us" target="_blank">brian.johnson@netgeek.us</a>> wrote:<br>
> Disagree with Bill here. It will depend on the complexity of the network as to use of uRPF in any mode (loose or strict). In general, I never use uRPF on transit links and use pure filters to ensure accurate filters are in place. uRPF may be used internally in either mode to great advantage and I’ve done it both ways.<br>
<br>
<br>
Hi Brian,<br>
<br>
Do you know and understand what you broke? It's one thing to make a<br>
judgement call. Quite another to wave your hands and say, "Oh well,<br>
nobody complained so it must be OK."<br>
<br>
<br>
> If you are looking for corner cases, avoid networking. I do not know of a protocol or a technique that I cannot find a corner case for.<br>
<br>
Not sure what you're saying here. Corner cases aren't a bad thing.<br>
They're just the point where a technology or technique is most likely<br>
to break. If you want reliability, you're supposed to identify the<br>
corner cases and then you're supposed to game out what happens in<br>
those corner cases. A result will be acceptable or unacceptable and if<br>
it's unacceptable you don't do that. If you haven't identified and<br>
gamed the corner cases then (A) you can't prove your stuff is reliable<br>
and (B) it probably isn't.<br>
<br>
With RPF, the corner cases you're looking for are: what situations<br>
would cause a packet to come from the wrong interface? For example, if<br>
you had some sort of routing loop where router A thought it could get<br>
to a destination via router B but router B thinks that destination<br>
unreachable so it returns the packet to its default route at router A.<br>
RPF then drops the packet because router B isn't an acceptable source.<br>
That's a corner case for RPF but it's an acceptable case because the<br>
packet would be dropped regardless.<br>
<br>
Another corner case with strict RPF is that your best route to a<br>
destination is transit C but a packet with that source arrives from<br>
transit D. That's broken, it causes significant problems for the<br>
network and as a result it constrains you to not use strict RPF in<br>
network scenarios where that's possible.<br>
<br>
Loose mode RPF tries to overcome the limitation by saying: as long as<br>
there's a route announced from D we'll accept packets from D even if C<br>
is the best route.<br>
<br>
<br>
So loose mode changes the nature of the corner cases you're looking<br>
for. Instead of looking for situations where the packet came from<br>
somewhere other than the best route, you're looking for situations<br>
where the packet came from an interface that advertises no return<br>
route at all. What are these situations?<br>
<br>
You may have gotten a packet from a reciprocal peer whose customer has<br>
told them not to advertise their route to you. Your peer isn't<br>
policy-routing deep in their core, so no matter what their customer<br>
instructs their packets to you will follow your peer's preferred path.<br>
If you use loose RPF there, you will black-hole that network's<br>
packets.<br>
<br>
You may have gotten an ICMP TTL expired from a router on a distant<br>
peering lan whose operator doesn't announce the lan's route for<br>
security purposes. After all, those routers don't need to be reached<br>
from the Internet. If you lose that packet, traceroute fails to reveal<br>
the hop.<br>
<br>
You may have gotten an ICMP fragmentation needed message from a router<br>
on the same distant peering lan. If you drop that packet, path MTU<br>
discovery fails and everything beyond that router is unreachable with<br>
TCP.<br>
<br>
So you might want to consider whether any of these corner cases is<br>
activated by the way you use loose mode RPF.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
-- <br>
William Herrin<br>
<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a><br>
<a href="https://bill.herrin.us/" rel="noreferrer" target="_blank">https://bill.herrin.us/</a><br>
</blockquote></div>