Route Origin Registry Problem Statement
draft-jiang-sidrops-psvro-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Shenglin(Forrest) Jiang , Ke Xu , Li Qi , Xingang Shi , Zhuotao liu | ||
| Last updated | 2026-05-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jiang-sidrops-psvro-04
SIDROPS S. Jiang
Internet-Draft Zhongguancun Laboratory
Intended status: Informational K. Xu
Expires: 19 November 2026 Q. Li
Tsinghua University
X. Shi
Tsinghua University & Zhongguancun Laboratory
Z. Liu
Tsinghua University
18 May 2026
Route Origin Registry Problem Statement
draft-jiang-sidrops-psvro-04
Abstract
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 AS (MOAS), higher requirements
are placed on the route origin registry. This document serves to
outline the problem statement for current route origin registry.
Status of This Memo
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 19 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jiang, et al. Expires 19 November 2026 [Page 1]
Internet-Draft PSVRO May 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Working Definition of Route Origin Registry . . . . . . . . . 3
4. Prefix Hijacking and Legitimate MOAS . . . . . . . . . . . . 3
5. Problems in Current Route Origin Registry . . . . . . . . . . 4
5.1. Security Risks from Partial Adoption . . . . . . . . . . 5
5.2. Inconsistency between Different Route Origin
Registries . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Insufficiency of Resource Certification . . . . . . . . . 6
5.4. Synchronization and Management . . . . . . . . . . . . . 6
5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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 AS
(MOAS).
Unfortunately, the current route origin registry, such as Internet
Routing Registry (IRR) [RFC2622] and Resource Public Key
Infrastructure (RPKI) [RFC6480], are not effective in distinguishing
between legitimate MOAS and prefix hijacking. There is a pressing
need for a verifiable route origin registry that can support
registration and protection of legitimate MOAS, thereby mitigating
the threats posed by prefix hijacking to the routing infrastructure.
Jiang, et al. Expires 19 November 2026 [Page 2]
Internet-Draft PSVRO May 2026
This document analyzes multiple scenarios involving MOAS events and
identifies limitations inherent in the current route origin registry
mechanisms. The intent is to provide guidance and insights to
network operators, researchers, and policymakers aimed at enhancing
the security and resilience of the global routing infrastructure.
2. Requirements Language
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.
3. Working Definition of Route Origin Registry
Route origin registry refers to an infrastructure that records the
mapping of IP prefixes to the ASes authorised to announce them.
Resource holders can register prefix-origin pairs 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 AS 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.
4. Prefix Hijacking and Legitimate MOAS
[RFC1930] suggests that a prefix should typically have a single AS as
its origin, with a few exceptions. However, CAIDA's analysis on BGP
routing data [CAIDA] reveals that MOAS has always been a common
phenomenon. There are various reasons that contribute to the
emergence of MOAS prefixes:
* *_Aggregation_*. For example, if "Prefix 0/24" originates from ASx
and "Prefix 1/24" originates from ASy, an aggregating router may
combine them into "Prefix 0/23". In this case, the aggregating
router has two options: it may include an AS_SET attribute
containing both ASx and ASy in the aggregated announcement,
Jiang, et al. Expires 19 November 2026 [Page 3]
Internet-Draft PSVRO May 2026
resulting in a MOAS prefix; or it may omit the AS_SET and attach
the ATOMIC_AGGREGATE attribute instead, indicating that route
information has been suppressed.
* *_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 is 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.
5. Problems in Current Route Origin Registry
This section outlines several challenges faced by the current route
origin registry in distinguishing legitimate MOAS events from
malicious MOAS incidents, such as route hijacking.
Jiang, et al. Expires 19 November 2026 [Page 4]
Internet-Draft PSVRO May 2026
5.1. Security Risks from Partial Adoption
As the adoption of RPKI continues to grow, the number of IP 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, 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.
5.2. Inconsistency between Different Route Origin Registries
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 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.
Jiang, et al. Expires 19 November 2026 [Page 5]
Internet-Draft PSVRO May 2026
5.3. Insufficiency of Resource Certification
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 AS Numbers 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.
5.4. Synchronization and Management
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.
Jiang, et al. Expires 19 November 2026 [Page 6]
Internet-Draft PSVRO May 2026
* 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 an effective communication mechanism among multiple
route origin registry, enabling negotiation and cross-validation of
conflicting or special-purpose route origin information.
5.5. Summary
The current route origin registry infrastructure, namely IRRs and
RPKI, are facing challenges due to the increased occurrence of MOAS
prefixes. These challenges mainly include low adoption rates, global
inconsistency, insufficient resource certification, and incomplete
multi-source collaboration mechanisms.
6. Security Considerations
There is no security consideration in this draft.
7. IANA Considerations
There is no IANA consideration in this draft.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Jiang, et al. Expires 19 November 2026 [Page 7]
Internet-Draft PSVRO May 2026
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999,
<https://www.rfc-editor.org/rfc/rfc2622>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/rfc/rfc8182>.
[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
<https://www.rfc-editor.org/rfc/rfc8416>.
8.2. Informative References
[CAIDA] "RouteViews Prefix to AS mappings", 2026,
<https://doi.org/10.21986/CAIDA.DATA.ROUTEVIEWS-PFX2AS-
MAPPING>.
[IRRegularities]
Du, B., Izhikevich, K., Rao, S., Akiwate, G., Testart, C.,
AC Snoeren, and K. Claffy, "IRRegularities in the internet
routing registry", Proceedings of the 2023 ACM on internet
measurement conference , 2023.
[MANRS] "MANRS Observatory", 2026,
<https://observatory.manrs.org/>.
[NRO] "NRO RIR Statistics", 2026,
<https://www.nro.net/about/rirs/statistics/>.
[NRTMv4] Romijn, S., Snijders, J., Shryane, E., and S.
Konstantaras, "Near Real Time Mirroring (NRTM) version 4",
Work in Progress, Internet-Draft, draft-ietf-grow-nrtm-
v4-11, 17 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
nrtm-v4-11>.
Jiang, et al. Expires 19 November 2026 [Page 8]
Internet-Draft PSVRO May 2026
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
<https://www.rfc-editor.org/rfc/rfc1930>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/rfc/rfc4272>.
[RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and
D. Mitchell, "Considerations for Internet Routing
Registries (IRRs) and Routing Policy Configuration",
RFC 7682, DOI 10.17487/RFC7682, December 2015,
<https://www.rfc-editor.org/rfc/rfc7682>.
[RFC8897] Ma, D. and S. Kent, "Requirements for Resource Public Key
Infrastructure (RPKI) Relying Parties", RFC 8897,
DOI 10.17487/RFC8897, September 2020,
<https://www.rfc-editor.org/rfc/rfc8897>.
Acknowledgments
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.
Authors' Addresses
Shenglin Jiang
Zhongguancun Laboratory
Beijing
China
Email: jiangshl@zgclab.edu.cn
Ke Xu
Tsinghua University
Beijing
China
Email: xuke@tsinghua.edu.cn
Qi Li
Tsinghua University
Beijing
China
Email: qli01@tsinghua.edu.cn
Jiang, et al. Expires 19 November 2026 [Page 9]
Internet-Draft PSVRO May 2026
Xingang Shi
Tsinghua University & Zhongguancun Laboratory
Beijing
China
Email: shixg@cernet.edu.cn
Zhuotao Liu
Tsinghua University
Beijing
China
Email: zhuotaoliu@tsinghua.edu.cn
Jiang, et al. Expires 19 November 2026 [Page 10]