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....@nanog.org> On Behalf Of Mike Hammett Sent: Monday, November 7, 2022 3:17 PM To: Charles Rumford <charl...@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 <mailto:nanog@nanog.org> > To: nanog@nanog.org <mailto: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 | charl...@deft.com <mailto:charl...@deft.com> deft.com
