large BCP38 compliance testing

Jérôme Nicolle jerome at ceriz.fr
Thu Oct 2 11:23:42 UTC 2014



Le 02/10/2014 12:28, Nick Hilliard a écrit :
> It would probably be more productive to pressurise transit providers to
> enforce bcp38 on their customer links.

This. But let me ask you, how many transit provider actually implement
strict prefix-filtering ? I've seen many using a max-prefix as their
sole defense.

Now, let's consider what you want is to match an interface ACL to
prefixes received on a BGP session runing through the same interface.
Ain't that what uRPF-strict is all about ? What are the known downsides
to uRPF-strict ?

When buying from transits, you either update your IRR for automatic
perfix-filter generation on your transit's side, or start by a "BGP over
SMTP" session. While the former could generate ACLs from a template, the
latter will be prone to human error. And still, how many of us _really_
ensure their IRRs are always up-to-date ?

Next in line : IXPs. You never really know what routes will be available
or has to be filtered when 800+ AS, most with customers also using BGP,
starts talking to the same route-server. Or maybe, the route-server
could provide a flowspec AFI to send filters AND routes simultaneously.
Would you trust it ? Will your router have enough silicon-horse-power to
match both IP _and_ L2 headers at line-rate ?

BCP38 aims at spoof prevention by filtering as close to the source as
possible. Implementation on network's edge looks to me like a tricky
one. Sharing the load amongst CPE is the best practice, and could be
considered a requirement enforced by transit providers. Or shouldn't it ?

Best regards,

-- 
Jérôme Nicolle



More information about the NANOG mailing list