Our research agenda for improving routing security

A new line of research aimed on on extending BGP security

Security lock symbol on circuit board

The Border Gateway Protocol (BGP) and the DNS are two of the core protocols of the Internet. The DNS tells us where we can find services and information on the Internet, and BGP tells us how we can get there. Since SIDN’s role as a registry and DNS operator for the .nl top-level domain critically depends on BGP, we recently started an additional line of research on extending BGP security. In this blogpost, we discuss the three research topics we will focus on: the resilience of the infrastructure that provides the keying material for BGP security (RPKI), the deployment of BGP path security (BGPsec), and routing security for customer networks.

Some of the problems with plain BGP

The current version of BGP is BGP4Link opens in new tab. It connects autonomously managed networks, called autonomous systems (ASes). BGP does so by propagating routing information through the Internet in a distributed and decentralised way. ASes establish peering relations between each other based on trust and economic incentives. The global exchange of routing information relies on the transitive trust that originates from those peering relations.

Every AS can claim new routes on the Internet, sometimes with disastrous consequences. For example, an AS can intentionally or accidentally claim that it is the origin of an IP address range or that it lies on a path towards a destination AS. Normally, it's not a problem that an IP address range can be announced from multiple ASes, because it allows the owner of a given prefix to migrate between ASes or distribute resources to increase resilience. However, the main problem here is that BGP in its most basic form does not enable an AS to check whether another AS is the rightful claimant to an IP prefix. Therefore, if such a claim is false, it might lead to the unavailability of the affected address range, and could enable the “hijacking” AS to eavesdrop on traffic sent towards IPs within the address range, or even to impersonate services.

Network operators implement filters to prevent false routing information from propagating. For example, they can make sure that they only accept routes from customers who are responsible for those routes. However, such filters are not always implemented correctly and are not sufficient because information often cannot be verified. Since the Internet relies on the correctness and stability of the information exchanged via BGP, the Internet community has developed several protocols that can improve the security of BGP and address the problems described. In this document, we briefly introduce the protocols in question, and we discuss where, in our opinion, research is needed to further improve the protocols and help their deployment.

An overview of BGP security

The protocols discussed here rely on the Resource Public Key InfrastructureLink opens in new tab (RPKI), which allows owners of IP address space and ASes to make cryptographically verifiable claims about their resources, like IP addresses or AS numbers. You can find an overview of RFCs related to the RPKI hereLink opens in new tab.

The first and most widely deployed objects in the RPKI are Route Origin AuthorizationsLink opens in new tab (ROAs), in which a resource owner cryptographically ties its prefix to a set of ASNs which are allowed to originate that prefix. All five Regional Internet Registries (RIR) support the creation of ROAs. ASes that validate and filter based on ROAs can prevent events where another AS falsely claims to be the origin of a prefix – a validation process which is called Route Origin Validation (RoV). The impact of this solution is, however, limited by the number of signed ROAs. Today, the number of ROAs is on the riseLink opens in new tab and the number of networks dropping prefixes that violate a ROA is increasingLink opens in new tab. Note that routers located at the edge of the Internet often need to rely on RoV implemented by their upstream providers because they do not receive the full BGP table and therefore cannot perform RoV.

Whereas ROAs associate IP prefixes with sets of originating AS numbers, Autonomous Systems Provider AuthorizationLink opens in new tab (ASPA) objects limit spoofing and impersonation of ASNs. ASPA is not yet standardised but is intended to enable ASes to publish in the RPKI through the provider AS that they use to connect to the rest of the Internet. Hence, ASPA can prevent an AS falsely claiming to be directly connected to an AS that publishes ASPA objects.

Finally, Border Gateway Protocol SecurityLink opens in new tab (BGPsec), standardised in RFC 8205, allows routers on the Internet to verify that received routing information was actually propagated via the claimed AS path. The router can then be sure that the path presented in the BGP update message actually exists. The system requires routers along the path to sign the BGP update with their private keys, including the signature of the previous BGP hop. That creates a chain of trust that enables routers to verify end-to-end AS paths. BGPsec requires network operators to publish the public keys of their routers in the RPKI.

The research community has come up with various measures for improving BGP security as well, for example BGP-iSecLink opens in new tab. However, there are no efforts to standardise them at the IETF, which reduces the chance of adoption. We don't therefore consider them in this blog.

Our research agenda for routing security

We want to focus on three aspects of BGP security: the resilience of the RPKI, the deployment of BGPsec, and tools and insights that help operators to respond to hijacks. We believe that these aspects have not gotten enough attention or are so important for the security of the Internet that they deserve the attention of as many researchers as possible.

Research area #1: RPKI resilience

The RPKI is the foundation of ROAs and ASPA objects, amongst other thingsLink opens in new tab, and it plays an important role in BGPsec. The availability and resilience of the RPKI are therefore crucial. If RPKI information were unavailable for a longer period, parties might be unable to validate ROA and ASPA objects, receive updates or fetch router certificates. That would effectively negate the protection those protocols offer and prevent routes from propagating.

For example, a prefix owner who moves between ASes might be unable to update their corresponding ROA when the RPKI is unavailable. As a result, their ROA might become invalid and validating parties might drop routes towards the AS. With RoV being deployed at scale, such scenarios might have devastating effects on the availability of the Internet.

Our objective is to identify the critical components that can influence the availability of the RPKI, assess the likelihood and impact of an outage, and what it takes to increase the resilience of the RPKI.

Examples of research questions relating to RPKI resilience:

  • What components are responsible for the availability of RPKI?

  • What would the impact be if parts of RPKI or the whole infrastructure became unavailable?

  • What events could affect the availability of critical components and how likely are such events?

  • How can we prevent such events or reduce their impact?

To answer those questions, we will carry out Internet-wide measurements of the various RPKI components and their underlying dependencies.

Research area #2: BGPsec deployment

Even though the RFCs standardising BGPsec are six years old, deployment of BGPsec remains almost non-existent. That is partly due to the chicken-and-egg problem that has haunted many security extensions to protocols in the past, such as DNSSEC.

Another reason is that the impact of BGPsec on route propagation is not well understood yet. A router sharing a route with a peer needs to sign the entire AS path in an announcement, and a router at the receiving end needs to verify that path. Those cryptographic operations can place a sizeable burden on the routers in question, especially where legacy equipment with limited processing capabilities is concerned.

Also, some BGP experts argue that BGPsec delivers the intended level of security only when it is fully deployed. Our goal is accordingly to understand how operators can achieve path security even if BGP is only partially deployed.

We have therefore formulated the following research questions:

  • What is the impact of BGPsec on the propagation of routes on the Internet?

  • If there is a negative impact, what causes the degradation in performance?

  • How can we reduce the performance impact?

  • Which ASes should adopt BGPsec to maximise the number of routes protected?

First and foremost, we want to answer those research questions by deploying and testing BGPsec in a local testbed at SIDN Labs. Recently, we also created our own test network located at NikhefLink opens in new tab. This allows us to run BGPsec experiments with parties that share our interest in routing security research and would like to peer with us.

Research area #3: Routing security for customer networks

Most networks on the Internet are customer networks, meaning that they do not provide connectivity for other networks. These networks should protect their IP prefixes, for instance by publishing ROA or ASPA objects in the RPKI. However, not all networks on the Internet validate such objects and drop invalid announcements. Hence, ROA and ASPA objects cannot prevent all possible attacks.

Various tools are available to operators to detect the misuse of their own prefixes. Examples are route collectorsLink opens in new tab or applications that build on route collectors, such as ARTEMISLink opens in new tab. Although these tools are not perfect and might not be able to detect all events, they are relatively well studied. For that reason, our goal is to help operators whose prefixes are misused to assess the impact of hijacks and take the appropriate action.

To that end, we need to understand:

  • What patterns, if any, do hijacks follow; for example, how are they carried out and what actors are involved?

  • What is the impact of a hijack on the targeted operator's network and services?

  • If the impact is “significant” (depending on the operator and service), what action should an operator take to mitigate the impact?

  • What measures can operators take to increase the resilience of their networks and services against future hijacks?

In relation to those questions, we will draw on SIDN’s own experience as a stub network operator that provides critical servicesLink opens in new tab. Possible research products include recommendations for operators and metrics for measuring the impact of routing security on their services.

Outreach

Have we missed important aspects? Do you want to collaborate on any of the topics mentioned above? We are interested receiving feedback from operators and researchers about our research agenda, and we invite you to contact us at moritz.muller@sidn.nl.

Acknowledgement: Thanks to our colleagues Jeroen Bulten and Dennis Meijer for their input.