Re: BCP38 For BGP Customers

[Douglas Fischer <fischerdouglas () gmail com>]

I also have this concern about Spoofing coming from Downstreams.

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!
And I feel sad to have to say that.

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.

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.
(Yes, I know it's hard to accept that...)
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.

With this method of a Policy-Filter based on the same Prefix-List as BGP
and a rate-limit that doesn't match the prefix-list you won't block 100% of
the spoofed packets that might come from a downstream, but it certainly
will. block an eventual DDoS vector coming from this interface.
It is worth remembering that your neighborhood router with Downstream has
to support this type of filtering in high capacity. And it is almost
certain that only hardware based filtering scenarios will handle this.

Em seg., 7 de nov. de 2022 às 16:23, Charles Rumford via NANOG <
nanog () nanog org> escreveu:

> Hello -
>
> I'm are currently working on getting BCP38 filtering in place for our BGP
> customers. My current plan is to use the Juniper uRPF feature to filter
> out
> spoofed traffic based on the routing table. The mentality would be: "If
> you
> don't send us the prefix, then we don't accept the traffic". This has
> raised
> some issues amongst our network engineers regarding multi-homed customers.
>
> One of the issues raised was if a multi-homed BGP customer revoked a
> prefix from
> one of their peerings, but continued sending us traffic on the link then
> we
> would drop the traffic.
>
> I would like to hear what others are doing for BCP38 deployments for BGP
> customers. Are you taking the stance of "if you don't send us the prefix,
> then
> we don't accept the traffic"? Are you putting in some kind of fall back
> filter
> in based on something like IRR data?
>
> Thanks!
>
> --
> Charles Rumford (he/his/him)
> Network Engineer | Deft
> 1-312-268-9342 | charlesr () deft com
> deft.com


-- 
Douglas Fernando Fischer
Engº de Controle e Automação