RFC 9455

RFC 9455: Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes 🎀

Okay bestie, let's start with the vibe check ✨. RFC 9455 is a Best Current Practice (it's BCP 238, and its category is also Best Current Practice 💅), published by the IETF in August 2023 with ISSN 2070-1721. The authors are Zhiwei Yan (CNNIC), Randy Bush (IIJ Research Lab & Arrcus, Inc.), Guanggang Geng (Jinan University), Ties de Kock (RIPE NCC), and Jiankang Yao (CNNIC). The header doesn't list any Obsoletes or Updates lines, so this RFC isn't replacing or patching any other RFC 🫶.

Abstract

So when you're using the Resource Public Key Infrastructure (RPKI) 🔐, address space holders have to issue Route Origin Authorization (ROA) object(s) that say which Autonomous Systems (ASes) are allowed to originate BGP routes to which IP prefixes. This memo talks about the operational headaches that can pop up when one ROA holds multiple IP prefixes 😬, and it recommends that each ROA contain a single IP prefix 🦋.

Status of This Memo

This memo documents an Internet Best Current Practice 🌸.

This document comes from the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community ✨. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more tea on BCPs, check out Section 2 of RFC 7841 🍓.

For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9455 💜.

Copyright Notice

Copyright (c) 2023 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Any Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 💅.

Table of Contents

1.  Introduction
2.  Terminology
3.  Problem Statement
4.  Recommendations
5.  Security Considerations
6.  IANA Considerations
7.  Normative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Okay so in the RPKI, a ROA is a digitally signed object 🔏. It says that a single AS has been authorized by the address space holder to originate BGP routes to one or more IP prefixes inside the related address space [RFC6482]. Iconic, right? 👑

Each ROA has an asID field and an ipAddrBlocks field 🧚. The asID field holds a single AS number that's allowed to originate routes to the given IP address prefix(es). The ipAddrBlocks field holds one or more IP address prefixes that the AS is authorized to originate routes for 💖.

If the address space holder wants to authorize more than one AS to advertise the same set of IP prefixes, they need to issue multiple ROAs, one for each AS number [RFC6480] 🌈. Before this document, there was zero guidance on whether to issue a separate ROA for each IP prefix or one single ROA with multiple IP prefixes. Honestly, it was giving confusion 💀.

2. Terminology 🩷

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. Problem Statement 😭

So an address space holder can issue a separate ROA for each of its routing announcements 🌷. Or, for a given asID, it can issue one single ROA covering multiple routing announcements, or even covering all of its routing announcements 🍰. Here's the tea: a given ROA is either valid or invalid, so every routing announcement that a ROA was issued for will "share fate" when it comes to RPKI validation 🫠. Right now, no existing RFCs give recommendations about what kinds of ROAs to issue, one per prefix or one for multiple routing announcements. The fate-sharing problem was never discussed or addressed, which is wild 🥲.

Now the RPKI trust chain. A Certification Authority (CA) certificate that a parent CA issued to a delegatee for some resources can be revoked by the parent at any time 🚫. That would change the resources listed in the certificate extensions defined in [RFC3779]. Any ROA object that includes resources that are a) no longer entirely contained in the new CA certificate, or b) contained in a new CA certificate that the Relying Party (RP) software hasn't discovered yet, gets rejected as invalid 💔. Since ROA invalidity hits every route in that ROA, the unchanged resources with routes via that asID can't be split off from the ones affected by the change in CA certificate validity. They get dragged into the invalid ROA even though nobody meant to change their validity 😤. If those resources had been in a separate ROA, there'd be no change to the issuing CA certificate and therefore no later invalidity ✨.

CAs have to carefully coordinate ROA updates with updates to a resource certificate 📅. This can be automated if a single entity manages both the parent CA and the CA issuing the ROAs (Scenario D in [RFC8211], Section 3.4) 🤖. But in other deployment scenarios, the coordination gets way more complicated 🌀.

There's also a single expiration time for the entire ROA, so expiration will affect all prefixes in that ROA ⏳. That means changes to the ROA for any one of the prefixes have to be synced with changes to the other prefixes, especially when authorization for a prefix is time bounded ⏰. If those prefixes had been in separately issued ROAs, each ROA would have its own validity interval, and invalidity would only be triggered by reissuance of the specific issuing parent CA certificate 🦋.

Picture this: a prefix is only allowed to originate from an AS for a specific period, like when the IP prefix was leased out temporarily 🏠. If you used a ROA with multiple IP prefixes, that would be harder to manage and potentially more error-prone 🫣. Similarly, more complex routing may require changes in asID or in routes for a subset of prefixes 🛣️. Reissuing a ROA might change the validity of previously received BGP routes covered by the ROA's prefixes 🌪️. There won't be any change to the validity of unaffected routes if a) the time-limited resources are in separate ROAs, or b) for more complex routing, each change in asID or change in routes for a given prefix is reflected in a discrete ROA 🧁.

Using a ROA with a single IP prefix can minimize all of these side effects 🫶. It avoids fate-sharing no matter what the cause is, as long as the parent CA issuing each ROA stays valid and each ROA itself stays valid too 💅.

4. Recommendations 💌

Unless the CA has good reasons to the contrary, an issued ROA SHOULD contain a single IP prefix 🌟.

5. Security Considerations 🚨

Issuing separate ROAs for independent IP prefixes may increase the file-fetch burden on the RP during validation 😱.

6. IANA Considerations 🌿

This document has no IANA actions 🍃.

7. 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/info/rfc2119>.

[RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
           Addresses and AS Identifiers", RFC 3779,
           DOI 10.17487/RFC3779, June 2004,
           <https://www.rfc-editor.org/info/rfc3779>.

[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/info/rfc6480>.

[RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
           Origin Authorizations (ROAs)", RFC 6482,
           DOI 10.17487/RFC6482, February 2012,
           <https://www.rfc-editor.org/info/rfc6482>.

[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/info/rfc8174>.

[RFC8211]  Kent, S. and D. Ma, "Adverse Actions by a Certification
           Authority (CA) or Repository Manager in the Resource
           Public Key Infrastructure (RPKI)", RFC 8211,
           DOI 10.17487/RFC8211, September 2017,
           <https://www.rfc-editor.org/info/rfc8211>.

Acknowledgements 🙌

Huge thank-you to these legends for their reviews and contributions to this document: George Michaelson, Tim Bruijnzeels, Job Snijders, Di Ma, Geoff Huston, Tom Harrison, Rob Austein, Stephen Kent, Christopher Morrow, Russ Housley, Ching-Heng Ku, Keyur Patel, Cuiling Zhang, and Kejun Dong 💖. Extra love to Sean Turner for the Security Area Directorate review 👑.

This work was supported by the Beijing Nova Program of Science and Technology under grant Z191100001119113 🌸.

Authors' Addresses 📮

Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
100190
China
Email: yanzhiwei@cnnic.cn


Randy Bush
IIJ Research Lab & Arrcus, Inc.
5147 Crystal Springs
Bainbridge Island, Washington 98110
United States of America
Email: randy@psg.com


Guanggang Geng
Jinan University
No.601, West Huangpu Avenue
Guangzhou
510632
China
Email: gggeng@jnu.edu.cn


Ties de Kock
RIPE NCC
Stationsplein 11
Amsterdam
Netherlands
Email: tdekock@ripe.net


Jiankang Yao
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
100190
China
Email: yaojk@cnnic.cn