ROA: the key to route verification on the network

The Internet of today and tomorrow is beginning to be built on the basis of a certified relationship of trust, in which its autonomous entities and systems collaborate to create a more secure and resilient digital ecosystem. This redefinition of trust is crucial in a world where the BGP routing protocol, a pillar of Internet communication that has shown various vulnerabilities and weaknesses, allows malicious redirects and traffic manipulations to be carried out.

In response to these threats, Routing Public Key Infrastructure (RPKI) has established itself as a foundational security architecture. Adopted globally by Regional Internet Registries (RIRs), it provides a framework for route verification and authentication, mitigating the risks associated with routing.

Route Origin Attestations (ROAs), the cornerstone of RPKI, are digitally signed documents that accurately correlate a set of IP prefixes with the autonomous systems (ASs) authorized to originate these prefixes in BGP announcements. The technical specification of ROA is introduced in RFC 6482, which provides a detailed framework for its implementation and use.

Basic operation

The operation of ROA is simple to understand: upon receiving a prefix ad via BGP, an autonomous system can verify whether the entity originating the ad and the length of the prefix (maxLength) match what is recorded in the RPKI. If there is a match, the BGP ad is recognized as valid. If there are discrepancies – either because it originated from a different autonomous system or because the declared maximum prefix length is violated – the BGP ad is categorized as invalid. In addition, a third status is introduced for situations where the ad is not supported by any ROA, i.e., there is no record of it in RPKI; In such instances, the status is designated as 'unknown' or 'not found'.

- Example of creating an ROA -

The maxLength parameter in a ROA is crucial, as it defines the maximum length of prefixes that the autonomous system can advertise. However, it is an optional parameter, so if it is not specified, only the exact prefix specified in the ROA can be advertised.

Let us see how the parameter works with some examples. Let us imagine an ROA with a prefix like 203.0.113/24 and a 26-bit maxLength. This means that the default mask is made up of the first 24 bits of the IP address, and that the authorized autonomous system can advertise more specific prefixes, with a maximum mask of 26 bits. Let us take a look at some situations that could occur according to the acceptance of route ads from that AS, with the parameters mentioned above:

• 203.0.113.0/25: This subnet covers IP addresses from 203.0.113.0 to 203.0.113.127. This is valid because the size of the netmask (25 bits) ≤ maxLength (26 bits).
• 203.0.113.128/25: This is the second resulting subnet and covers IP addresses from 203.0.113.128 to 203.0.113.255. It is obtained by modifying the prefix and a 25-bit netmask.
• 203.0.113.0/27: With a larger netmask we would have smaller, more specific subnets within 203.0.113.0/24. However, it is not allowed to advertise this prefix, because the value of the mask exceeds the maxLength allowed by the ROA (27 > 26).

Main challenges

According to some researchers, more than 5% of ROAs in RPKI repositories were conflicting with legitimate, persistent BGP ads in 2020, and close to 30% were misconfigured. This could lead to ASs discarding legitimate BGP route ads, disconnecting thousands of valid destinations, and leaving the sender unprotected against prefix hijacking. Let us look at some of the most important issues that can lead to security incidents:

• Insecure access to ROA management: Management interfaces used by network operators to manage ROAs may have security gaps. These breaches can facilitate unauthorized access due to configuration flaws, vulnerabilities in components or APIs, among others. Improper access can allow malicious actors to alter ROA, compromising the validity and operability of network paths.

• Improper use of maxLength in RPKI: As we have seen, when incorporated into a ROA, it allows for the authorization of subnets within a larger IP address block, providing flexibility in BGP route announcements. However, an improper implementation of maxLength can lead to the authorization and propagation of more IP prefixes than are actually required, opening significant security gaps in the network.

  An attacker with knowledge of this configuration could exploit this vulnerability, performing route hijacking to advertise more specific subnets within the allowed range. These fraudulent ads, being consistent with ROA, can be accepted by other autonomous systems.

• Inconsistent ROAs in repositories: Eliminating outdated or redundant ROAs is considered a best practice for maintaining accuracy and security in the RPKI infrastructure and ultimately the Internet routing system. However, the deletion process can be complex due to the challenges associated with synchronizing information in distributed systems. When a ROA is deleted or modified, it is crucial that those updates are propagated and reflected in a consistent and timely manner across all repositories and systems that rely on this information for BGP route validation.

  However, caching systems that temporarily retain ROA information may experience delays in updating data. This means that ROAs that have already been modified or deleted may persist, which in turn can lead to conflicts or inconsistencies in the route validation process. Consequently, actively reviewing ROAs is essential to maintaining security and consistency in Internet routing. As in the previous case, the creation of ROAs with adequate validity should be prioritized.

Tips for secure deployment

MANRS provides a number of best practices to prevent the most common and damaging routing incidents, such as IP spoofing and bad route propagation. The guide called 'Common ROA Management Requirements and Security Standards for Operators of RPKI Services (ORS)' is a crucial resource for RPKI service operators in the secure implementation of ROA. Here is a summary of these practices, which could help mitigate the most important risks.

• Management of ROA parameters: the correct use of ROA parameters is vital to ensure integrity in network path advertisements. For efficient and secure administration, service operators should automatically renew all ROAs at least 90 days before their expiration and ensure a minimum validity of two years for each, thus minimizing expiration and certificate compliance issues. It is also crucial that network operators receive alerts of ROA expiration or renewal, allowing for a prompt response and necessary adjustments, contributing to a more secure and resilient network. In addition, it is imperative to correctly configure the maxLength attribute, authorizing only the necessary IP prefixes and avoiding the exposure of unused or unassigned IP addresses. In this sense, the creation of minimum ROAs should be prioritized.
• API and security: secure ROA management, especially in network operators with large address spaces, demands robust and secure tools to properly maintain routes. A key solution for this is APIs, which facilitate automated and scalable ROA management. However, these APIs must be designed and provided under security standards. The ORS, tasked with delivering these APIs, must ensure that any interaction through these interfaces is secure. In addition, it is vital that the tokens used to access these APIs are not only protected and encrypted, but also have limitations, both in validity time and access levels. This precaution reduces the risk of unauthorized access or malicious actions, ensuring that ROA management occurs in a secure and controlled environment.
• Safeguards for changes in ROA: changes to an ROA can have significant implications on the planning and operation of network paths. As such, ORS must meticulously validate any proposed modifications to an ROA to prevent potential adverse behavior. If a change to an ROA can override existing BGP ads, blocking warnings should be issued, although network operators should have the power to manually override these warnings if they understand and accept the associated risks.
• Infrastructure health metrics: infrastructure reliability is crucial. ORS should ensure that stakeholders can have a significant level of visibility into the health and health of the routing service. This level of transparency is crucial for monitoring the integrity of the system and identifying any inconsistencies or anomalies in ROAs. Having effective alert and notification systems in place that inform stakeholders of any service degradation or anomaly detected in real-time is critical.

Conclusion

ROAs, within the RPKI framework, become a pillar to face the challenges and threats of Internet security, providing a terrain for authentication and route verification and, therefore, for risk mitigation in routing. But a certification system does not make the infrastructure completely secure: vulnerable management systems, misuse of parameters or configuration failures are some of the challenges that arise. The adoption of good security practices, as we have seen, helps to maintain the integrity and consistency of these certified objects.