Secure Inter-Domain Routing Z. Yan Internet-Draft Y. Fu Intended status: Informational X. Liu Expires: November 7, 2016 G. Geng CNNIC May 6, 2016 Problem Statement and Considerations for ROA Mergence draft-yan-sidr-roa-mergence-00 Abstract The address space holder needs to issue an ROA object when it authorizes one or more ASes to originate routes to multiple prefixes. During the process of ROA issuance, the address space holder needs to specify an origin AS for a list of IP prefixes. Besides, the address space holder has a free choice to put multiple prefixes into a single ROA or issue separate ROAs for each prefix based on the current specification. This memo analyzes and presents some operational problems which may be caused by the misconfigurations of ROAs containing multiple IP prefixes. Some suggestions and considerations also have been proposed. 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 November 7, 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 Yan, et al. Expires November 7, 2016 [Page 1] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 (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 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. Problem statement and Analysis . . . . . . . . . . . . . . . 3 3.1. Statistical analysis of ROA mergence . . . . . . . . . . 3 3.2. Experimental analysis of ROA mergence . . . . . . . . . . 5 3.3. Problem statement . . . . . . . . . . . . . . . . . . . . 8 4. Suggestions and Considerations . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Route Origin Authorization (ROA) is a digitally signed object which is used to identify that a single AS has been authorized by the address space holder to originate routes to one or more prefixes within the address space[RFC6482].If the address space holder needs to authorize more than one ASes to advertise the same set of address prefixes, the holder must issue multiple ROAs, one per AS number. However, at present there are no mandatory requirements in any RFCs describing that the address space holders must issue a separate ROA for each prefix or a ROA for multiple prefixes. Each ROA contains an "asID" field and an "ipAddrBlocks" field. The "asID" field contains one single AS number which is authorized to originate routes to the given IP address prefixes. The "ipAddrBlocks" field contains one or more IP address prefixes to which the AS is authorized to originate the routes. The ROA mergence is a common case that each ROA contains exactly one AS number but may contain multiple IP address prefixes in the operational process of ROA issuance. Yan, et al. Expires November 7, 2016 [Page 2] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 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. Problem statement and Analysis 3.1. Statistical analysis of ROA mergence As mentioned above, the address space holder needs to issue an ROA object when it authorizes one or more ASes to originate routes to multiple prefixes. During the process of ROA issuance, the address space holder needs to specify an origin AS for a list of IP prefixes. Besides, the address space holder has a free choice to put multiple prefixes into a single ROA or issue separate ROAs for each prefix based on the current specification. On our RPKI testbed, the Trust Anchor Locator (TAL) files configured by RP correspond to the five RIRs' RPKI Trust Anchors. By using these TAL files, all the ROA objects issued in each region (the five RIRs) around the world are collected and validated with the RPKI Relying Party tools provided by rpki.net. According to the analysis on these data, some statistical results are described in Table. 1. +----------------+------------------------+-------------------------+ | The total | The number of ROAs | The number of ROAs with | | number of ROAs | with a single prefix | multiple prefixes | +----------------+------------------------+-------------------------+ | 5027 | 2341 | 2686 | +----------------+------------------------+-------------------------+ Table.1 Statistical results of all ROAs As shown in Table. 1, by now (as of April 19, 2016), the total number of ROA objects issued around the world is about 5027. The result is in accordance with the statistics provided by RIPE NCC and Internet Multifeed Co. (MF). Based on the further analysis on these ROA objects, it is found that: the number of ROAs containing only one prefix is about 2341 (account for 46.6% of all ROA objects), and the number of ROAs containing two or more prefixes is about 2686 (account for 53.4% of all ROA objects). In the 2686 ROA objects which each one contains two or more prefixes, the number of IP address prefixes are calculated and analyzed. The statistical results are shown in Table. 2. Yan, et al. Expires November 7, 2016 [Page 3] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 +------------------+---------------+--------------------------------+ | The number of | The number of | The average number of prefixes | | prefixes | ROAs | in each ROA | +------------------+---------------+--------------------------------+ | 20379 | 2686 | 7.59 | +------------------+---------------+--------------------------------+ Table. 2 Statistical results of the 2686 ROAs As described in Table. 2, there are 20379 IP address prefixes in the 2686 ROA objects. And the average number of prefixes in each ROA is 7.59 (20379/2686). In addition, four types of ROAs are analyzed and calculated in the 2686 ROAs: ROAs each contains 2-10/11-50/51-100/>100 IP address prefixes. The statistical results are presented in Table. 3. +----------+----------+-----------+-----------+-----------+---------+ | ROA | ROA with | ROA with | ROA with | ROA with | Total | | types | 2-10 | 11-50 | 51-100 | >100 | | | | prefixes | prefixes | prefixes | prefixes | | +----------+----------+-----------+-----------+-----------+---------+ | The | 2316 | 325 | 29 | 16 | 2686 | | number | | | | | | | of ROAs | | | | | | | The | 86.22% | 12.10% | 1.08% | 0.60% | 100.00% | | ratio of | | | | | | | ROAs | | | | | | | The | 8849 | 6563 | 1917 | 3050 | 20379 | | number | | | | | | | of | | | | | | | prefixes | | | | | | | The | 43.42% | 32.20% | 9.41% | 14.97% | 100.00% | | ratio of | | | | | | | prefixes | | | | | | +----------+----------+-----------+-----------+-----------+---------+ Table. 3 Statistical results of four types of ROAs As shown in Table. 3, taking the first type of ROA as an example, there are 2316 ROAs (account for 86.22% of the 2628 ROA objects) which each contains 2-10 IP address prefixes, and the total number of IP prefixes in these 2316 ROAs is 8849 (account for 43.42% of the 20379 prefixes). According to the third row (the ratio of ROAs) in Table. 3, it shows the trend that the address space holders tend to issue each ROA object with fewer IP prefixes (more than 98% of ROAs containing less Yan, et al. Expires November 7, 2016 [Page 4] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 than 50 prefixes), but they still tend to put multiple prefixes into one single ROA. It should also be paid more attention that among all the ROAs issued today, a single ROA may contain a large number of IP address prefixes. In the statistical results, it is found that there exists two ROAs (corresponding to ASN 3215 and ASN 9299) which each contains more than 300 IP address prefixes (324 and 375 respectively). 3.2. Experimental analysis of ROA mergence A large number of experiments for the process of ROA issuance have been made on our RPKI testbed, it is found that the misconfigurations during the issuance may cause the ROAs which have been issued to be revoked. The corresponding scenarios are as follows. AS shown in Fig. 1, an ISP needed to issue two ROA objects respectively to authorize ASN 64500 to originate routes to IP prefixes 192.0.2.128/28 and ASN 64501 to originate routes to IP prefixes 198.51.100.128/28. The operations are simulated on our RPKI testbed. Yan, et al. Expires November 7, 2016 [Page 5] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 +-----------+ | | ASNs: | IANA |----- 0-4294967295 | | IP Prefixes: | | 0.0.0.0/0 +-----|-----+ | ASNs: +-----|-----+ 64497-64510 | | 65537-65550 | | IP Prefixes | APNIC ------ 192.0.2.118/25 | | 198.51.100.128/25 | | 203.0.113.128/25 +-----|-----+ | +-----|-----+ ASNs: | | 64498-64505 | | IP Prefixes | | 192.0.2.128/26 | CNNIC ------ 198.51.100.128/26 | | 203.0.113.128/26 +-----|-----+ | +-----|-----+ | | ASNs: | | 64500-64505 | | IP Prefixes: | ISP ------ 192.0.2.128/27 | | 198.51.100.128/27 | | 203.0.113.128/27 +-----+-----+ | -------------- | //// \\\\ | // ROA1: \\ ---------------| 64500->192.0.2.128/28 | | ROA2: | | 64501->198.51.100.128/28 | \\ // \\\\ //// -------------- Fig. 1 Scenario of ROA issuance The ROA objects issued by ISP could be checked with the "show_published_objects" command. And as shown in Fig. 2, ISP has issued two ROA objects M74Rq1am9m4YUairntkXTRAx6Wg.roa and vulw_jMZBy7-ktn7nyhlpchBKZY.roa to respectively authorize ASN 64500 Yan, et al. Expires November 7, 2016 [Page 6] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 to originate routes to IP prefixes 192.0.2.128/28 and ASN 64501 to originate routes to IP prefixes 198.51.100.128/28. test@~$cat ISPROA.csv 192.0.2.128/28 64500 Group1 198.51.100.128/28 64501 Group2 test@~$ rpkic -i ISP load_roa_requests ISPROA.csv test@~$ rpkic -i ISP show_published_objects rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.crl 2016-04-19T10:34:04Z 594CB167AF4E81424EBEA7C1A5FD8DDE216D5C69 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft 2016-04-19T10:34:04Z 17C98CBFB179D60D9D0A6D52C2629B7A8DEA8A9C rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/M74Rq1am9m4YUairntkXTRAx6Wg.roa 2016-04-19T09:20:20Z 0CFD927D1522BF43FC52B748F274646387569222 64500 192.0.2.128/28 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vulw_jMZBY7-KTN7nyhlpchBKZY.roa 2016-04-19T10:34:04Z 305866D0c4ee5e156ebeda811d3540bf0e094043 64501 198.51.100.128/28 Fig. 2 Check the ROAs issued by ISP Afterwards, ISP wanted to authorize ASN 64501 to originate routes to another IP prefixes 203.0.113.128/28, so it modified the ISPROA.csv file and operated the "load_roa_requests" command again. test@~$cat ISPROA.csv 192.0.2.128/28 64500 Group1 198.51.100.128/28 64501 Group2 203.0.113.128/28 64501 Group2 test@~$ rpkic -i ISP load_roa_requests ISPROA.csv test@~$ rpkic -i ISP show_published_objects rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.crl 2016-04-19T10:38:03Z 2606EAA75AB60BE7785AE0CB0599D984AFD5BDB5 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft 2016-04-19T10:38:03Z 10F3F9249F0A6A636BF8143075693681B45A4BC2 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/M74Rq1am9m4YUairntkXTRAx6Wg.roa 2016-04-19T09:20:20Z 0CFD927D1522BF43FC52B748F274646387569222 64500 192.0.2.128/28 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vO3whtjMpYxxyva4BxRqI2H8eqA.roa 2016-04-19T10:38:03Z 4B85FDBABEC567A9DD8DA5745B34A201390F4530 64501 198.51.100.128/28,203.0.113.128/28 Fig. 3 Add a new authorization As shown in Fig. 3, after processing the above operations, a new ROA object vO3WhtjMpYxxyva4BxRqI2H8eqA.roa which contained two IP prefixes was issued. One thing which needs to be noticed is that in the ISPROA.csv file the third column of the last two lines (with Yan, et al. Expires November 7, 2016 [Page 7] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 respect to ASN 64501) are set as the same label "Group2" to make sure that the authorizations to the two IP prefixes will be issued into a single ROA. Now, ISP wants to authorize ASN 64500 to originate routes to IP prefixes 203.0.113.128/28 as well, but when it modifies the ISPROA.csv file, it appends 204.0.113.128/28 (or any prefixes that do not belong to ISP) instead of 203.0.113.128/28 into the ISPROA.csv file by mistake. And then, when it operates the "load_roa_requests" command, something unexpected will happen. test@~$cat ISPROA.csv 192.0.2.128/28 64500 Group1 204.0.113.128/28 64500 Group1 198.51.100.128/28 64501 Group2 203.0.113.128/28 64501 Group2 test@~$ rpkic -i ISP load_roa_requests ISPROA.csv test@~$ rpkic -i ISP show_published_objects rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.crl 2016-04-19T12:39:47Z 2DD037213237D72AF6CE95F8F37D1F08E8B49A37 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft 2016-04-19T12:39:47Z 735D9723B8C6D8214DA78117D27E529AA47E14B6 rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vO3whtjMpYxxyva4BxRqI2H8eqA.roa 2016-04-19T10:38:03Z 4B85FDBABEC567A9DD8DA5745B34A201390F4530 64501 198.51.100.128/28,203.0.113.128/28 Fig. 4 Add an incorrect authorization by mistake As shown in Fig. 4, a legitimate ROA object was revoked because of ISP's misconfiguration. Obviously, this misconfiguration may lead to some serious consequences to RPKI (such as legitimate BGP routes are misclassified as "invalid"). 3.3. Problem statement It concludes that the misconfigurations of ROAs containing multiple IP address prefixes may lead to much more serious consequences than ROAs with fewer IP address prefixes. According to the above statistical and experimental analysis, misconfigurations of the ROAs which contain more than 300 IP address prefixes may cause a large- scale network interruption. Another potential influence of misconfigurations of ROAs containing multiple IP prefixes on BGP routers may be considered. For the ROA containing multiple prefixes, once increase or delete one pair in it, this ROA will be reissued. Through sychronization with repository, RPs fetch a new ROA object and then notify and send all the pairs in this ROA to BGP Yan, et al. Expires November 7, 2016 [Page 8] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 routers. That is to say, the update of the ROA containing multiple IP address prefixes will lead to redundant transmission between RP and BGP routers . So frequent update of these ROAs will increase the convergency time of BGP routers and reduce their performance obviously. 4. Suggestions and Considerations Based on the statistical and experimental analysis, following considerations should be considered during the process of ROA issuance: 1) The issuance of ROAs containing a large number of IP prefixes may lead to misconfigurations more easily than ROAs with fewer IP prefixes. A ROA which contains a large number of IP prefixes is more vulnerable to misconfigurations, because any misconfiguration of these prefixes may cause the legitimate ROA to be revoked. Besides, since the misconfigurations of ROAs containing a larger number of IP address prefixes may lead to much more serious consequences (a large-scale network interruption) than ROAs with fewer IP address prefixes, it is suggested to avoid issuing ROAs with a large number of IP address prefixes. 2) The number of ROAs containing multiple IP prefixes should be limited and the number of IP prefixes in each ROA should also be limited. The extreme case (a single ROA can only contain one IP address prefix) may lead to too much ROA objects globally, which may in turn become a burden for RPs to synchronize and validate all these ROA objects with the fully deployment of RPKI. So a tradeoff between the number of ROAs and the number of IP prefixes in a single ROA should be considered. 3) A safeguard scheme is essential to protect the process of ROA issuance Considering the misconfigurations during the process of ROA issuance are inevitable and the serious consequences they may lead to, a safeguard scheme to protect and monitor the process of ROA issuance should be considered. Yan, et al. Expires November 7, 2016 [Page 9] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 5. Security Considerations TBD. 6. IANA Considerations This draft does not request any IANA action. 7. 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]. 8. References 8.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, . 8.2. Informative References [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, . Yan, et al. Expires November 7, 2016 [Page 10] Internet-Draft draft-yan-sidr-roa-mergence-00 May 2016 Authors' Addresses Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: yanzhiwei@cnnic.cn Yu Fu CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: fuyu@cnnic.cn Xiaowei Liu CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: liuxiaowei@cnnic.cn Guanggang Geng CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: gengguanggang@cnnic.cn Yan, et al. Expires November 7, 2016 [Page 11]