| Internet-Draft | PSVRO | November 2024 |
| Jiang, et al. | Expires 29 May 2025 | [Page] |
Prefix hijacking, i.e., unauthorized announcement of a prefix, has emerged as a major security threat in the Border Gateway Protocol (BGP), garnering widespread attention. To migrate such attacks while supporting legitimate Multiple Origin ASes (MOAS), higher requirements are placed on the route origin registry. This document serves to outline the problem statement for current route origin registry.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 May 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Border Gateway Protocol (BGP) is ubiquitously used for inter-domain routing. However, it lacks built-in security validation on whether its UPDATE information is legitimate [RFC4272]. This poses concerns regarding prefix hijacking, where unauthorized announcements of prefixes can occur, simulating legitimate Multiple Origin ASes (MOAS).¶
Unfortunately, the current route origin registry, such as Internet Routing Registry (IRR) [RFC1786] and Resource Public Key Infrastructure (RPKI) [RFC6480], are not effective in distinguishing between legitimate MOAS and prefix hijacking. There is a pressing need for an verifiable route origin registry that can support registration and protection of legitimate MOAS, thereby mitigating the threats posed by prefix hijacking to the routing system.¶
This document will primarily analyze the various scenarios of MOAS and highlight the limitations of the current route origin registry. By examining these issues, our primary objective is to offer valuable insights to network operators, researchers, and policymakers for improving the security and robustness of the global routing system.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Route origin registry refers to a system that records the mapping of IP prefixes to the ASes authorised to announce them. Resource holders can register route origin mapping relationships in route origin registry by themselves or delegate to others.¶
IRR and RPKI currently offer functionalities related to route origin registry. IRRs, which have been in operation since 1995, serve as a globally distributed database for routing information. They record the binding relationship between IPs and Autonomous Systems (ASes) via Route(6) objects, which are defined by the Routing Policy Specification Language (RPSL).¶
On the other hand, the RPKI, which was developed starting in 2008, provides a formally verifiable framework. The RPKI is based on resource certificates that extend the X.509 standard. It records the mapping between IP prefixes and their authorised ASes via Route Origin Authorization (ROA) objects. These ROA objects contain essential information such as the prefix, origin ASN, and MaxLength.¶
[RFC1930] suggests that a prefix should typically have a single Autonomous System (AS) as its origin, with a few exceptions. However, CAIDA's analysis on BGP routing data [CAIDA] reveals that MOAS have become a common phenomenon. There are various reasons that contribute to the emergence of MOAS prefixes:¶
Aggregation. According to [RFC1930], aggregation could result in prefix originated from multiple possible ASes. For example, if the "Prefix 0/24" originates from ASx and the "Prefix 1/24" originates from ASy, aggregating them into "Prefix 0/23" with the originates from [ASx, ASy] may result in the loss of the specific origin AS information if the ATOMIC_AGGREGATE attributes of the aggregation announcements are not specific.¶
Business consideration. Companies often choose providers that offer high-speed and reliable data services to host their servers. For efficient resource allocation, a parent organization that owns a large chunk of IP addresses may divide its address space among one or more child organizations, which choose different providers and ask them to announce the same prefix. For example, a multi-national company may advertise its prefix from multiple locations where it has offices.¶
Multi-homing. When multi-homing occur without the use of BGP, it can result in MOAS conflicts. Assuming ASx is connected to two providers, ISP1 and ISP2. ISP1 is connected to ASx using BGP, while ISP2 is connected to ASx through static routes or Interior Gateway Protocol (IGP). Both ISP1 and ISP2 advertise prefixes that belong to ASx.¶
Internet eXchanges. When a prefix is associated with an exchange point, it becomes directly accessible from all the ASes connected to that exchange point. Each AS at the exchange point has the capability to advertise the prefix as if it originates directly from their own AS.¶
Anycast. Anycast is often employed by content distribution networks (CDNs) to direct the requests of their customers to the nearest servers, ensuring speedy data delivery to their customers.¶
Prefix hijacking and misconfigurations. A malicious AS may advertise prefixes belonging to another organization to attract its traffic. An AS may also make such annoucements unintentionally due to misconfiguration.¶
Distinguishing between prefix hijacking, misconfiguration, and legitimate MOAS can be a complex task. The challenge arises from the resemblance of these behaviors, as they often display similar characteristics. Moreover, accurately identifying and classifying these situations necessitates a route origin registry with high coverage and accuracy.¶
This section outlines several challenges faced by the current route origin registration mechanisms in distinguishing legitimate MOAS events from malicious MOAS incidents, such as route hijacking.¶
As the adoption of RPKI continues to grow, the number of address prefixes registered within RPKI is gradually increasing. However, recent reports from the Number Resource Organization (NRO) [NRO] indicate that the coverage of IP prefixes within ROAs is still relatively low, and the adoption rate of route origin validation (ROV), as measured by Mutually Agreed Norms for Routing Security (MANRS) [MANRS], is even significantly lower than the coverage of ROAs. Similarly, [IRRegularities] also notes a decreasing trend in IP Prefix coverage in certain IRRs. When focusing on MOAS (Multiple Origin AS), their coverage is significantly lower and insufficient to distinguish between legitimate MOAS and route hijacking.¶
Limited IP prefix coverage within the current route origin registry, especially for MOAS prefixes, hinders the complete validation of route announcements, significantly limiting the motivation for network operators to utilize route origin registry.¶
Based on the analysis presented in the previous sections, it is evident that relying solely on a single source of route origin registry is insufficient in route origin validation. To address this issue effectively, it is recommended to integrate the RPKI and multiple active IRRs.¶
However, it is important to note that this fusion approach may encounter several limitations. As highlighted in [IRRegularities], inconsistencies exist among the Route(6) objects across different IRRs. This inconsistency can be attributed to the chronic neglect by IRR customers. For instance, some companies may register Route(6) objects in some IRRs but fail to update them in all the route origin registries, resulting in outdated and stale Route(6) objects. Furthermore, it is observed that a higher number of IRRs exhibit lower consistency with RPKI. In practice, different networks often use different data and methodologies to perform route validation and filtering, resulting in disparate outcome, especially when ROA and IRR data conflict with each other.¶
As a result, while integrating the RPKI and multiple active IRRs can improve the effectiveness of route origin validation, it is essential to address the issues of inconsistencies between different route origin registries.¶
As mentioned in [RFC7682], the lack of certification and incentives for maintaining up-to-date data within IRRs leads to low accuracy of the information. Recent measurement [IRRegularities] reveals that IRRs with low update activity exhibit lower overlap with BGP announcements than those with high update activity. This indicates that IRRs with lower activity may contain a higher proportion of outdated and stale Route(6) objects, thereby impacting the reliability of the route origin registry.¶
RPKI is a hierarchical Public Key Infrastructure (PKI) that binds Internet Number Resources (INRs) such as Autonomous System Numbers (ASNs) and IP addresses to public keys via certificates. However, there is a risk of conflicts in INRs ownership when misconfiguration or malicious operations occur at the upper tier, resulting in multiple lower tiers being allocated the same INRs. Additionally, the existence of legitimate MOAS necessitates the authorization of binding between a prefix with multiple ASes, further complicating the issue. Balancing the protection of legitimate MOAS while minimizing risks in INRs certificates presents a challenging problem that requires innovative solutions. Furthermore, it is worth noting that RPKI Relying Parties (RPs) [RFC8897] have not yet standardized the process of constructing certificate chains and handling exceptions such as Certificate Revocation Lists (CRLs) and Manifests. This lack of standardization has resulted in different views on the RPKI records by RPs who adopt different implementations. Consequently, ASes served by different RPs may have varying validation results for the same route announcement.¶
Consequently, the absence of data validation and standardization in operations within the IRR or RPKI framework means that there is no guarantee of the accuracy of the data registered in any route origin registry.¶
The current practice in IRRs involves the use of the Near-Real-Time Mirroring (NRTM) protocol [NRTMv4] to replicate and synchronize Route(6) object from other IRRs. Similarly, the RPKI relies on the RPKI Repository Delta Protocol (RRDP) [RFC8182] to synchronize and update data. However, these network protocols exhibit several weaknesses that need to be addressed.¶
The absence of a mechanism to notify other mirrors when updates occur results in synchronization delays and data inconsistency issues. This can be problematic when timeliness and accuracy are crucial.¶
The absence of validation for replicated data from mirrored sources in both IRRs and RPKI is a legitimate concern. This situation creates a considerable risk for inconsistencies and conflicts with the current data.¶
The absence of application security mechanisms within these protocols is another area of vulnerability. This lack of security measures exposes the system to unauthorized access and compromise on data integrity.¶
Although some approaches attempt to optimise the quality of the route origin registry, e.g. RIPE NCC, IRRdv4 using RPKI to validate/filter IRR Route(6) objects, and [RFC8416] proposing that RPs can customise route origin with local data, the problem of inconsistency persists due to the limited coverage of RPKI and the lack of effective mechanisms to resolve conflicting data between IRRs. It is crucial to establish a effective communication mechanism among multiple route origin registry, enabling negotiation and cross-validation of conflicting or special-purpose route origin information.¶
The current route origin registry systems, namely IRRs and RPKI, are facing challenges as the increased occurrence of MOAS prefixes. These challenges mainly include low adoption rates, global inconsistency, insufficient resource certification, and incomplete multi-source collaboration mechanisms.¶
This section lists the requirements designed to guide the improvement of current route origin registry mechanisms. These enhancements should prioritize multi-party collaboration to safeguard legitimate MOAS events while effectively filtering out malicious MOAS incidents.¶
To ensure robust protection for legitimate MOAS events, prefix users should implement an allowlist mechanism as a complementary to the current resource-owner-centric systems. This mechanism permits multiple users to be authorized to announce the same prefix concurrently. Moreover, users should be able to dynamically join or leave the allowlist based on practical business consideration.¶
One of the primary objectives of route origin validation is to suppress the propagation of malicious MOAS incidents and mitigate their impact. To enhance the efficiency and precision of anomaly detection, network participants should employ real-time anomaly monitoring and rapid consensus mechanisms to construct a blocklist. This blocklist enables the timely de-prioritization of anomalous routes, thereby reducing their disruptive effects on the routing system.¶
Multi-party governance plays a pivotal role in the development of new route origin mechanisms. By integrating and cross-verifying data from multiple sources, this approach facilitates effective negotiation and resolution of data duplication and conflicts. It ensures the full utilization of the strengths of each data source, thereby enhancing the reliability and functionality of the system.¶
There is no security consideration in this draft.¶
There is no IANA consideration in this draft.¶
The authors would like to thank Yangfei Guo, Di Ma, Qi Li, Shuhe Wang, Xiaoliang Wang, Hui Wang, etc. for their valuable comments on this document.¶