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 | charl...@deft.com > deft.com > -- Douglas Fernando Fischer Engº de Controle e Automação
