BCP38 For BGP Customers

Tue Nov 8 01:43:21 UTC 2022

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221107/70f717e9/attachment.html>