Boston Internet Exchange

The BOSIX, IRR and RPKI

As you may have seen, we recently deployed route servers to the Boston Internet Exchange (BOSIX). If you’re unaware of what route servers are and what benefit they impose, you can read more about that here: BOSIX Route Servers. In implementing our route servers, we have decided to implement route validation using IRR as mandatory, and are working toward RPKI validation as optional, though RPKI is not implemented at this time. This guide will help you understand what you need to know about IRR, and how we’re using it.

What is IRR and RPKI?

When thinking about how we might best implement route servers in a safe manner, we considered two features: integration with the Internet Routing Registry (IRR) and Resource Public Key Infrastructure (RPKI). The IRR is a distributed registry of routing information such as autonomous system numbers (ASNs) and prefixes submitted by service providers and other companies to regional Internet registries (RIRs) such as ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC. Using the IRR, network operators can validate that entities proclaiming to own a particular ASN and prefix do in fact own those assignments. Accordingly, operators can then build rules that only allow the acceptance of validated routes. This helps to ensure the stability of networks upon which prefixes are exchanged, such as the BOSIX.

The IRR is not imperfect, however. Information is submitted by humans, and the IRR is maintained by humans. Humans make mistakes. Information sometimes becomes stale. Sometimes information is missing completely. RPKI is an effort to augment the safety and validation of prefixes by providing a mechanism to cryptographically sign records called Route Origin Authorizations (ROA). This model is built on a chain of trust, not terribly dissimilar to how Certificate Authorities function today. There are challenges with RPKI, however, some of which have to do with legal concerns. Cloudflare has an excellent article on these challenges and the differences between IRR and RPKI, and it’s worth a read.

What does IRR enforcement mean for BOSIX participants?

Today, it is likely that you peer with individual BOSIX participants. This is administratively cumbersome, but a finer granularity of exchanged prefixes is possible, as participants maintain well-defined relationships. In order to solve the administrative burden while adding security for route validation, we’ve deployed route servers that have been configured to only accept routes that have been validated against their ASNs in the IRR as maintained by Merit RADb. Twice daily, we query the list of configured ASNs against the IRR, check any changes for sanity, and push those updates to the route servers. If your prefixes are not properly recorded in the IRR, they will not be accepted for advertisement by our route servers.

What does RPKI optional mean for BOSIX participants?

RPKI validated routes have three states: valid, invalid, and unknown.

Valid records are those that have been found in the RPKI caching server and verified as accurate—that is, the prefix, prefix length, and AS match the records that have been signed. Our route servers accept valid records.

Invalid records have been found in the database, but what’s being advertised does not match with the signed entry. Our route servers reject invalid records.

Unknown records have not been found in the database. This is the most common type of record presently found, as RPKI adoption remains low at present. Our route servers accept unknown records.

Upon classification of the validated records, our route servers tag the prefixes with the following well-known extended BGP communities:

Valid: 0x4300:0.0.0.0:0

Unknown: 0x4300:0.0.0.0:1

Invalid: 0x4300:0.0.0.0:2

BOSIX participants can choose whether to accept valid or unknown records. Invalid records are rejected, and not advertised to other participants.

For more information on record states, see: https://tools.ietf.org/html/rfc6811.

Because of the aforementioned issues with RPKI, we have chosen not to strictly enforce the acceptance/rejection of RPKI validated routes.

What are the current prefixes associated with each ASN?

For a list of every BOSIX participant, please see: https://www.markleygroup.com/services/boston-internet-exchange/peering.

We publish the output of our query to our Github page, which you can access here: https://github.com/markleygroup/bosix.

If you do not see your prefix there, then it isn’t being accepted by our route servers.

I don’t see my prefix list in your Github repo. How do I get it added?

You must register your ASN and associated prefixes with a regional RIR’s IRR database. This can generally be done by logging into the control panel for your RIR and submitting the required information, though details for each RIR vary. For more information, please see:

ARIN: https://www.arin.net/resources/manage/irr/userguide/
RIPE NCC: https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-in-the-irr
APNIC: https://www.apnic.net/about-apnic/whois_search/about/what-is-in-whois/IRR/
LACNIC: https://prensa.lacnic.net/news/en/routing/lacnics-irr-begins-operating
AFRINIC: https://www.afrinic.net/internet-routing-registry

What routes are filtered?

Besides invalidated routes, we will not accept the following:

Default routes (0.0.0.0/0; ::/0);

RFC1918 address space (private networks such as 10.0.0.0/8; 172.16.0.0/16; 192.168.0.0/24);

BOGON networks (see: https://ipgeolocation.io/resources/bogon.html);

IPv4 routes longer than /24;

IPv6 routes longer than /48;

Routes tagged with the extended BGP community 0x4300:0x0:0x2, indicating invalid RPKI prefixes.

I have an issue with another participant on the BOSIX. How do I get in touch with them?

Generally speaking, participant information is registered in PeeringDB
. Registered network operations can look up provider information and obtain contact information.

 

Steve Zuromski | CIO, VP of IT | Bridgewater State University

“With our growing use of the Internet, being able to peer directly with the likes of Netflix, Akamai, Microsoft and Apple on the Boston Internet Exchange has been huge for us. For a flat access fee for a 10 gigabit pipe, we avoided having to double our Internet bandwidth.”

Read the case study.