idnits 2.17.1 draft-yan-sidrops-roa-considerations-03.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 (September 10, 2019) is 1689 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: March 13, 2020 Internet Initiative Japan 6 G. Geng 7 J. Yao 8 CNNIC 9 September 10, 2019 11 Problem Statement and Considerations for ROAs issued with Multiple 12 Prefixes 13 draft-yan-sidrops-roa-considerations-03 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 March 13, 2020. 45 Copyright Notice 47 Copyright (c) 2019 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 Route Origin Authorization (ROA) is a digitally signed object which 77 is used to identify that a single AS has been authorized by the 78 address space holder to originate routes to one or more prefixes 79 within the address space[RFC6482].If the address space holder needs 80 to authorize more than one ASes to advertise the same set of address 81 prefixes, the holder must issue multiple ROAs, one per AS number. 82 However, at present there are no mandatory requirements in any RFCs 83 describing that the address space holders must issue a separate ROA 84 for each prefix or a ROA for multiple prefixes. 86 Each ROA contains an "asID" field and an "ipAddrBlocks" field. The 87 "asID" field contains one single AS number which is authorized to 88 originate routes to the given IP address prefixes. The 89 "ipAddrBlocks" field contains one or more IP address prefixes to 90 which the AS is authorized to originate the routes. The ROAs with 91 multiple prefixes is a common case that each ROA contains exactly one 92 AS number but may contain multiple IP address prefixes in the 93 operational process of ROA issuance. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Problem statement and Analysis 103 As mentioned above, the address space holder needs to issue an ROA 104 object when it authorizes one or more ASes to originate routes to 105 multiple prefixes. During the process of ROA issuance, the address 106 space holder needs to specify an origin AS for a list of IP prefixes. 107 Besides, the address space holder has a free choice to put multiple 108 prefixes into a single ROA or issue separate ROAs for each prefix 109 based on the current specification. 111 In reality, the address space holders tend to issue each ROA object 112 with fewer IP prefixes, but they still tend to put multiple prefixes 113 into one single ROA. 115 A large number of experiments for the process of ROA issuance have 116 been made on our RPKI testbed, it is found that the misconfigurations 117 during the issuance may cause the ROAs which have been issued to be 118 revoked. 120 Furthermore, for the ROA containing multiple prefixes, once increase 121 or delete one pair in it, this ROA will be reissued. 122 Through sychronization with repository, RPs fetch a new ROA object 123 and then notify and send all the pairs in this ROA to 124 BGP routers. That is to say, the update of the ROA containing 125 multiple IP address prefixes will lead to redundant transmission 126 between RP and BGP routers . So frequent update of these ROAs will 127 increase the convergency time of BGP routers and reduce their 128 performance obviously. 130 4. Suggestions and Considerations 132 Based on the statistical and experimental analysis, following 133 suggestions should be considered during the process of ROA issuance: 135 1) The issuance of ROAs containing a large number of IP prefixes may 136 lead to misconfigurations more easily than ROAs with fewer IP 137 prefixes. 139 A ROA which contains a large number of IP prefixes is more vulnerable 140 to misconfigurations, because any misconfiguration of these prefixes 141 may cause the legitimate ROA to be revoked. Besides, since the 142 misconfigurations of ROAs containing a larger number of IP address 143 prefixes may lead to much more serious consequences (a large-scale 144 network interruption) than ROAs with fewer IP address prefixes, it is 145 suggested to avoid issuing ROAs with a large number of IP address 146 prefixes. 148 2) The number of ROAs containing multiple IP prefixes should be 149 limited and the number of IP prefixes in each ROA should also be 150 limited. 152 The extreme case (a single ROA can only contain one IP address 153 prefix) may lead to too many ROA objects globally, which may in turn 154 become a burden for RPs to synchronize and validate all these ROA 155 objects with the fully deployment of RPKI. So a tradeoff between the 156 number of ROAs and the number of IP prefixes in a single ROA should 157 be considered. 159 3) A safeguard scheme is essential to protect the process of ROA 160 issuance 162 Considering the misconfigurations during the process of ROA issuance 163 are inevitable and the serious consequences they may lead to, a 164 safeguard scheme to protect and monitor the process of ROA issuance 165 should be considered. 167 5. Security Considerations 169 TBD. 171 6. IANA Considerations 173 This document does not request any IANA action. 175 7. Acknowledgements 177 The authors would like to thanks the valuable comments made by 178 members of sidrops WG. 180 This document was produced using the xml2rfc tool [RFC2629]. 182 8. References 183 8.1. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 191 Origin Authorizations (ROAs)", RFC 6482, 192 DOI 10.17487/RFC6482, February 2012, 193 . 195 8.2. Informative References 197 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 198 DOI 10.17487/RFC2629, June 1999, 199 . 201 Authors' Addresses 203 Zhiwei Yan 204 CNNIC 205 No.4 South 4th Street, Zhongguancun 206 Beijing, 100190 207 P.R. China 209 Email: yanzhiwei@cnnic.cn 211 Randy Bush 212 Internet Initiative Japan 214 Email: randy@psg.com 216 Guanggang Geng 217 CNNIC 218 No.4 South 4th Street, Zhongguancun 219 Beijing, 100190 220 P.R. China 222 Email: gengguanggang@cnnic.cn 223 Jiankang Yao 224 CNNIC 225 No.4 South 4th Street, Zhongguancun 226 Beijing, 100190 227 P.R. China 229 Email: yaojk@cnnic.cn