Mailing List Archive

1 2  View All
Re: BCP38 For BGP Customers [ In reply to ]
On Thu, Nov 10, 2022 at 10:27:02AM -0800, William Herrin wrote:
> On Thu, Nov 10, 2022 at 10:08 AM Grant Taylor via NANOG <nanog@nanog.org> wrote:
> > I wonder if Feasible Path uRPF or Enhanced Feasible Path uRPF might help
> > the situation. However I suspect they both suffer from the FIB != RIB
> > problem and associated signaling.
>
> Hi Grant,
>
> That's a fairly good way to think about it. BGP knows -a- path and
> sometimes it knows more than one but it simply doesn't have signal on
> the totality of feasible paths for a particular IP address. No
> distance-vector protocol can.

There's more than this going on as well, because there's a
number of other things going on, the IETF has created a SAVNET working
group to see if it's possible to do something here, and there's also
work in the SIDROPS WG that isn't yet adopted but may be.

The intent would be to include things like the ASPA work with
the SIDR/RPKI work to permit a proof to exist for SAV purposes. This
may not include all the p2p IP space that would exist between the
networks, and if one doesn't publish ASPA data for things like all those
cloud on-ramp type services, you may end up with traffic blackholed or
other side-effects.

Simply put, SAV/BCP-38 et al is hard, and nearly impossible when
you get much further away from the subnet that traffic originates from.

- Jared

--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: BCP38 For BGP Customers [ In reply to ]
We’ve seen Juniper EX9ks implement uRPF in such a way that if I have two (load-balanced) BGP connections to the EX9k, and uRPF is turned on facing me, I immediately experience ~50% outbound packet loss.
Methinks the EX9ks apply uRPF a little too close to the hardware and ignore the RIB.
-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca<https://www.merlin.mb.ca/>
[cid:image002.png@01D8FE60.27B812C0]Chat with me on Teams<https://teams.microsoft.com/l/chat/0/0?users=athompson@merlin.mb.ca>

From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Mike Hammett
Sent: November 8, 2022 2:29 PM
To: William Herrin <bill@herrin.us>
Cc: nanog@nanog.org; Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: BCP38 For BGP Customers

"Reverse path filtering literally says don't accept a packet from
somewhere that isn't currently the next hop for that packet's source
address."

FIB or RIB?

I knew of uRPF as available over an interface, per the routing table, not best path available. Or is that implementation dependent?



-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

________________________________
From: "William Herrin" <bill@herrin.us<mailto:bill@herrin.us>>
To: "Grant Taylor" <gtaylor@tnetconsulting.net<mailto:gtaylor@tnetconsulting.net>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Sent: Tuesday, November 8, 2022 2:01:49 PM
Subject: Re: BCP38 For BGP Customers

On Tue, Nov 8, 2022 at 8:40 AM Grant Taylor via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote:
> Maybe it's the lack of caffeine, but would someone please remind /
> enlighten me as to why uRPF is a bad idea on downstream interfaces?

Hi Grant,

Two words: asymmetric routing.

If the downstream network is architected in such a way that there's
more than one path in and out of their network then there's no way to
guarantee that any particular router believes the forward path to that
network goes to a particular next hop. It can currently map to any
next hop that goes in the direction of one of the valid paths. That
routing is completely independent of how next hops are selected in the
other direction. Packets can travel in one path and out another.

Reverse path filtering literally says don't accept a packet from
somewhere that isn't currently the next hop for that packet's source
address. When it's possible for the forward route to point a different
direction than the one from which valid packets are received, that is
the wrong thing to do. In fact, it breaks the network.

Useful automated reverse path filtering can ONLY be used when there is
exactly ONE valid path to which and from which packets can be
received. This is where strict mode uRPF actually works.


> N.B. Maybe I'm thinking more a varient of uRPF wherein if I have a route
> to the source from the interface in question. Thus not uRPF-strict
> (active route) nor uRPF-loose (route on any interface).

Even if a particular router happens to have RIB entries for all the
valid paths to a host (a sketchy proposition at best), only one such
entry will be stored in the FIB where uRPF looks to make its filtering
decision.

As for loose mode, it's basically useless in a BCP38 discussion. Loose
mode only filters bogons. It doesn't prevent impersonation of any IP
address currently routed in the system and doesn't do anything at all
on a router with a default route.

Regards,
Bill Herrin




--
For hire. https://bill.herrin.us/resume/

1 2  View All