idnits 2.17.1 draft-fu-sidr-unexpected-scenarios-02.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 22 instances of too long lines in the document, the longest one being 13 characters in excess of 72. == There are 6 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 12, 2016) is 2776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5914' is defined on line 591, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing Y. Fu 3 Internet-Draft Z. Yan 4 Intended status: Informational X. Liu 5 Expires: March 16, 2017 C. Wang 6 CNNIC 7 September 12, 2016 9 Scenarios of unexpected resource assignment in RPKI 10 draft-fu-sidr-unexpected-scenarios-02 12 Abstract 14 There are some unexpected scenarios where a CA allocates resources to 15 the sub-node caused by misoperation or malicious operation of CA in 16 RPKI. Then some mechanisms may be needed to avoid these scenarios to 17 happen. This document describes these scenarios and related 18 experiments are presented. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 16, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The scenarios of unexpected resource assignment . . . . . . . 3 57 3.1. Unauthorized resource assignment . . . . . . . . . . . . 3 58 3.2. Resource reassignment . . . . . . . . . . . . . . . . . . 3 59 3.3. Resource transfer . . . . . . . . . . . . . . . . . . . . 4 60 4. Experimental Result . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Unauthorized resource assignment . . . . . . . . . . . . 4 62 4.1.1. Completely unauthorized assignment . . . . . . . . . 4 63 4.1.2. Partially unauthorized assignment . . . . . . . . . . 6 64 4.2. Resource reassignment . . . . . . . . . . . . . . . . . . 8 65 4.2.1. Matching case . . . . . . . . . . . . . . . . . . . . 8 66 4.2.2. Intersection case . . . . . . . . . . . . . . . . . . 10 67 4.2.3. Subset case . . . . . . . . . . . . . . . . . . . . . 12 68 4.3. Resource transfer . . . . . . . . . . . . . . . . . . . . 14 69 5. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 5.1. The CA function enhancement . . . . . . . . . . . . . . . 15 71 5.2. The RP function enhancement . . . . . . . . . . . . . . . 15 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 9.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 n RPKI, CAs (Certification Authorities) are organized in a 83 hierarchical structure which is aligned to the existing INR (Internet 84 Number Resources, including IP prefixes and AS numbers) allocation 85 hierarchy. Each INR allocation requires corresponding resource 86 certificates to attest to it. Two important resource certificates 87 [RFC6480] are needed during this allocation process, and they are CA 88 certificates and EE (End-entity) certificates: CA certificates attest 89 to the INR holdings; EE certificates are primarily used for the 90 validation of ROAs (Route Origin Authorizations) [RFC6482] which is 91 used to verify whether an AS is permitted to originate routes to 92 specific IP prefixes. Besides, Manifest [RFC6486] is used to ensure 93 the integrity of the repository. So the operation of CA is very 94 important for the RPKI deployment and applications based on it. 96 Considering misoperation and malicious operation are inevitable and 97 the significant impact they may cause, this draft describes and 98 analyzes some scenarios of the unexpected resource assignment caused 99 by CA in RPKI deployment. Then some experiments are given to show 100 these scenarios more clearly. Some suggestions are also proposed to 101 avoid corresponding side-effects. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. The scenarios of unexpected resource assignment 111 As described in [RFC6480], the holder of resource ( IP addresses and 112 AS numbers ) may reallocate portions of that block, to the sub-node, 113 subject to contractual constraints established by the registries. 114 But some scenarios of unexpected resource allocation may be caused by 115 the misoperaion of malicious operation of the CA as below: for 116 simplicity, we describe some scenarios with the AS number allocation 117 case. 119 3.1. Unauthorized resource assignment 121 For this scenario, a CA allocates a block of IP address which does 122 not belong to him to subordinate node. That is, this CA doesn't own 123 this block of IP Prefixes actually. So the sub-node cannot use these 124 addresses. But in RPKI scenario, this assignment could be operated 125 successfully. This scenario may be caused by misoperation of the CA 126 or on purpose. 128 According to the resources to be allocated, we divide this case into 129 two kinds of scenarios: Completely unauthorized assignment and 130 Partially unauthorized assignment. 132 (1) Completely unauthorized assignment: the resources to be allocated 133 to subordinate node are without the ownership of CA. 135 (2) Partially unauthorized assignment: the resources to be allocated 136 to subordinate node are with the partially ownership of CA. 138 3.2. Resource reassignment 140 In this scenario, a CA reassign the resource to one sub-node which 141 has been already assigned to another sub-node. This scenario could 142 be sorted into three types: 144 (1) Matching: the block of IP address which is reassigned is the same 145 as which has been already assigned to the other sub-node. 147 (2) Subset: The block of IP address which is reassigned is smaller 148 than which has been already assigned to the other sub-node. 150 (3) Intersection: The block of IP address which is reassigned has 151 overlap with which has been already assigned to the other sub-node. 153 3.3. Resource transfer 155 In practice, resource transfer between two Internet registries is 156 reasonably achievable for most useful operational needs. For the 157 resource transfer, a block of IP addresses will be transferred from 158 one sub-node to the other. This scenario is described in 159 [I-D.ymbk-sidr-transfer] in more detail. The resource reassignment 160 may happened in this scenario by the misoperation of the CA. 162 4. Experimental Result 164 We test the scenarios described above in our testbed. In this 165 section, we present the test results for each case and analyze these 166 results. 168 4.1. Unauthorized resource assignment 170 4.1.1. Completely unauthorized assignment 172 The test scenario is described in Figure 1: APNIC allocates AS number 173 65551 and IP prefixes of 192.0.3.128/26 to TWNIC. But APNIC doesn't 174 own this resource completely. We simulated this process of 175 assignment on our testbed and the result is illustrated in Figure 2. 177 ASNs; 178 +-------------+ 64496-64511,65536-65551 179 | | IP prefixes: 180 | IANA +---------192.0.2.0/24,198.51.100.0/24 181 | | 203.0.113.0/24 182 +------|------+ 183 | 184 +-------------+ ASNs 185 | | 64497-64510,65537-65550 186 | | IP prefixes: 187 | APNIC ---------192.0.2.128/25, 188 | | 198.51.100.128/25 189 -------|------+ 203.0.113.128/25 190 | | | 191 ----------------| | |--------------- 192 | | | 193 +-----------+ +------|------+ +-----------+ 194 | JPNIC | | TWNIC | | CNNIC | 195 +-----|-----+ +------|------+ +----|------+ 196 | | | 197 ASNs: ASNs: ASNs: 198 65540-65550 65551 64498-64505 199 IP prefixes IP prefixes IP prefixes: 200 203.0.113.128/26 192.0.3.128/26 192.0.2.128/26 201 198.51.100.128/26 203 Figure 1: The network architecture of the completely unauthorized 204 assignment 206 We test this case with the tools offered by http://rpki.net/. The 207 result (as described in Figure 2) shows: APNIC has allocated the 208 unauthorized resources (ASNs: 65551, IP prefixes: 192.0.3.128/26) to 209 TWNIC successfully, but TWNIC did not receive these resources 210 actually. 212 root@ubuntu:~#rpkic -i cnnic show_received_resources 213 Parent: apnic 214 notBefore: 2015-07-15T15:53:25Z 215 notAfter: 2016-07-14T15:36:05Z 216 URI: rsync://localhost/rpki/iana/apnic/BqHiZw817JRhXby5cljw-Iy75c4.cer 217 SIA URI: rsync://localhost/rpki/iana/apnic/cnnic/ 218 AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer 219 ASN: 64498-64505 220 IPv4: 192.0.2.128/26,198.51.100.128/26 221 IPv6: 222 root@ubuntu:~# rpkic -i jpnic show_received_resources 223 Parent: apnic 224 notBefore: 2015-07-15T15:25:54Z 225 notAfter: 2016-07-14T15:20:04Z 226 URI: rsync://localhost/rpki/iana/apnic/NSt9KXs-a2py_OGZlol4fipm1lQ.cer 227 SIA URI: rsync://localhost/rpki/iana/apnic/jpnic/ 228 AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer 229 ASN: 65540-65550 230 IPv4: 203.0.113.128/26 231 IPv6: 232 root@ubuntu:~# rpkic -i twnic show_received_resources 233 root@ubuntu:~# 235 Figure 2: The test result of completely unauthorized assignment 237 4.1.2. Partially unauthorized assignment 239 The test scenario is described in Figure 3: APNIC allocates ASNs ( 240 9700-9818 ) to JPNIC. But APNIC only take the ownership of ASNs ( 241 9801-9818 ). We simulated this process of assignment on our testbed 242 and the result is illustrated in Figure 4. 244 +-------------+ 245 | | ASNs: 246 | IANA +---------9800-9819,132176-132191 247 +------|------+ 248 | 249 +-------------+ 250 | | ASNs: 251 | APNIC ---------9801-9818,132177-132190 252 | | 253 --------------+ 254 | | 255 ----------------| |--------------- 256 | | 257 +-----------+ +-----------+ 258 | JPNIC | | CNNIC | 259 +-----|-----+ +----|------+ 260 | | 261 ASNs: ASNs: 262 9700-9818 132178-132189 264 Figure 3: The network architecture of partially unauthorized 265 assignment 267 Our test result for this scenario (as described in Figure 4) shows: 268 APNIC think that it has allocated the partially unauthorized 269 resources to JPNIC successfully, but JPNIC only received the legal 270 part (ASNs 9801-9818), without the illegal part (ASNs 9700-9800). 272 root@ubuntu:~# rpkic -i apnic show_child_resources 273 Child: cnnic 274 ASN: 132178-132179 275 IPv4: 203.0.113.0/26,218.214.108.0/26 276 Child: jpnic 277 ASN: 9700-9818 278 IPv4: 218.241.104.0/26 280 root@ubuntu:~#rpkic -i cnnic show_received_resources 281 Parent: apnic 282 notBefore: 2015-08-31T15:45:37Z 283 notAfter: 2016-08-30T12:24:04Z 284 URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer 285 SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ 286 AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 287 ASN: 132178-132189 288 IPv4: 203.0.113.0/26,218.214.108.0/26 289 IPv6: 290 root@ubuntu:~# rpkic -i jpnic show_received_resources 291 Parent: apnic 292 notBefore: 2015-08-31T15:47:38Z 293 notAfter: 2016-08-30T12:25:25Z 294 URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer 295 SIA URI: rsync://192.168.137.139/rpki/iana/apnic/jpnic/ 296 AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 297 ASN: 9801-9818 298 IPv4: 218.241.104.0/26 299 IPv6: 301 Figure 4: The test result of partially unauthorized assignment 303 4.2. Resource reassignment 305 In the "Resource reassignment" case, we mean that a CA allocate the 306 resources, which have been allocated to one subordinate CA ( e.g. 307 CNNIC ), to another subordinate CA ( e.g. JPNIC ). This case may 308 also be caused by misoperation of CA or on purpose. And it may 309 result in resource conflicts in the Internet. 311 4.2.1. Matching case 313 For the matching case, the test scenario is described in Figure 5: 314 the resources to be allocated to JPNIC (ASNs 132178-132189) is 315 identical to those allocated to CNNIC (ASNs 132178-132189). 317 +-------------+ 318 | | ASNs: 319 | IANA +---------9800-9819,132176-132191 320 +------|------+ 321 | 322 +-------------+ 323 | | ASNs: 324 | APNIC ---------9801-9818,132177-132190 325 | | 326 --------------+ 327 | | 328 ----------------| |--------------- 329 | | 330 +-----------+ +-----------+ 331 | JPNIC | | CNNIC | 332 +-----|-----+ +----|------+ 333 | | 334 ASNs: ASNs: 335 132178-132189 132178-132189 337 Figure 5: The network architecture of matching case 339 We test this case with the tools offered by http://rpki.net/. The 340 result (as described in Fig 6) is that both CNNIC and JPNIC can 341 receive these ASNs at the same time. It may result in resource 342 confliction in the internet. 344 root@ubuntu:~# rpkic -i apnic show_child_resources 345 Child: cnnic 346 ASN: 132178-132189 347 IPv4: 203.0.113.0/26 348 Child: jpnic 349 ASN: 132178-132189 350 IPv4: 203.0.113.0/26 352 root@ubuntu:~# rpkic -i jpnic show_received_resources 353 Parent: apnic 354 notBefore: 2015-08-31T13:43:18Z 355 notAfter: 2016-08-30T12:25:25Z 356 URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer 357 SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ 358 AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 359 ASN: 132178-132189 360 IPv4: 203.0.113.0/26 361 IPv6: 363 root@ubuntu:~# rpkic -i cnnic show_received_resources 364 Parent: apnic 365 notBefore: 2015-08-31T13:39:19Z 366 notAfter: 2016-08-30T12:24:04Z 367 URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer 368 SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ 369 AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 370 ASN: 132178-132189 371 IPv4: 203.0.113.0/26 372 IPv6: 374 Figure 6: The test result of matching case 376 CNNIC and JPNIC receive the same resource assigned by the APNIC at 377 the same time. So the same resource could be allocated to the 378 different sub-node simultaneously. 380 4.2.2. Intersection case 382 As is shown in Figure 7, in the intersection case, there is an 383 overlap between the resources to be allocated to JPNIC (ASNs 384 132180-132190) and those allocated to CNNIC (ASNs 132177-132185). 386 +-------------+ 387 | | ASNs: 388 | IANA +---------9800-9819,132176-132191 389 +------|------+ 390 | 391 +-------------+ 392 | | ASNs: 393 | APNIC ---------9801-9818,132177-132190 394 | | 395 --------------+ 396 | | 397 ----------------| |--------------- 398 | | 399 +-----------+ +-----------+ 400 | JPNIC | | CNNIC | 401 +-----|-----+ +----|------+ 402 | | 403 ASNs: ASNs: 404 132180-132190 132177-132185 406 Figure 7: The network architecture of intersection case 408 Our test result (as described in Figure 8) shows that both CNNIC and 409 JPNIC can receive these ASNs. 411 root@ubuntu:~# rpkic -i apnic show_child_resources 412 Child: cnnic 413 ASN: 132177-132185 414 IPv4: 203.0.113.0/26,218.241.108.0/26 415 Child: jpnic 416 ASN: 132180-132190 417 IPv4: 218.241.104.0/26 419 root@ubuntu:~#rpkic -i cnnic show_received_resources 420 Parent: apnic 421 notBefore: 2015-08-31T14:58:54Z 422 notAfter: 2016-08-30T12:24:04Z 423 URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer 424 SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ 425 AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 426 ASN: 132177-132185 427 IPv4: 203.0.113.0/26,218.214.108.0/26 428 IPv6: 429 root@ubuntu:~# rpkic -i jpnic show_received_resources 430 Parent: apnic 431 notBefore: 2015-08-31T14:58:44Z 432 notAfter: 2016-08-30T12:25:25Z 433 URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer 434 SIA URI: rsync://192.168.137.139/rpki/iana/apnic/jpnic/ 435 AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 436 ASN: 132180-132090 437 IPv4: 218.241.104.0/26 438 IPv6: 440 Figure 8: The test result of intersection case 442 4.2.3. Subset case 444 For the subset case, the network architecture is described in 445 Figure 9: APNIC allocates the ASN 65540 and a block of IP address ( 446 203.0.113.128/26 ) to JPNIC. Then it reallocated this resources to 447 CNNIC. These resources are the subset of CNNIC's resource. 449 ASNs: 450 +-------------+ 64496-64511,65536-65551 451 | | IP prefixes: 452 | IANA +---------192.0.2.0/24,198.51.100.0/24 453 | | 203.0.113.0/24 454 +------|------+ 455 | 456 +-------------+ ASNs: 457 | | 64497-64510,65537-65550 458 | | IP prefixes: 459 | APNIC ---------192.0.2.128/25, 460 | | 198.51.100.128/25 461 --------------+ 203.0.113.128/25 462 | | 463 ----------------| |--------------- 464 | | 465 +-----------+ +-----------+ 466 | JPNIC | | CNNIC | 467 +-----|-----+ +----|------+ 468 | | 469 ASNs: ASNs: 470 65540 64498-64505,65540 471 IP prefixes IP prefixes: 472 203.0.113.128/26 192.0.2.128/26 473 198.51.100.128/26 474 203.0.113.128/26 476 Figure 9: The network architecture of subset case 478 We test this case with the tools offered by http://rpki.net/. The 479 result (as described in Fig 6 ) is that both CNNIC and JPNIC can 480 receive these ASNs and IP Prefixes at the same time. It may result 481 in resource confliction in the internet. 483 root@ubuntu:~# rpkic -i apnic show_child_resources 484 Child: cnnic 485 ASN: 64498-64505,65540 486 IPv4: 192.0.2.128/26,198.51.100.128/26,203.0.113.128/26 487 Child: jpnic 488 ASN: 65540 489 IPv4: 203.0.113.128/26 491 root@ubuntu:~# rpkic -i cnnic show_received_resources 492 Parent: apnic 493 notBefore: 2015-07-15T15:37:58Z 494 notAfter: 2016-07-14T15:36:05Z 495 URI: rsync://localhost/rpki/iana/apnic/BqHiZw817JRhXby5cljw-Iy75c4.cer 496 SIA URI: rsync://localhost/rpki/iana/apnic/cnnic/ 497 AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer 498 ASN: 64498-64505,65540 499 IPv4: 192.0.2.128/26,198.51.100.128/26,203.0.113.128/26 500 IPv6: 502 root@ubuntu:~# rpkic -i jpnic show_received_resources 503 Parent: apnic 504 notBefore: 2015-07-15T15:25:54Z 505 notAfter: 2016-07-14T15:20:04Z 506 URI: rsync://localhost/rpki/iana/apnic/NSt9KXs-a2py_OGZlol4fipm1lQ.cer 507 SIA URI: rsync://localhost/rpki/iana/apnic/jpnic/ 508 AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer 509 ASN: 65540 510 IPv4: 203.0.113.128/26 511 IPv6: 513 Figure 10: The test result of subset case 515 CNNIC and JPNIC could receive the same resources assigned by APNIC at 516 the same time. So the test result verify that the same resources 517 could be allocated to different sub-nodes simultaneously. 519 4.3. Resource transfer 521 This issue is described in [I-D.ymbk-sidr-transfer]. The most 522 serious problem caused by it is the address reassignment described 523 above. 525 5. Solutions 527 In order to avoid the above issues or reduce the related side- 528 effects, the following two solutions may be needed. 530 5.1. The CA function enhancement 532 We have designed a mechanism to enhance the CA function to avoid the 533 above misoperation or malicious operation. The detail information 534 will be given in the future. 536 5.2. The RP function enhancement 538 The enhancement of RP function is needed to discover these resource 539 assignment errors. 541 6. Security Considerations 543 TBD. 545 7. IANA Considerations 547 This draft does not request any IANA action. 549 8. Acknowledgements 551 The authors would like to thanks the valuable comments made by XXX 552 and other members of sidr WG. 554 This document was produced using the xml2rfc tool [RFC2629]. 556 9. References 558 9.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, 562 DOI 10.17487/RFC2119, March 1997, 563 . 565 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 566 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 567 February 2012, . 569 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 570 Origin Authorizations (ROAs)", RFC 6482, 571 DOI 10.17487/RFC6482, February 2012, 572 . 574 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 575 "Manifests for the Resource Public Key Infrastructure 576 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 577 . 579 9.2. Informative References 581 [I-D.ymbk-sidr-transfer] 582 Austein, R., Bush, R., Huston, G., and G. Michaelson, 583 "Resource Transfer in the Resource Public Key 584 Infrastructure", draft-ymbk-sidr-transfer-01 (work in 585 progress), July 2015. 587 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 588 DOI 10.17487/RFC2629, June 1999, 589 . 591 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 592 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 593 . 595 Authors' Addresses 597 Yu Fu 598 CNNIC 599 No.4 South 4th Street, Zhongguancun 600 Hai-Dian District, Beijing, 100190 601 P.R. China 603 Email: fuyu@cnnic.cn 605 Zhiwei Yan 606 CNNIC 607 No.4 South 4th Street, Zhongguancun 608 Beijing, 100190 609 P.R. China 611 Email: yanzhiwei@cnnic.cn 613 Xiaowei Liu 614 CNNIC 615 No.4 South 4th Street, Zhongguancun 616 Beijing, 100190 617 P.R. China 619 Email: liuxiaowei@cnnic.cn 620 Cuicui Wang 621 CNNIC 622 No.4 South 4th Street, Zhongguancun 623 Hai-Dian District, Beijing, 100190 624 P.R. China 626 Email: wangcuicui@cnnic.cn