commit e1370641a53ea8286b1f4889d8117c2e30aaa76a Author: Randy Bush Date: Tue Sep 3 06:20:00 2019 -0700 initial from cnnic diff --git a/Makefile b/Makefile new file mode 100755 index 0000000..05f8c9f --- /dev/null +++ b/Makefile @@ -0,0 +1,19 @@ +# +# Makefile for I-D's and RFCs +# $Id: Makefile,v 1.1.1.1 2002-11-11 05:11:48 randy Exp $ +# + +# Your nroff document is called foo.txt. Change below as appropiate. +NAME=draft-yan-sidrops-roa-considerations +DEST=psg.com:public_html +RSY=rsync --rsh ssh -v -a -l -H -p -t -x --delete + +all: $(NAME).xml + xml2rfc $(NAME).xml --html --text + +rsy: + $(RSY) $(NAME).html $(DEST) + $(RSY) $(NAME).txt $(DEST) + +clean: + rm -f *.html *.txt diff --git a/draft-yan-sidrops-roa-considerations.xml b/draft-yan-sidrops-roa-considerations.xml new file mode 100644 index 0000000..1dd49f8 --- /dev/null +++ b/draft-yan-sidrops-roa-considerations.xml @@ -0,0 +1,555 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + Problem Statement + and Considerations for ROAs issued with Multiple Prefixes + + + CNNIC + +
+ + No.4 South 4th Street, Zhongguancun + + Beijing, 100190 + + P.R. China + + + yanzhiwei@cnnic.cn +
+ + + + CNNIC +
+ + 4 South 4th Street,Zhongguancun,Haidian District + Beijing + Beijing + 100190 + China + + +86 10 5881 3007 + yaojk@cnnic.cn +
+ + + + ISCAS + +
+ + Institute of Software Chinese Academy of Sciences + + Beijing, 100190 + + P.R. China + + + liuxiaowei@iscas.ac.cn +
+ + + + CNNIC + +
+ + No.4 South 4th Street, Zhongguancun + + Beijing, 100190 + + + + + + P.R. China + + + + + + + gengguanggang@cnnic.cn + + +
+ + + + + + +
+ + + eleven711711@foxmail.com +
+ + + + + + + Operations and Management Area (ops) + + SIDR Operations + + ROA + + + 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. + + + + +
+ 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.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 ROAs with multiple prefixes 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. +
+ +
+ 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 . +
+ +
+
+ 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 number of ROAs + + The number of ROAs with a single prefix + + The number of ROAs with multiple prefixes + + 7166 + + 3307 + + 3859 + + + As shown in Table. 1, by the July 4, 2017, the total number of ROA + objects issued around the world is about 7166. 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 3307 (account for 46.1% of all ROA objects), and the + number of ROAs containing two or more prefixes is about 3859 (account + for 53.9% of all ROA objects). + + In the 3859 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. + + + The number of prefixes + + The number of ROAs + + The average number of prefixes in each ROA + + 37367 + + 3859 + + 9.68 + + + As described in Table. 2, there are 37367 IP address prefixes in + the 3859 ROA objects. And the average number of prefixes in each ROA + is 9.68 (37367/3859). In addition, four types of ROAs are analyzed and + calculated in the 3859 ROAs: ROAs each contains + 2-10/11-50/51-100/>100 IP address prefixes. The statistical results + are presented in Table. 3. + + + ROA types + + ROA with 2-10 prefixes + + ROA with 11-50 prefixes + + ROA with 51-100 prefixes + + ROA with >100 prefixes + + Total + + The number of ROAs + + 3263 + + 496 + + 60 + + 40 + + 3859 + + The ratio of ROAs + + 84.56% + + 12.85% + + 1.55% + + 1.04% + + 100.00% + + The number of prefixes + + 12442 + + 10365 + + 4125 + + 10435 + + 37367 + + The ratio of prefixes + + 33.30% + + 27.74% + + 11.04% + + 27.93% + + 100.00% + + + As shown in Table. 3, taking the first type of ROA as an example, + there are 3263 ROAs (account for 84.56% of the 3859 ROA objects) which + each contains 2-10 IP address prefixes, and the total number of IP + prefixes in these 3263 ROAs is 12442 (account for 33.29% of the 37367 + 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 60% of ROAs containing less + 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 24440 and ASN 23752) which each + contains more than 700 IP address prefixes (796 and 892 + respectively). +
+ +
+ 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. + +
+ 192.0.2.128/28 | + | ROA2: | + | 64501->198.51.100.128/28 | + \\ // + \\\\ //// + -------------- + ]]> +
+ + 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 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. + +
+ +
+ + Then, 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. + +
+ +
+ + As shown in Fig. 3, so a new ROA object + vO3WhtjMpYxxyva4BxRqI2H8eqA.roa which contained two IP prefixes was + issued. It should be noticed that in the ISPROA.csv file the third + column of the last two lines (with 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 happened. + +
+ +
+ + 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 "not found"). +
+ +
+ It shows 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 <AS, + ip_prefix> 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 <AS, ip_prefix> pairs in this ROA to BGP + 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. +
+
+ +
+ Based on the statistical and experimental analysis, following + suggestions 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. + + So it is also recommended in the last paragraph of the section 4.2.5 + of that + opterators MAY issue separate ROAs for each IP address prefix, so that + the loss of on IP address prefix from the VRS-IP of any certificate + along the path to the trust anchor would not invalidate authorizations + for other 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. +
+ +
+ TBD. +
+ +
+ This document does not request any IANA action. +
+ +
+ The authors would like to thanks the valuable comments made by members of sidrops WG. + + This document was produced using the xml2rfc tool . +
+ + + + + + + + + + + + + + + +