Skip to main content

Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9455.
Authors Zhiwei Yan , Randy Bush , Guanggang Geng , Ties de Kock , Jiankang Yao
Last updated 2023-08-23 (Latest revision 2023-04-25)
Replaces draft-yan-sidrops-roa-considerations
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Best Current Practice
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Russ Housley
Shepherd write-up Show Last changed 2022-12-19
IESG IESG state Became RFC 9455 (Best Current Practice)
Action Holders
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Warren "Ace" Kumari
Send notices to,
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions
SIDR Operations                                                   Z. Yan
Internet-Draft                                                     CNNIC
Intended status: Best Current Practice                           R. Bush
Expires: 28 October 2023                 IIJ Research Lab & Arrcus, Inc.
                                                               G.G. Geng
                                                        Jinan University
                                                              T. de Kock
                                                                RIPE NCC
                                                                  J. Yao
                                                              April 2023

            Avoidance of ROA Containing Multiple IP Prefixes


   When using the Resource Public Key Infrastructure (RPKI), address
   space holders need to issue Route Origin Authorization (ROA)
   object(s) to authorize one or more Autonomous Systems (ASes) to
   originate routes to IP address prefix(es).  This memo discusses
   operational problems which may arise from ROAs containing multiple IP
   prefixes and recommends that each ROA contains a single IP prefix.

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

   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 3 October 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Yan, et al.              Expires 28 October 2023                [Page 1]
Internet-Draft             ROA considerations                 April 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   In the RPKI, a ROA is a digitally signed object which identifies that
   a single AS has been authorized by the address space holder to
   originate routes to one or more IP prefixes within the related
   address space [RFC6482].

   Each ROA contains an "asID" field and an "ipAddrBlocks" field.  The
   "asID" field contains a single AS number which is authorized to
   originate routes to the given IP address prefix(es).  The
   "ipAddrBlocks" field contains one or more IP address prefixes to
   which the AS is authorized to originate the routes.

   If the address space holder needs to authorize more than one AS to
   advertise the same set of IP prefixes, multiple ROAs must be issued
   (one for each AS number [RFC6480]).  Prior to this document, there
   was no guidance recommending the issuance of a separate ROA for each
   IP prefix or a single ROA containing multiple IP prefixes.

Yan, et al.              Expires 28 October 2023                [Page 2]
Internet-Draft             ROA considerations                 April 2023

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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

   An address space holder can issue a separate ROA for each of its
   routing announcements.  Alternatively, for a given asID, it can issue
   a single ROA for multiple routing announcements, or even for all of
   its routing announcements.  Since a given ROA is either valid or
   invalid, the routing announcements for which that ROA was issued will
   "share fate" when it comes to RPKI validation.  Currently, no
   guidance is offered in existing RFCs to recommend what kinds of ROA
   are issued: one per prefix, or one ROA for multiple routing
   announcements.  The problem of fate-sharing was not discussed or

   In the RPKI trust chain, the Certification Authority (CA) certificate
   issued by a parent CA to a delegate of some resources may be revoked
   by the parent at any time resulting in changes to resources specified
   in the [RFC3779] certificate extension.  Any ROA object that includes
   resources which are a) no longer entirely contained in the new CA
   certificate, or b) contained in a new CA certificate that has not yet
   been discovered by Relying Party (RP) software, will be rejected as
   invalid.  Since ROA invalidity affects all routes specified in that
   ROA, unchanged resources with associated routes via that asID cannot
   be separated from those affected by the change in the CA certificate
   validity.  They will fall under this invalid ROA even though there
   was no intention to change their validity.  Had these resources been
   in a separate ROA, there would have been no change to the issuing CA
   certificate, and therefore no subsequent invalidity.

   CAs have to carefully coordinate ROA updates with resource
   certificate updates.  This process may be automated if a single
   entity manages both the parent CA and the CA issuing the ROAs
   (Scenario D in [RFC8211] Section 3).  However, in other deployment
   scenarios, this coordination becomes more complex.

Yan, et al.              Expires 28 October 2023                [Page 3]
Internet-Draft             ROA considerations                 April 2023

   As there is a single expiration time for the entire ROA, expiration
   will affect all prefixes in the ROA.  Thus, any changes to the ROA
   for any of the prefixes must be synchronized with any changes to
   other prefixes, especially time-limitations on authorization for a
   prefix.  Had these prefixes been in separately issued ROAs, the
   validity interval would be unique to each ROA, and invalidity would
   only be affected by re-issuance of the specific parent CA certificate
   which issued them.

   A prefix could be allowed to be originated from an AS only for a
   specific period of time, for example if the IP prefix was leased out
   temporarily.  This would be more difficult to manage, and potentially
   be more error-prone if a ROA with multiple IP prefixes was used.
   Similarly more complex routing may demand changes in asID or routes
   for a subset of prefixes.  Re-issuance of the ROA may cause change to
   validity for all routes in the affected ROA.  If the time limited
   resources are in separate ROAs, or for more complex routing if each
   change in asID or routes for a given prefix is reflected in a change
   to a discrete ROA, then no change to validity of unaffected routes
   will be caused.

   The use of ROA with a single IP prefix can minimize these side-
   effects.  It avoids fate-sharing irrespective of the causes, where
   the parent CA issuing each ROA remains valid and where each ROA
   itself remains valid.

4.  Recommendations

   Unless the CA has good reasons to the contrary, 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 RP during validation.

6.  IANA Considerations

   This document does not request any IANA action.

7.  Acknowledgements

   The authors wish to thank the following people for their review 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.  Thanks are also due to Warren Kumari
   for the Security Area Directorate review.

Yan, et al.              Expires 28 October 2023                [Page 4]
Internet-Draft             ROA considerations                 April 2023

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

   This document was produced using the xml2rfc tool [RFC2629].

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,

   [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,

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [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,

8.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,

Authors' Addresses

Yan, et al.              Expires 28 October 2023                [Page 5]
Internet-Draft             ROA considerations                 April 2023

   Zhiwei Yan
   No.4 South 4th Street, Zhongguancun
   Beijing, 100190
   P.R. China

   Randy Bush
   IIJ Research Lab & Arrcus, Inc.
   5147 Crystal Springs
   Bainbridge Island, Washington 98110
   United States of America

   Guanggang Geng
   Jinan University
   No.601, West Huangpu Avenue
   P.R. China

   Ties de Kock
   Stationsplein 11

   Jiankang Yao
   No.4 South 4th Street, Zhongguancun
   Beijing, 100190
   P.R. China

Yan, et al.              Expires 28 October 2023                [Page 6]