idnits 2.17.1 draft-yan-sidrops-roa-considerations-00.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2017) is 2458 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-sidr-rpki-validation-reconsidered-08 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Operations Z. Yan 3 Internet-Draft Y. Fu 4 Intended status: Informational CNNIC 5 Expires: February 3, 2018 X. Liu 6 ISCAS 7 G. Geng 8 CNNIC 9 August 2, 2017 11 Problem Statement and Considerations for ROAs issued with Multiple 12 Prefixes 13 draft-yan-sidrops-roa-considerations-00 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 http://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 February 3, 2018. 45 Copyright Notice 47 Copyright (c) 2017 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 (http://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 3.1. Statistical analysis . . . . . . . . . . . . . . . . . . 3 66 3.2. Experimental analysis . . . . . . . . . . . . . . . . . . 5 67 3.3. Problem statement . . . . . . . . . . . . . . . . . . . . 8 68 4. Suggestions and Considerations . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Route Origin Authorization (ROA) is a digitally signed object which 80 is used to identify that a single AS has been authorized by the 81 address space holder to originate routes to one or more prefixes 82 within the address space[RFC6482].If the address space holder needs 83 to authorize more than one ASes to advertise the same set of address 84 prefixes, the holder must issue multiple ROAs, one per AS number. 85 However, at present there are no mandatory requirements in any RFCs 86 describing that the address space holders must issue a separate ROA 87 for each prefix or a ROA for multiple prefixes. 89 Each ROA contains an "asID" field and an "ipAddrBlocks" field. The 90 "asID" field contains one single AS number which is authorized to 91 originate routes to the given IP address prefixes. The 92 "ipAddrBlocks" field contains one or more IP address prefixes to 93 which the AS is authorized to originate the routes. The ROAs with 94 multiple prefixes is a common case that each ROA contains exactly one 95 AS number but may contain multiple IP address prefixes in the 96 operational process of ROA issuance. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Problem statement and Analysis 106 3.1. Statistical analysis 108 As mentioned above, the address space holder needs to issue an ROA 109 object when it authorizes one or more ASes to originate routes to 110 multiple prefixes. During the process of ROA issuance, the address 111 space holder needs to specify an origin AS for a list of IP prefixes. 112 Besides, the address space holder has a free choice to put multiple 113 prefixes into a single ROA or issue separate ROAs for each prefix 114 based on the current specification. 116 On our RPKI testbed, the Trust Anchor Locator (TAL) files configured 117 by RP correspond to the five RIRs' RPKI Trust Anchors. By using 118 these TAL files, all the ROA objects issued in each region (the five 119 RIRs) around the world are collected and validated with the RPKI 120 Relying Party tools provided by rpki.net. According to the analysis 121 on these data, some statistical results are described in Table. 1. 123 +----------------+------------------------+-------------------------+ 124 | The total | The number of ROAs | The number of ROAs with | 125 | number of ROAs | with a single prefix | multiple prefixes | 126 +----------------+------------------------+-------------------------+ 127 | 7166 | 3307 | 3859 | 128 +----------------+------------------------+-------------------------+ 130 Table.1 Statistical results of all ROAs 132 As shown in Table. 1, by now (as of July 4, 2017), the total number 133 of ROA objects issued around the world is about 7166. The result is 134 in accordance with the statistics provided by RIPE NCC and Internet 135 Multifeed Co. (MF). Based on the further analysis on these ROA 136 objects, it is found that: the number of ROAs containing only one 137 prefix is about 3307 (account for 46.1% of all ROA objects), and the 138 number of ROAs containing two or more prefixes is about 3859 (account 139 for 53.9% of all ROA objects). 141 In the 3859 ROA objects which each one contains two or more prefixes, 142 the number of IP address prefixes are calculated and analyzed. The 143 statistical results are shown in Table. 2. 145 +------------------+---------------+--------------------------------+ 146 | The number of | The number of | The average number of prefixes | 147 | prefixes | ROAs | in each ROA | 148 +------------------+---------------+--------------------------------+ 149 | 37367 | 3859 | 9.68 | 150 +------------------+---------------+--------------------------------+ 152 Table. 2 Statistical results of the 3859 ROAs 154 As described in Table. 2, there are 37367 IP address prefixes in the 155 3859 ROA objects. And the average number of prefixes in each ROA is 156 9.68 (37367/3859). In addition, four types of ROAs are analyzed and 157 calculated in the 3859 ROAs: ROAs each contains 158 2-10/11-50/51-100/>100 IP address prefixes. The statistical results 159 are presented in Table. 3. 161 +----------+----------+-----------+-----------+-----------+---------+ 162 | ROA | ROA with | ROA with | ROA with | ROA with | Total | 163 | types | 2-10 | 11-50 | 51-100 | >100 | | 164 | | prefixes | prefixes | prefixes | prefixes | | 165 +----------+----------+-----------+-----------+-----------+---------+ 166 | The | 3263 | 496 | 60 | 40 | 3859 | 167 | number | | | | | | 168 | of ROAs | | | | | | 169 | The | 84.56% | 12.85% | 1.55% | 1.04% | 100.00% | 170 | ratio of | | | | | | 171 | ROAs | | | | | | 172 | The | 12442 | 10365 | 4125 | 10435 | 37367 | 173 | number | | | | | | 174 | of | | | | | | 175 | prefixes | | | | | | 176 | The | 33.30% | 27.74% | 11.04% | 27.93% | 100.00% | 177 | ratio of | | | | | | 178 | prefixes | | | | | | 179 +----------+----------+-----------+-----------+-----------+---------+ 181 Table. 3 Statistical results of four types of ROAs 183 As shown in Table. 3, taking the first type of ROA as an example, 184 there are 3263 ROAs (account for 84.56% of the 3859 ROA objects) 185 which each contains 2-10 IP address prefixes, and the total number of 186 IP prefixes in these 3263 ROAs is 12442 (account for 33.29% of the 187 37367 prefixes). 189 According to the third row (the ratio of ROAs) in Table. 3, it shows 190 the trend that the address space holders tend to issue each ROA 191 object with fewer IP prefixes (more than 60% of ROAs containing less 192 than 50 prefixes), but they still tend to put multiple prefixes into 193 one single ROA. 195 It should also be paid more attention that among all the ROAs issued 196 today, a single ROA may contain a large number of IP address 197 prefixes. In the statistical results, it is found that there exists 198 two ROAs (corresponding to ASN 24440 and ASN 23752) which each 199 contains more than 700 IP address prefixes (796 and 892 200 respectively). 202 3.2. Experimental analysis 204 A large number of experiments for the process of ROA issuance have 205 been made on our RPKI testbed, it is found that the misconfigurations 206 during the issuance may cause the ROAs which have been issued to be 207 revoked. The corresponding scenarios are as follows. 209 AS shown in Fig. 1, an ISP needed to issue two ROA objects 210 respectively to authorize ASN 64500 to originate routes to IP 211 prefixes 192.0.2.128/28 and ASN 64501 to originate routes to IP 212 prefixes 198.51.100.128/28. The operations are simulated on our RPKI 213 testbed. 215 +-----------+ 216 | | ASNs: 217 | IANA |----- 0-4294967295 218 | | IP Prefixes: 219 | | 0.0.0.0/0 220 +-----|-----+ 221 | ASNs: 222 +-----|-----+ 64497-64510 223 | | 65537-65550 224 | | IP Prefixes 225 | APNIC ------ 192.0.2.118/25 226 | | 198.51.100.128/25 227 | | 203.0.113.128/25 228 +-----|-----+ 229 | 230 +-----|-----+ ASNs: 231 | | 64498-64505 232 | | IP Prefixes 233 | | 192.0.2.128/26 234 | CNNIC ------ 198.51.100.128/26 235 | | 203.0.113.128/26 236 +-----|-----+ 237 | 238 +-----|-----+ 239 | | ASNs: 240 | | 64500-64505 241 | | IP Prefixes: 242 | ISP ------ 192.0.2.128/27 243 | | 198.51.100.128/27 244 | | 203.0.113.128/27 245 +-----+-----+ 246 | -------------- 247 | //// \\\\ 248 | // ROA1: \\ 249 ---------------| 64500->192.0.2.128/28 | 250 | ROA2: | 251 | 64501->198.51.100.128/28 | 252 \\ // 253 \\\\ //// 254 -------------- 256 Fig. 1 Scenario of ROA issuance 258 The ROA objects issued by ISP could be checked with the 259 "show_published_objects" command. And as shown in Fig. 2, ISP has 260 issued two ROA objects M74Rq1am9m4YUairntkXTRAx6Wg.roa and 261 vulw_jMZBy7-ktn7nyhlpchBKZY.roa to respectively authorize ASN 64500 262 to originate routes to IP prefixes 192.0.2.128/28 and ASN 64501 to 263 originate routes to IP prefixes 198.51.100.128/28. 265 test@~$cat ISPROA.csv 266 192.0.2.128/28 64500 Group1 267 198.51.100.128/28 64501 Group2 268 test@~$ rpkic -i ISP load_roa_requests ISPROA.csv 269 test@~$ rpkic -i ISP show_published_objects 270 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.crl 271 2017-07-19T10:34:04Z 594CB167AF4E81424EBEA7C1A5FD8DDE216D5C69 272 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft 273 2017-07-19T10:34:04Z 17C98CBFB179D60D9D0A6D52C2629B7A8DEA8A9C 274 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/M74Rq1am9m4YUairntkXTRAx6Wg.roa 275 2017-07-19T09:20:20Z 0CFD927D1522BF43FC52B748F274646387569222 276 64500 192.0.2.128/28 277 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vulw_jMZBY7-KTN7nyhlpchBKZY.roa 278 2017-07-19T10:34:04Z 305866D0c4ee5e156ebeda811d3540bf0e094043 279 64501 198.51.100.128/28 281 Fig. 2 Check the ROAs issued by ISP 283 Afterwards, ISP wanted to authorize ASN 64501 to originate routes to 284 another IP prefixes 203.0.113.128/28, so it modified the ISPROA.csv 285 file and operated the "load_roa_requests" command again. 287 test@~$cat ISPROA.csv 288 192.0.2.128/28 64500 Group1 289 198.51.100.128/28 64501 Group2 290 203.0.113.128/28 64501 Group2 291 test@~$ rpkic -i ISP load_roa_requests ISPROA.csv 292 test@~$ rpkic -i ISP show_published_objects 293 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.crl 294 2017-07-19T10:38:03Z 2606EAA75AB60BE7785AE0CB0599D984AFD5BDB5 295 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft 296 2017-07-19T10:38:03Z 10F3F9249F0A6A636BF8143075693681B45A4BC2 297 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/M74Rq1am9m4YUairntkXTRAx6Wg.roa 298 2017-07-19T09:20:20Z 0CFD927D1522BF43FC52B748F274646387569222 299 64500 192.0.2.128/28 300 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vO3whtjMpYxxyva4BxRqI2H8eqA.roa 301 2017-07-19T10:38:03Z 4B85FDBABEC567A9DD8DA5745B34A201390F4530 302 64501 198.51.100.128/28,203.0.113.128/28 304 Fig. 3 Add a new authorization 306 As shown in Fig. 3, after processing the above operations, a new ROA 307 object vO3WhtjMpYxxyva4BxRqI2H8eqA.roa which contained two IP 308 prefixes was issued. One thing which needs to be noticed is that in 309 the ISPROA.csv file the third column of the last two lines (with 310 respect to ASN 64501) are set as the same label "Group2" to make sure 311 that the authorizations to the two IP prefixes will be issued into a 312 single ROA. 314 Now, ISP wants to authorize ASN 64500 to originate routes to IP 315 prefixes 203.0.113.128/28 as well, but when it modifies the 316 ISPROA.csv file, it appends 204.0.113.128/28 (or any prefixes that do 317 not belong to ISP) instead of 203.0.113.128/28 into the ISPROA.csv 318 file by mistake. And then, when it operates the "load_roa_requests" 319 command, something unexpected will happen. 321 test@~$cat ISPROA.csv 322 192.0.2.128/28 64500 Group1 323 204.0.113.128/28 64500 Group1 324 198.51.100.128/28 64501 Group2 325 203.0.113.128/28 64501 Group2 326 test@~$ rpkic -i ISP load_roa_requests ISPROA.csv 327 test@~$ rpkic -i ISP show_published_objects 328 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.crl 329 2017-07-19T12:39:47Z 2DD037213237D72AF6CE95F8F37D1F08E8B49A37 330 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft 331 2017-07-19T12:39:47Z 735D9723B8C6D8214DA78117D27E529AA47E14B6 332 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vO3whtjMpYxxyva4BxRqI2H8eqA.roa 333 2017-07-19T10:38:03Z 4B85FDBABEC567A9DD8DA5745B34A201390F4530 334 64501 198.51.100.128/28,203.0.113.128/28 336 Fig. 4 Add an incorrect authorization by mistake 338 As shown in Fig. 4, a legitimate ROA object was revoked because of 339 ISP's misconfiguration. Obviously, this misconfiguration may lead to 340 some serious consequences to RPKI (such as legitimate BGP routes are 341 misclassified as "invalid"). 343 3.3. Problem statement 345 It concludes that the misconfigurations of ROAs containing multiple 346 IP address prefixes may lead to much more serious consequences than 347 ROAs with fewer IP address prefixes. According to the above 348 statistical and experimental analysis, misconfigurations of the ROAs 349 which contain more than 300 IP address prefixes may cause a large- 350 scale network interruption. 352 Another potential influence of misconfigurations of ROAs containing 353 multiple IP prefixes on BGP routers may be considered. For the ROA 354 containing multiple prefixes, once increase or delete one pair in it, this ROA will be reissued. Through 356 sychronization with repository, RPs fetch a new ROA object and then 357 notify and send all the pairs in this ROA to BGP 358 routers. That is to say, the update of the ROA containing multiple 359 IP address prefixes will lead to redundant transmission between RP 360 and BGP routers . So frequent update of these ROAs will increase the 361 convergency time of BGP routers and reduce their performance 362 obviously. 364 4. Suggestions and Considerations 366 Based on the statistical and experimental analysis, following 367 considerations should be considered during the process of ROA 368 issuance: 370 1) The issuance of ROAs containing a large number of IP prefixes may 371 lead to misconfigurations more easily than ROAs with fewer IP 372 prefixes. 374 A ROA which contains a large number of IP prefixes is more vulnerable 375 to misconfigurations, because any misconfiguration of these prefixes 376 may cause the legitimate ROA to be revoked. Besides, since the 377 misconfigurations of ROAs containing a larger number of IP address 378 prefixes may lead to much more serious consequences (a large-scale 379 network interruption) than ROAs with fewer IP address prefixes, it is 380 suggested to avoid issuing ROAs with a large number of IP address 381 prefixes. 383 So it is also recommended in the last paragraph of the section 4.2.5 384 of [I-D.ietf-sidr-rpki-validation-reconsidered] that opterators MAY 385 issue separate ROAs for each IP address prefix, so that the loss of 386 on IP address prefix from the VRS-IP of any certificate along the 387 path to the trust anchor would not invalidate authorizations for 388 other IP address prefixes. 390 2) The number of ROAs containing multiple IP prefixes should be 391 limited and the number of IP prefixes in each ROA should also be 392 limited. 394 The extreme case (a single ROA can only contain one IP address 395 prefix) may lead to too much ROA objects globally, which may in turn 396 become a burden for RPs to synchronize and validate all these ROA 397 objects with the fully deployment of RPKI. So a tradeoff between the 398 number of ROAs and the number of IP prefixes in a single ROA should 399 be considered. 401 3) A safeguard scheme is essential to protect the process of ROA 402 issuance 404 Considering the misconfigurations during the process of ROA issuance 405 are inevitable and the serious consequences they may lead to, a 406 safeguard scheme to protect and monitor the process of ROA issuance 407 should be considered. 409 5. Security Considerations 411 TBD. 413 6. IANA Considerations 415 This draft does not request any IANA action. 417 7. Acknowledgements 419 The authors would like to thanks the valuable comments made by XXX 420 and other members of sidrops WG. 422 This document was produced using the xml2rfc tool [RFC2629]. 424 8. References 426 8.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 434 Origin Authorizations (ROAs)", RFC 6482, 435 DOI 10.17487/RFC6482, February 2012, 436 . 438 8.2. Informative References 440 [I-D.ietf-sidr-rpki-validation-reconsidered] 441 Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 442 Newton, A., and D. Shaw, "RPKI Validation Reconsidered", 443 draft-ietf-sidr-rpki-validation-reconsidered-08 (work in 444 progress), June 2017. 446 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 447 DOI 10.17487/RFC2629, June 1999, 448 . 450 Authors' Addresses 452 Zhiwei Yan 453 CNNIC 454 No.4 South 4th Street, Zhongguancun 455 Beijing, 100190 456 P.R. China 458 Email: yanzhiwei@cnnic.cn 460 Yu Fu 461 CNNIC 462 No.4 South 4th Street, Zhongguancun 463 Beijing, 100190 464 P.R. China 466 Email: fuyu@cnnic.cn 468 Xiaowei Liu 469 ISCAS 470 Institute of Software Chinese Academy of Sciences 471 Beijing, 100190 472 P.R. China 474 Email: liuxiaowei@iscas.ac.cn 476 Guanggang Geng 477 CNNIC 478 No.4 South 4th Street, Zhongguancun 479 Beijing, 100190 480 P.R. China 482 Email: gengguanggang@cnnic.cn