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/nanog@lists.nanog.org/message/DX3HDX2E... [3]: https://bgpfilterguide.nlnog.net/guides/reject_invalids/ [4]: https://www.kentik.com/blog/how-much-does-rpki-rov-reduce-the-propagation-of... [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/nanog@lists.nanog.org/message/TB3IN5DD...