Secure Inter-Domain Routing Y. Fu Internet-Draft Z. Yan Intended status: Informational X. Liu Expires: September 11, 2016 C. Wang CNNIC March 10, 2016 Scenarios of unexpected resource assignment in RPKI draft-fu-sidr-unexpected-scenarios-01 Abstract There are some unexpected scenarios where a CA allocates resources to the sub-node caused by misoperation or malicious operation of CA in RPKI. Then some mechanisms may be needed to avoid these scenarios to happen. This document describes these scenarios and related experiments are presented. 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 http://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 September 11, 2016. Copyright Notice Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of Fu, et al. Expires September 11, 2016 [Page 1] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The scenarios of unexpected resource assignment . . . . . . . 3 3.1. Unauthorized resource assignment . . . . . . . . . . . . 3 3.2. Resource reassignment . . . . . . . . . . . . . . . . . . 3 3.3. Resource transfer . . . . . . . . . . . . . . . . . . . . 4 4. Experimental Result . . . . . . . . . . . . . . . . . . . . . 4 4.1. Unauthorized resource assignment . . . . . . . . . . . . 4 4.1.1. Completely unauthorized assignment . . . . . . . . . 4 4.1.2. Partially unauthorized assignment . . . . . . . . . . 6 4.2. Resource reassignment . . . . . . . . . . . . . . . . . . 8 4.2.1. Matching case . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Intersection case . . . . . . . . . . . . . . . . . . 10 4.2.3. Subset case . . . . . . . . . . . . . . . . . . . . . 12 4.3. Resource transfer . . . . . . . . . . . . . . . . . . . . 14 5. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. The CA function enhancement . . . . . . . . . . . . . . . 15 5.2. The RP function enhancement . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction n RPKI, CAs (Certification Authorities) are organized in a hierarchical structure which is aligned to the existing INR (Internet Number Resources, including IP prefixes and AS numbers) allocation hierarchy. Each INR allocation requires corresponding resource certificates to attest to it. Two important resource certificates [RFC6480] are needed during this allocation process, and they are CA certificates and EE (End-entity) certificates: CA certificates attest to the INR holdings; EE certificates are primarily used for the validation of ROAs (Route Origin Authorizations) [RFC6482] which is used to verify whether an AS is permitted to originate routes to specific IP prefixes. Besides, Manifest [RFC6486] is used to ensure the integrity of the repository. So the operation of CA is very important for the RPKI deployment and applications based on it. Fu, et al. Expires September 11, 2016 [Page 2] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 Considering misoperation and malicious operation are inevitable and the significant impact they may cause, this draft describes and analyzes some scenarios of the unexpected resource assignment caused by CA in RPKI deployment. Then some experiments are given to show these scenarios more clearly. Some suggestions are also proposed to avoid corresponding side-effects. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. The scenarios of unexpected resource assignment As described in [RFC6480], the holder of resource ( IP addresses and AS numbers ) may reallocate portions of that block, to the sub-node, subject to contractual constraints established by the registries. But some scenarios of unexpected resource allocation may be caused by the misoperaion of malicious operation of the CA as below: for simplicity, we describe some scenarios with the AS number allocation case. 3.1. Unauthorized resource assignment For this scenario, a CA allocates a block of IP address which does not belong to him to subordinate node. That is, this CA doesn't own this block of IP Prefixes actually. So the sub-node cannot use these addresses. But in RPKI scenario, this assignment could be operated successfully. This scenario may be caused by misoperation of the CA or on purpose. According to the resources to be allocated, we divide this case into two kinds of scenarios: Completely unauthorized assignment and Partially unauthorized assignment. (1) Completely unauthorized assignment: the resources to be allocated to subordinate node are without the ownership of CA. (2) Partially unauthorized assignment: the resources to be allocated to subordinate node are with the partially ownership of CA. 3.2. Resource reassignment In this scenario, a CA reassign the resource to one sub-node which has been already assigned to another sub-node. This scenario could be sorted into three types: Fu, et al. Expires September 11, 2016 [Page 3] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 (1) Matching: the block of IP address which is reassigned is the same as which has been already assigned to the other sub-node. (2) Subset: The block of IP address which is reassigned is smaller than which has been already assigned to the other sub-node. (3) Intersection: The block of IP address which is reassigned has overlap with which has been already assigned to the other sub-node. 3.3. Resource transfer In practice, resource transfer between two Internet registries is reasonably achievable for most useful operational needs. For the resource transfer, a block of IP addresses will be transferred from one sub-node to the other. This scenario is described in [I-D.ymbk-sidr-transfer] in more detail. The resource reassignment may happened in this scenario by the misoperation of the CA. 4. Experimental Result We test the scenarios described above in our testbed. In this section, we present the test results for each case and analyze these results. 4.1. Unauthorized resource assignment 4.1.1. Completely unauthorized assignment The test scenario is described in Figure 1: APNIC allocates AS number 65551 and IP prefixes of 192.0.3.128/26 to TWNIC. But APNIC doesn't own this resource completely. We simulated this process of assignment on our testbed and the result is illustrated in Figure 2. Fu, et al. Expires September 11, 2016 [Page 4] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 ASNs; +-------------+ 64496-64511,65536-65551 | | IP prefixes: | IANA +---------192.0.2.0/24,198.51.100.0/24 | | 203.0.113.0/24 +------|------+ | +-------------+ ASNs | | 64497-64510,65537-65550 | | IP prefixes: | APNIC ---------192.0.2.128/25, | | 198.51.100.128/25 -------|------+ 203.0.113.128/25 | | | ----------------| | |--------------- | | | +-----------+ +------|------+ +-----------+ | JPNIC | | TWNIC | | CNNIC | +-----|-----+ +------|------+ +----|------+ | | | ASNs: ASNs: ASNs: 65540-65550 65551 64498-64505 IP prefixes IP prefixes IP prefixes: 203.0.113.128/26 192.0.3.128/26 192.0.2.128/26 198.51.100.128/26 Figure 1: The network architecture of the completely unauthorized assignment We test this case with the tools offered by http://rpki.net/. The result (as described in Figure 2) shows: APNIC has allocated the unauthorized resources (ASNs: 65551, IP prefixes: 192.0.3.128/26) to TWNIC successfully, but TWNIC did not receive these resources actually. Fu, et al. Expires September 11, 2016 [Page 5] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 root@ubuntu:~#rpkic -i cnnic show_received_resources Parent: apnic notBefore: 2015-07-15T15:53:25Z notAfter: 2016-07-14T15:36:05Z URI: rsync://localhost/rpki/iana/apnic/BqHiZw817JRhXby5cljw-Iy75c4.cer SIA URI: rsync://localhost/rpki/iana/apnic/cnnic/ AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer ASN: 64498-64505 IPv4: 192.0.2.128/26,198.51.100.128/26 IPv6: root@ubuntu:~# rpkic -i jpnic show_received_resources Parent: apnic notBefore: 2015-07-15T15:25:54Z notAfter: 2016-07-14T15:20:04Z URI: rsync://localhost/rpki/iana/apnic/NSt9KXs-a2py_OGZlol4fipm1lQ.cer SIA URI: rsync://localhost/rpki/iana/apnic/jpnic/ AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer ASN: 65540-65550 IPv4: 203.0.113.128/26 IPv6: root@ubuntu:~# rpkic -i twnic show_received_resources root@ubuntu:~# Figure 2: The test result of completely unauthorized assignment 4.1.2. Partially unauthorized assignment The test scenario is described in Figure 3: APNIC allocates ASNs ( 9700-9818 ) to JPNIC. But APNIC only take the ownership of ASNs ( 9801-9818 ). We simulated this process of assignment on our testbed and the result is illustrated in Figure 4. Fu, et al. Expires September 11, 2016 [Page 6] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 +-------------+ | | ASNs: | IANA +---------9800-9819,132176-132191 +------|------+ | +-------------+ | | ASNs: | APNIC ---------9801-9818,132177-132190 | | --------------+ | | ----------------| |--------------- | | +-----------+ +-----------+ | JPNIC | | CNNIC | +-----|-----+ +----|------+ | | ASNs: ASNs: 9700-9818 132178-132189 Figure 3: The network architecture of partially unauthorized assignment Our test result for this scenario (as described in Figure 4) shows: APNIC think that it has allocated the partially unauthorized resources to JPNIC successfully, but JPNIC only received the legal part (ASNs 9801-9818), without the illegal part (ASNs 9700-9800). Fu, et al. Expires September 11, 2016 [Page 7] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 root@ubuntu:~# rpkic -i apnic show_child_resources Child: cnnic ASN: 132178-132179 IPv4: 203.0.113.0/26,218.214.108.0/26 Child: jpnic ASN: 9700-9818 IPv4: 218.241.104.0/26 root@ubuntu:~#rpkic -i cnnic show_received_resources Parent: apnic notBefore: 2015-08-31T15:45:37Z notAfter: 2016-08-30T12:24:04Z URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer ASN: 132178-132189 IPv4: 203.0.113.0/26,218.214.108.0/26 IPv6: root@ubuntu:~# rpkic -i jpnic show_received_resources Parent: apnic notBefore: 2015-08-31T15:47:38Z notAfter: 2016-08-30T12:25:25Z URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer SIA URI: rsync://192.168.137.139/rpki/iana/apnic/jpnic/ AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer ASN: 9801-9818 IPv4: 218.241.104.0/26 IPv6: Figure 4: The test result of partially unauthorized assignment 4.2. Resource reassignment In the "Resource reassignment" case, we mean that a CA allocate the resources, which have been allocated to one subordinate CA ( e.g. CNNIC ), to another subordinate CA ( e.g. JPNIC ). This case may also be caused by misoperation of CA or on purpose. And it may result in resource conflicts in the Internet. 4.2.1. Matching case For the matching case, the test scenario is described in Figure 5: the resources to be allocated to JPNIC (ASNs 132178-132189) is identical to those allocated to CNNIC (ASNs 132178-132189). Fu, et al. Expires September 11, 2016 [Page 8] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 +-------------+ | | ASNs: | IANA +---------9800-9819,132176-132191 +------|------+ | +-------------+ | | ASNs: | APNIC ---------9801-9818,132177-132190 | | --------------+ | | ----------------| |--------------- | | +-----------+ +-----------+ | JPNIC | | CNNIC | +-----|-----+ +----|------+ | | ASNs: ASNs: 132178-132189 132178-132189 Figure 5: The network architecture of matching case We test this case with the tools offered by http://rpki.net/. The result (as described in Fig 6) is that both CNNIC and JPNIC can receive these ASNs at the same time. It may result in resource confliction in the internet. Fu, et al. Expires September 11, 2016 [Page 9] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 root@ubuntu:~# rpkic -i apnic show_child_resources Child: cnnic ASN: 132178-132189 IPv4: 203.0.113.0/26 Child: jpnic ASN: 132178-132189 IPv4: 203.0.113.0/26 root@ubuntu:~# rpkic -i jpnic show_received_resources Parent: apnic notBefore: 2015-08-31T13:43:18Z notAfter: 2016-08-30T12:25:25Z URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer ASN: 132178-132189 IPv4: 203.0.113.0/26 IPv6: root@ubuntu:~# rpkic -i cnnic show_received_resources Parent: apnic notBefore: 2015-08-31T13:39:19Z notAfter: 2016-08-30T12:24:04Z URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer ASN: 132178-132189 IPv4: 203.0.113.0/26 IPv6: Figure 6: The test result of matching case CNNIC and JPNIC receive the same resource assigned by the APNIC at the same time. So the same resource could be allocated to the different sub-node simultaneously. 4.2.2. Intersection case As is shown in Figure 7, in the intersection case, there is an overlap between the resources to be allocated to JPNIC (ASNs 132180-132190) and those allocated to CNNIC (ASNs 132177-132185). Fu, et al. Expires September 11, 2016 [Page 10] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 +-------------+ | | ASNs: | IANA +---------9800-9819,132176-132191 +------|------+ | +-------------+ | | ASNs: | APNIC ---------9801-9818,132177-132190 | | --------------+ | | ----------------| |--------------- | | +-----------+ +-----------+ | JPNIC | | CNNIC | +-----|-----+ +----|------+ | | ASNs: ASNs: 132180-132190 132177-132185 Figure 7: The network architecture of intersection case Our test result (as described in Figure 8) shows that both CNNIC and JPNIC can receive these ASNs. Fu, et al. Expires September 11, 2016 [Page 11] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 root@ubuntu:~# rpkic -i apnic show_child_resources Child: cnnic ASN: 132177-132185 IPv4: 203.0.113.0/26,218.241.108.0/26 Child: jpnic ASN: 132180-132190 IPv4: 218.241.104.0/26 root@ubuntu:~#rpkic -i cnnic show_received_resources Parent: apnic notBefore: 2015-08-31T14:58:54Z notAfter: 2016-08-30T12:24:04Z URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/ AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer ASN: 132177-132185 IPv4: 203.0.113.0/26,218.214.108.0/26 IPv6: root@ubuntu:~# rpkic -i jpnic show_received_resources Parent: apnic notBefore: 2015-08-31T14:58:44Z notAfter: 2016-08-30T12:25:25Z URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer SIA URI: rsync://192.168.137.139/rpki/iana/apnic/jpnic/ AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer ASN: 132180-132090 IPv4: 218.241.104.0/26 IPv6: Figure 8: The test result of intersection case 4.2.3. Subset case For the subset case, the network architecture is described in Figure 9: APNIC allocates the ASN 65540 and a block of IP address ( 203.0.113.128/26 ) to JPNIC. Then it reallocated this resources to CNNIC. These resources are the subset of CNNIC's resource. Fu, et al. Expires September 11, 2016 [Page 12] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 ASNs: +-------------+ 64496-64511,65536-65551 | | IP prefixes: | IANA +---------192.0.2.0/24,198.51.100.0/24 | | 203.0.113.0/24 +------|------+ | +-------------+ ASNs: | | 64497-64510,65537-65550 | | IP prefixes: | APNIC ---------192.0.2.128/25, | | 198.51.100.128/25 --------------+ 203.0.113.128/25 | | ----------------| |--------------- | | +-----------+ +-----------+ | JPNIC | | CNNIC | +-----|-----+ +----|------+ | | ASNs: ASNs: 65540 64498-64505,65540 IP prefixes IP prefixes: 203.0.113.128/26 192.0.2.128/26 198.51.100.128/26 203.0.113.128/26 Figure 9: The network architecture of subset case We test this case with the tools offered by http://rpki.net/. The result (as described in Fig 6 ) is that both CNNIC and JPNIC can receive these ASNs and IP Prefixes at the same time. It may result in resource confliction in the internet. Fu, et al. Expires September 11, 2016 [Page 13] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 root@ubuntu:~# rpkic -i apnic show_child_resources Child: cnnic ASN: 64498-64505,65540 IPv4: 192.0.2.128/26,198.51.100.128/26,203.0.113.128/26 Child: jpnic ASN: 65540 IPv4: 203.0.113.128/26 root@ubuntu:~# rpkic -i cnnic show_received_resources Parent: apnic notBefore: 2015-07-15T15:37:58Z notAfter: 2016-07-14T15:36:05Z URI: rsync://localhost/rpki/iana/apnic/BqHiZw817JRhXby5cljw-Iy75c4.cer SIA URI: rsync://localhost/rpki/iana/apnic/cnnic/ AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer ASN: 64498-64505,65540 IPv4: 192.0.2.128/26,198.51.100.128/26,203.0.113.128/26 IPv6: root@ubuntu:~# rpkic -i jpnic show_received_resources Parent: apnic notBefore: 2015-07-15T15:25:54Z notAfter: 2016-07-14T15:20:04Z URI: rsync://localhost/rpki/iana/apnic/NSt9KXs-a2py_OGZlol4fipm1lQ.cer SIA URI: rsync://localhost/rpki/iana/apnic/jpnic/ AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer ASN: 65540 IPv4: 203.0.113.128/26 IPv6: Figure 10: The test result of subset case CNNIC and JPNIC could receive the same resources assigned by APNIC at the same time. So the test result verify that the same resources could be allocated to different sub-nodes simultaneously. 4.3. Resource transfer This issue is described in [I-D.ymbk-sidr-transfer]. The most serious problem caused by it is the address reassignment described above. 5. Solutions In order to avoid the above issues or reduce the related side- effects, the following two solutions may be needed. Fu, et al. Expires September 11, 2016 [Page 14] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 5.1. The CA function enhancement We have designed a mechanism to enhance the CA function to avoid the above misoperation or malicious operation. The detail information will be given in the future. 5.2. The RP function enhancement The enhancement of RP function is needed to discover these resource assignment errors. 6. Security Considerations TBD. 7. IANA Considerations This draft does not request any IANA action. 8. Acknowledgements The authors would like to thanks the valuable comments made by XXX and other members of sidr WG. This document was produced using the xml2rfc tool [RFC2629]. 9. References 9.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, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, . Fu, et al. Expires September 11, 2016 [Page 15] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 9.2. Informative References [I-D.ymbk-sidr-transfer] Austein, R., Bush, R., Huston, G., and G. Michaelson, "Resource Transfer in the Resource Public Key Infrastructure", draft-ymbk-sidr-transfer-01 (work in progress), July 2015. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, . Authors' Addresses Yu Fu CNNIC No.4 South 4th Street, Zhongguancun Hai-Dian District, Beijing, 100190 P.R. China Email: fuyu@cnnic.cn Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: yanzhiwei@cnnic.cn Xiaowei Liu CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: liuxiaowei@cnnic.cn Fu, et al. Expires September 11, 2016 [Page 16] Internet-Draft draft-fu-sidr-unexpected-scenarios-01 March 2016 Cuicui Wang CNNIC No.4 South 4th Street, Zhongguancun Hai-Dian District, Beijing, 100190 P.R. China Email: wangcuicui@cnnic.cn Fu, et al. Expires September 11, 2016 [Page 17]