BCP38 For BGP Customers

Tue Nov 8 16:40:37 UTC 2022

On 11/8/22 6:28 AM, Douglas Fischer wrote:
> I also have this concern about Spoofing coming from Downstreams.

+1

> And after a lot of struggle I can say that using uRPF in strict mode per 
> interface doing FIB lookup is not a good idea!

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?

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).

> I've spent a lot of time wrestling with this issue, and the measurement 
> that matters most, which are support tickets, doesn't show good results.

Will you please share a high level of what the technical problems are?

> The best option I've found so far?
> It is to use the same Prefix-List that you use to release the routes 
> accepted in the BGP session in a Filter Policy applied in the interface 
> with the Downstream.
> Another important point to note is that you MUST NOT drop everything 
> else that doesn't match this Prefix-List.

Please clarify if there are routes that would return the packets that 
would be dropped back to your router & downstream client.

I don't understand why you would want to allow packets that couldn't 
return the same path.

As for asymmetrically routed packets, I would still expect a return path 
to exist, even if it's not utilized.

> (Yes, I know it's hard to accept that...)

#headScratching

> But put a bandwidth and PPS control on what doesn't match the 
> prefix-list, and block what exceeds.
> And why do it this way?
> Among other reasons, it is very common that Exceeded TTL responses come 
> with source IPs for private use, or IP blocks that are for public use 
> but not announced to the DFZ.

I'll argue -- possibly from a place of ignorance -- that there should 
not be any packets on the Internet at large (default free zone) to or 
from IPs not part of the Internet (DFZ).

I view the TTL Exceeded packets as errant in their non-globally-routed 
source address and as such should be dropped early / often.

Both "be liberal in what you accept and conservative in what you send" 
(Jon Postel) and "Brown M&M" (Van Halen) come to mind, as does the newer 
industry phrase "fail-fast".

-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221108/6212ed9b/attachment.bin>