RPKI and IRR should be part of the prefix-list generation process, from there setup rpf-check with a fail-filter pointing to an ACL that allows source traffic matching the prefix-list and drops the rest. Although at that point you can just apply said ACL to the L3 interfaces supplying the BGP handoff.

Ryan

From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> On Behalf Of Mike Hammett
Sent: Monday, November 7, 2022 3:17 PM
To: Charles Rumford <charlesr@deft.com>
Cc: nanog@nanog.org
Subject: Re: BCP38 For BGP Customers

This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR, etc. instead of current BGP feed?

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

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

---

From: "Charles Rumford via NANOG" <nanog@nanog.org>
To: nanog@nanog.org
Sent: Monday, November 7, 2022 10:47:54 AM
Subject: BCP38 For BGP Customers

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