Re: BCP38 For BGP Customers

[William Herrin <bill () herrin us>]

On Tue, Nov 8, 2022 at 9:08 PM Grant Taylor via NANOG <nanog () nanog org>
wrote:
> This thread has made me wonder if there isn't a need for a 3rd type of
> uRPF or comparable filtering wherein the incoming interface is a viable
> route in the RIB even if it's not the best route in the FIB.

Hi Grant,

Two problems here:

1. uRPF reuses the existing FIB. Either the next hop matches the source
(strict) or some entry in the FIB matches the source (loose). The hardware
"fast path" to implement the per-packet FIB is already there; all it takes
is a second lookup. Unless someone comes up with a really clever idea,
that's basically all the filtering you can squeeze out of the FIB. To do
something more, you'd have to implement an additional "fast path" in the
router that can act on every packet. That's kinda expensive.

2. BGP is a distance-vector protocol, not a link-state protocol. The
significance for filtering is that the BGP RIB on a given router does not
describe the complete state of the network. It only knows about itself and
its immediate neighbors. That's not algorithmically guaranteed to be enough
knowledge about the network to determine that a packet with a given source
address can't reasonably come from a particular interface.

Consider the following scenario:

A - B - C - D - E - A
    |
    F

B receives a packet from A to F via C. Is the packet legitimate? B can't
know because the only route to A in B's RIB is the direct connection to A.
C didn't pass E's route to A back to B because it was a longer, unpreferred
path. C might not even have received the route from D.

So even if you go to the expense of building a fast path that can consider
what's in the RIB instead of just the FIB, you don't have the information
you need in the RIB either.

Regards,
Bill Herrin

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