Re: Securing EBGP while getting rid of big IRR-based prefix-list-filters (Was: How long AS-PATH policies have you used)

Some additional negatives of building prefix-lists out of AS-sets and
route objects:

* AS-sets make it impossible for ASes to specify different sets of
prefixes that they intend to announce to different neighboring
networks. Each ASN only maps to a single set of route objects. A
possible byproduct is that ASes may specify (a single) loose filter to
(all) their neighboring networks.
* Route objects cannot specify prefix-length ranges. This complicates
the management of route objects. For example, if one has a /44 IPv6
prefix that they need to announce at /48 granularity, they have to
maintain 16 route6 objects.
* To aggravate the above, bgpq4 does not generate range-based filters
when building prefix-lists by default (but you can pass -A for that).
This results in prefix lists that are larger than necessary. I bet the
routers optimize with aggregation or it would be a gigantic slog, but
the shorter list is still preferable for inspection.
* There is limited, if any, validation of route objects for prefixes
without an ROA.

I wish peers would use RS-PEERING-TESTBED instead of AS-PEERING-TESTBED...

On Thu, Feb 26, 2026 at 6:41 AM Job Snijders via NANOG
<[email protected]> wrote:
>
> Dear all,
>
> Securing one's EBGP perimeter is a challenge: how to do it?
>
> (Some slides: https://bsd.nl/publications/irr_out_rpki_in.pdf)
>
> Much of the information used to construct safe pass/nopass EBGP filters
> comes in unwieldly formats and from questionable provenance. I can share
> some detail of the approach I implemented at my previous $employer,
> perhaps it'll help some of you get rid of excessively large IRR-based
> prefix-filters! :-)
>
> Quick recap - here is what we're protecting against:
>
> A) Mis-originations (the digits on your keybaord are super close to each
>    other)
> B) Unauthorized more-specifics (e.g. some government instructs their
>    incumbent telco to kill access to 1.1.1.1/32 or some other IP)
> C) Route leaks (an operator turns up a second EBGP session on their
>    non-RFC8212 router and BOOM, a route-leak could spring into existence)
>
> What doesn't work well: generating an 'allowlist' (a prefix-list-filter)
> by recursing a given IRR AS-SET into its members and doing reverse
> lookups to obtain the set of "route:" "route6:" objects to construct a
> list of prefixes. The core problem is that any AS-SET can reference any
> other AS-SET and the resulting excessively large lists of prefixes are a
> PITA to upload to routers AND WORSE: are a very expensive "allow any any".
>
> What I've found to work quite well:
>
> - Imposing good ole' maximum prefix limits: when a peer or customer
>   starts announcing 100x or 1000x the number of routes they normally
>   announce, usually something somewhere is wrong and it is safer to
>   automatically terminate the EBGP session. This safety mechanism helps
>   with issue (C)
>
> - "BGP OPEN Roles" (RFC 9234 / OTC attribute). This is a safety
>   mechanism (perhaps surprisingly) does _not_ rely on either IRR or
>   RPKI. RFC 9234 is extremely easy to implement and deploy. The trick is
>   that both sides of the EBGP session have to agree with each other what
>   they are to each other (in context of the Gao-Rexford model [1]). It
>   is opportunistic: if one side doesn't support it, the other side can
>   still do its part. At Fastly this helped identify and resolve a bunch
>   of configuration issues in peering sessions, and it stopped a lot of
>   leaking, even with very limited global deployment! At YYCIX we saw it
>   stop IX-to-IX leaks while the networks in the middle didn't even
>   support it (yet) [2]. The BGP OPEN Roles mechanism offers
>   per-EBGP-session-per-NLRI granuarlity and greatly helps with issue (C).
>
> - The practise of rejecting RPKI-ROV invalid routes is effective for
>   addressing issues (A) & (B). This practise is popular amongst large
>   carriers and IX route server operators. Even though there are hundreds
>   of thousands of ROAs in the global system, loading those into routers
>   is a breeze: the binary RPKI-To-Router (RTR) provisioning protocol is
>   quite effortless compared to using TCL to upload megabytes of
>   prefix-filter in the vendor-specific language.
>
> - 'Peerlock' [5] / 'peerlock-lite' [6] : when you as operator _know_
>   that certain ASNs should NEVER appear anywhere in the AS_PATH behind
>   certain EBGP sessions, why not just outright block those? Proven tech
>   albeit a bit involved to deploy and maintain, so a spiritual successor
>   appeared: ASPA
>
> - ASPA very much helps with issue (C). There already are more than a
>   1000 AS holders [7] who publicly declared what the ASNs of their
>   authorized upstream are. From this information it can be inferred what
>   paths are plausible and which paths are not plausible. Implausible
>   paths are rejected (just like you'd reject ROV-invalids). ASPA uses
>   the same pipelines as are used for ROAs, so we capitalise on previous
>   investments. ASPA can easily be deployed on IX route servers using
>   open source BGP implementations [8], and most major commercial
>   hardware chassis-oriented vendors have it on their roadmap.
>
> In summary: use maximum prefix limits, reject ROV-invalid & ASPA-invalid
> routes, take advantage of the RFC 9234 OTC attribute, and maybe use
> Peerlock. Stop using IRR-based prefix-lists. IRR needs to be sunset.
>
> Vendors can help their users: for example, in the OpenBGPD implementation
> the 'role' configuration keyword helps set up *both* ASPA and RFC9234 in
> one go! This is super convenient for the operators.
>
> If the above guidance is followed, the resulting router configurations
> are VERY concise and don't require a lot of ongoing maintenance (because
> the parts of the config that frequently change are provisioned through
> RTR); but most importantly, these practises greatly help improve the
> safety and reliablity of day-to-day routing operations.
>
> Kind regards,
>
> Job
>
> [1]: https://people.eecs.berkeley.edu/~sylvia/cs268-2019/papers/gao-rexford.pdf
> [2]: https://lists.nanog.org/archives/list/[email protected]/message/DX3HDX2EXOUZJEGCS7OY7NP6D3NETGJN/
> [3]: https://bgpfilterguide.nlnog.net/guides/reject_invalids/
> [4]: https://www.kentik.com/blog/how-much-does-rpki-rov-reduce-the-propagation-of-invalid-routes/
> [5]: https://arxiv.org/abs/2006.06576
> [6]: https://bgpfilterguide.nlnog.net/guides/no_transit_leaks/
> [7]: https://console.rpki-client.org/aspa.html
> [8]: https://lists.nanog.org/archives/list/[email protected]/message/TB3IN5DDCIJ756ZHEBBG7VZCFEWPLYTT/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/[email protected]/message/LHXZO7FKXB7FXPE5DIH7KNOMFNXKSDLI/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/XWABTBQHTBF3J6WW44WNRNT4L3MRROTA/