Is the LoA DoA for Routing

By Carlos Friaças, Michael Smith, with contributions by netsec-sig members
Friday, December 22nd, 2023

Back in the early days of the Internet, when everybody knew everybody, the way that you validated yourself to a Certificate Authority (CA) for an X509 certificate for Secure Sockets Layer (SSL) was to send a fax on company letterhead. This seems like an incredibly quaint practice today, a relic of a more naive past. However, when it comes to authorizing routing changes, some network operators are still following a functional equivalent of this long-abandoned practice, and inheriting the security risks associated with it.

That practice is a Letter of Authorization (LOA). It is basically a document signed by someone and is used for many purposes, including authorizing a 3rd party to make routing announcements on your behalf. It’s similar to a Limited Power of Attorney. In this blog post, we will explain how we came to use LOAs, why they should not be considered best-practices for routing policy, and how Resource Public Key Infrastructure (RPKI) 1, 2 should be the go-to for replacement.

One of the critical foundations of the Internet is the registration and distribution of unique public Internet Protocol (IP) addresses and network blocks. This is generally not something that occupies the thoughts of security teams – someone registers a network block, addresses are configured on routers, the routes are advertised via Border Gateway Protocol (BGP), the traffic flows to its destination address, and everyone is happy. However, assuming that network traffic goes to the appropriate destination is an assumption that is not always correct. Hijacks do happen on a daily basis according to Cloudflare’s Radar 3, and we have seen BGP and routing authorization abused in several notable incidents.4

Originally, when the Internet was small, IP blocks were registered through a worldwide centralized registry. That evolved over time to three regional registries and then to our current model with five regional internet registries (ARIN in North America, RIPE NCC in Europe Middle East and some parts of Central Asia, APNIC in Asia-Pacific, LACNIC in Latin America, and AFRINIC in Africa).

The main operating principle behind this global IP registration and distribution system is that everyone is able to understand who is really the legitimate resource holder for any given IP block or address and can configure routes and security policies appropriately. The system wasn’t created perfectly from scratch with built-in security controls, and there are still a few public databases (the Internet Routing Registries, or IRRs) that allow anyone to add records without proper identification and authorization.

Where this becomes a problem is when a network operator needs to know that the IP block a customer is asking to propagate in fact belongs to that customer. Or if the customer is not the registered owner of the block, that the rightful owner has given that authorization to the customer to route traffic on their behalf.

This brings us back to the practice of using the LOA. LOAs are used for authorizing some types of work such as standing up network circuits and wiring cross-connects inside a datacenter where they function as a very limited statement of work without involving a third party. Some years ago, routing authorization was exclusively done through LOAs, which were just printed on pieces of paper or digitally-signed documents. However, these LOAs can be forged, as easily as a signature can be forged on a piece of paper. The practice of accepting LOAs for routing allows a malicious actor the ability to hijack network traffic for a wide variety of evil purposes, ranging from sending spam to eavesdropping on traffic.

Today, there is a secure alternative that has deprecated the use of LOAs for routing. Ten years ago, a cryptographic ecosystem, RPKI, was created in Request for Comments (RFC) 6480, “An Infrastructure to Support Secure Internet Routing”5, and extended in RFC6810, “The Resource Public Key Infrastructure (RPKI) to Router Protocol”6. RPKI is anchored on the five regional internet registries and provides a digital means, called Route Origin Validation (ROV)7, outlined in RFC6811, “BGP Prefix Origin Validation”8, to validate the authorization over any given IP block using public-key cryptography.

For example, if a network operator’s customer is not the owner of an IP block and they want the network operator to announce or propagate a route to the network block on their behalf, the rightful owner can create a cryptographically-signed object in RPKI called a Route Origin Authorization (ROA) that points to the network operator’s Autonomous System Number (ASN) and the destination IP block. This allows the network operator (and their peers) the ability to validate that their customer is authorized to request routing on the IP block owner’s behalf.

Network operators are using RPKI because it makes sense. According to the National Institute of Standards and Technology (NIST) RPKI monitor9, 47% of routes have been validated by RPKI. This level of adoption implies that we have reached a watershed point where we can now require that all network prefixes are validated with ROV. There was even a poll and thread on the North American Network Operator’s Group (NANOG) email distro inquiring if it was time to replace LOA with ROA.10

So, what can security teams in a network operator do to participate in RPKI?

What can you do if you are the owner of a network block?

With the current level of RPKI adoption, now is time to adopt it as the best current practice, to discontinue the usage of LOAs for authorization of routing, and to instead rely on ROV, ROAs, and the cryptographic trust we all can obtain from them!


References:

  1. https://www.arin.net/resources/manage/rpki/^
  2. https://www.apnic.net/community/security/resource-certification/^
  3. https://radar.cloudflare.com/routing^
  4. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/^
  5. https://datatracker.ietf.org/doc/rfc6480/^
  6. https://datatracker.ietf.org/doc/rfc6810/^
  7. https://www.manrs.org/2020/10/what-is-rov/^
  8. https://datatracker.ietf.org/doc/rfc6811/^
  9. https://rpki-monitor.antd.nist.gov/^
  10. https://seclists.org/nanog/2023/Nov/73^
  11. https://blog.apnic.net/2022/04/06/how-to-installing-an-rpki-validator-2/^
  12. https://www.arin.net/resources/manage/rpki/tal/^_
  13. https://www.arin.net/resources/manage/rpki/roa_request/^