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

[Job Snijders via NANOG <nanog () lists nanog org>]

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/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/nanog () lists nanog org/message/TB3IN5DDCIJ756ZHEBBG7VZCFEWPLYTT/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/LHXZO7FKXB7FXPE5DIH7KNOMFNXKSDLI/