SIDR Operations Z. Yan Internet-Draft CNNIC Intended status: Informational R. Bush Expires: 9 June 2023 IIJ Research Lab & Arrcus, Inc. G.G. Geng Jinan University T. de Kock RIPE NCC J. Yao CNNIC December 2022 Avoidance for ROA Containing Multiple IP Prefixes draft-ietf-sidrops-roa-considerations-05 Abstract In RPKI, the address space holder needs to issue an ROA object when authorizing one or more ASes to originate routes to IP prefix(es). During ROA issurance process, the address space holder may need to specify an origin AS for a list of IP prefixes. Additionally, the address space holder is free to choose to put multiple prefixes into a single ROA or issue separate ROAs for each prefix according to the current specification. This memo analyzes some operational problems which may arise from ROAs containing multiple IP prefixes and recommends avoiding placing multiple IP prefixes in one ROA as possible. 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 4 June 2023. Yan, et al. Expires 9 June 2023 [Page 1] Internet-Draft ROA considerations December 2022 Copyright Notice Copyright (c) 2022 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction In Resource Public Key Infrastructure (RPKI), Route Origin Authorization (ROA) is the digitally signed object which identifies that a single Autonomous System (AS) has been authorized by the address space holder to originate routes to one or more prefixes within the address space[RFC6482]. Each ROA contains an "asID" field and an "ipAddrBlocks" field. The "asID" field contains one single AS number which is authorized to originate routes to the given IP address prefixes. 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 ASes to advertise the same set of IP prefixes, the holder must issue multiple ROAs, one for each AS number. However, at present there are no mandatory requirements describing that the address space holders must issue a separate ROA for each IP prefix or a ROA containing multiple IP prefixes. Yan, et al. Expires 9 June 2023 [Page 2] Internet-Draft ROA considerations December 2022 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 A Certification Authority (CA) may issue a separate ROA for each of its routing announcements. Alternatively, for a given ASN, it may 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, and operator practice in this respect may affect the stability and security of RPKI. Besides, the CA certificate issued by a parent may be replaced by the parent at any time resulting in changes in resources. Any ROA object that includes resources which are a) no longer contained in the new CA certificate, or b) contained in a new CA certificate that is not yet discovered by Relying Party (RP) software, will be rejected as invalid. CAs should carefully coordinate ROA updates with resource certificate updates. A CA can automate this process if a single entity manages both the parent CA and the CA issuing the ROAs (scenario D [[RFC8211] section 3]). However, in other deployment scenarios, this coordination becomes more complex. Furthermore, for the ROA containing multiple IP prefixes, the IP prefixes share the same expiry configuration. If the ROA is not reissued timely, the whole set of IP prefixes will be affected after expiry. Furthermore, the use of ROA with a single IP prefix can minimize the side-effect if prefixes are used in different scenarios or under some temporary contracts. For example, a prefix could be allowed to be originated from an AS only for a specific period of time, such as the IP prefix was leased out temporarily. This would be more difficult to manage, and potentially be more error prone if the ROA with multiple IP prefixes was used. 4. Suggestions The following suggestions should be considered during the process of ROA issurance: Yan, et al. Expires 9 June 2023 [Page 3] Internet-Draft ROA considerations December 2022 1) It's the most important to guarantee the stability and security of RPKI, and it is recommended to include a single IP prefix in each ROA in default. 2) In some special scenarios, where the resource is very stable, a CA has operational problems producing increased number of individual ROAs, or to avoid the possible affects on RP performance, the CA may choose to aggregate multiple IP prefixes. 5. Security Considerations This memo does not give rise to additional security risks. 6. IANA Considerations This document does not request any IANA action. 7. Acknowledgements The authors would like to thanks the valuable comments made by members of sidrops WG and the list will be updated later. 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, . [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, . Yan, et al. Expires 9 June 2023 [Page 4] Internet-Draft ROA considerations December 2022 [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 Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: yanzhiwei@cnnic.cn Randy Bush IIJ Research Lab & Arrcus, Inc. Email: randy@psg.com Guanggang Geng Jinan University No.601, West Huangpu Avenue Guangzhou 510632 P.R. China Email: gggeng@jnu.edu.cn Ties de Kock RIPE NCC Stationsplein 11 Amsterdam Netherlands Email: tdekock@ripe.net Yan, et al. Expires 9 June 2023 [Page 5] Internet-Draft ROA considerations December 2022 Jiankang Yao CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: yaojk@cnnic.cn Yan, et al. Expires 9 June 2023 [Page 6]