idnits 2.17.1 draft-yan-sidrops-roa-considerations-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 29, 2020) is 1488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Operations Z. Yan 3 Internet-Draft CNNIC 4 Intended status: Informational R. Bush 5 Expires: September 30, 2020 Internet Initiative Japan 6 G. Geng 7 J. Yao 8 CNNIC 9 March 29, 2020 11 Problem Statement and Considerations for ROAs issued with Multiple 12 Prefixes 13 draft-yan-sidrops-roa-considerations-04 15 Abstract 17 The address space holder needs to issue an ROA object when it 18 authorizes one or more ASes to originate routes to multiple prefixes. 19 During the process of ROA issuance, the address space holder needs to 20 specify an origin AS for a list of IP prefixes. Besides, the address 21 space holder has a free choice to put multiple prefixes into a single 22 ROA or issue separate ROAs for each prefix based on the current 23 specification. This memo analyzes and presents some operational 24 problems which may be caused by the misconfigurations of ROAs 25 containing multiple IP prefixes. Some suggestions and considerations 26 also have been proposed. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 30, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Problem statement and Analysis . . . . . . . . . . . . . . . 3 65 4. Suggestions and Considerations . . . . . . . . . . . . . . . 3 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 8.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 Route Origin Authorization (ROA) is a digitally signed object which 78 is used to identify that a single AS has been authorized by the 79 address space holder to originate routes to one or more prefixes 80 within the address space[RFC6482].If the address space holder needs 81 to authorize more than one ASes to advertise the same set of address 82 prefixes, the holder must issue multiple ROAs, one per AS number. 83 However, at present there are no mandatory requirements in any RFCs 84 describing that the address space holders must issue a separate ROA 85 for each prefix or a ROA for multiple prefixes. 87 Each ROA contains an "asID" field and an "ipAddrBlocks" field. The 88 "asID" field contains one single AS number which is authorized to 89 originate routes to the given IP address prefixes. The 90 "ipAddrBlocks" field contains one or more IP address prefixes to 91 which the AS is authorized to originate the routes. The ROAs with 92 multiple prefixes is a common case that each ROA contains exactly one 93 AS number but may contain multiple IP address prefixes in the 94 operational process of ROA issuance. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Problem statement and Analysis 104 As mentioned above, the address space holder needs to issue an ROA 105 object when it authorizes one or more ASes to originate routes to 106 multiple prefixes. During the process of ROA issuance, the address 107 space holder needs to specify an origin AS for a list of IP prefixes. 108 Besides, the address space holder has a free choice to put multiple 109 prefixes into a single ROA or issue separate ROAs for each prefix 110 based on the current specification. 112 In reality, the address space holders tend to issue each ROA object 113 with fewer IP prefixes, but they still tend to put multiple prefixes 114 into one single ROA. 116 A large number of experiments for the process of ROA issuance have 117 been made on our RPKI testbed, it is found that the misconfigurations 118 during the issuance may cause the ROAs which have been issued to be 119 revoked. 121 Another potential influence of misconfigurations of ROAs containing 122 multiple IP prefixes on BGP routers may be considered. For the ROA 123 containing multiple prefixes, once increase or delete one pair in it, this ROA will be reissued. Through 125 sychronization with repository, RPs fetch a new ROA object and then 126 notify and send all the pairs in this ROA to BGP 127 routers. That is to say, the update of the ROA containing multiple 128 IP address prefixes will lead to redundant transmission between RP 129 and BGP routers . So frequent update of these ROAs will increase the 130 convergency time of BGP routers and reduce their performance 131 obviously. 133 4. Suggestions and Considerations 135 Based on the statistical and experimental analysis, following 136 suggestions should be considered during the process of ROA issuance: 138 1) The issuance of ROAs containing a large number of IP prefixes may 139 lead to misconfigurations more easily than ROAs with fewer IP 140 prefixes. 142 A ROA which contains a large number of IP prefixes is more vulnerable 143 to misconfigurations, because any misconfiguration of these prefixes 144 may cause the legitimate ROA to be revoked. Besides, since the 145 misconfigurations of ROAs containing a larger number of IP address 146 prefixes may lead to much more serious consequences (a large-scale 147 network interruption) than ROAs with fewer IP address prefixes, it is 148 suggested to avoid issuing ROAs with a large number of IP address 149 prefixes. 151 2) The number of ROAs containing multiple IP prefixes should be 152 limited and the number of IP prefixes in each ROA should also be 153 limited. 155 The extreme case (a single ROA can only contain one IP address 156 prefix) may lead to too many ROA objects globally, which may in turn 157 become a burden for RPs to synchronize and validate all these ROA 158 objects with the fully deployment of RPKI. So a tradeoff between the 159 number of ROAs and the number of IP prefixes in a single ROA should 160 be considered. 162 3) A safeguard scheme is essential to protect the process of ROA 163 issuance 165 Considering the misconfigurations during the process of ROA issuance 166 are inevitable and the serious consequences they may lead to, a 167 safeguard scheme to protect and monitor the process of ROA issuance 168 should be considered. 170 5. Security Considerations 172 TBD. 174 6. IANA Considerations 176 This document does not request any IANA action. 178 7. Acknowledgements 180 The authors would like to thanks the valuable comments made by 181 members of sidrops WG. 183 This document was produced using the xml2rfc tool [RFC2629]. 185 8. References 186 8.1. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, 190 DOI 10.17487/RFC2119, March 1997, 191 . 193 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 194 Origin Authorizations (ROAs)", RFC 6482, 195 DOI 10.17487/RFC6482, February 2012, 196 . 198 8.2. Informative References 200 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 201 DOI 10.17487/RFC2629, June 1999, 202 . 204 Appendix A. Acknowledgments 206 This work was supported by Beijing Nova Program of Science and 207 Technology under grant Z191100001119113. 209 Authors' Addresses 211 Zhiwei Yan 212 CNNIC 213 No.4 South 4th Street, Zhongguancun 214 Beijing, 100190 215 P.R. China 217 Email: yanzhiwei@cnnic.cn 219 Randy Bush 220 Internet Initiative Japan 222 Email: randy@psg.com 224 Guanggang Geng 225 CNNIC 226 No.4 South 4th Street, Zhongguancun 227 Beijing, 100190 228 P.R. China 230 Email: gengguanggang@cnnic.cn 231 Jiankang Yao 232 CNNIC 233 No.4 South 4th Street, Zhongguancun 234 Beijing, 100190 235 P.R. China 237 Email: yaojk@cnnic.cn