randy/draft-roa-consideratins
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

initial from cnnic

Browse source
This commit is contained in:
Randy Bush 2019-09-03 06:20:00 -07:00
commit e1370641a5
2 changed files with 574 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

555
draft-yan-sidrops-roa-considerations.xml Normal file
View file

@ -0,0 +1,555 @@
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-yan-sidrops-roa-considerations-02"
ipr="trust200902">
<front>
<title abbrev="draft-yan-sidrops-roa-considerations">Problem Statement
and Considerations for ROAs issued with Multiple Prefixes</title>
<author fullname="Zhiwei Yan" initials="Z." surname="Yan">
<organization>CNNIC</organization>
<address>
<postal>
<street>No.4 South 4th Street, Zhongguancun</street>
<city>Beijing, 100190</city>
<country>P.R. China</country>
</postal>
<email>yanzhiwei@cnnic.cn</email>
</address>
</author>
<author fullname="Jiankang Yao" initials="J." surname="Yao" >
<organization>CNNIC</organization>
<address>
<postal>
<street>4 South 4th Street,Zhongguancun,Haidian District</street>
<city>Beijing</city>
<region>Beijing</region>
<code>100190</code>
<country>China</country>
</postal>
<phone>+86 10 5881 3007</phone>
<email>yaojk@cnnic.cn</email>
</address>
</author>
<author fullname="Xiaowei Liu" initials="X." surname="Liu">
<organization>ISCAS</organization>
<address>
<postal>
<street>Institute of Software Chinese Academy of Sciences</street>
<city>Beijing, 100190</city>
<country>P.R. China</country>
</postal>
<email>liuxiaowei@iscas.ac.cn</email>
</address>
</author>
<author fullname="Guanggang Geng" initials="G." surname="Geng">
<organization>CNNIC</organization>
<address>
<postal>
<street>No.4 South 4th Street, Zhongguancun</street>
<city>Beijing, 100190</city>
<region/>
<code/>
<country>P.R. China</country>
</postal>
<phone/>
<facsimile/>
<email>gengguanggang@cnnic.cn</email>
<uri/>
</address>
</author>
<author fullname="Yu Fu" initials="Y." surname="Fu">
<address>
<email>eleven711711@foxmail.com</email>
</address>
</author>
<date month="March" year="2019"/>
<area>Operations and Management Area (ops)</area>
<workgroup>SIDR Operations</workgroup>
<keyword>ROA</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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<xref target="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.</t>
<t>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.</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
<section title="Problem statement and Analysis">
<section title="Statistical analysis">
<t>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.</t>
<t>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.</t>
<texttable title="Table.1 Statistical results of all ROAs">
<ttcol>The total number of ROAs</ttcol>
<ttcol>The number of ROAs with a single prefix</ttcol>
<ttcol>The number of ROAs with multiple prefixes</ttcol>
<c>7166</c>
<c>3307</c>
<c>3859</c>
</texttable>
<t>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).</t>
<t>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.</t>
<texttable title="Table. 2 Statistical results of the 3859 ROAs">
<ttcol>The number of prefixes</ttcol>
<ttcol>The number of ROAs</ttcol>
<ttcol>The average number of prefixes in each ROA</ttcol>
<c>37367</c>
<c>3859</c>
<c>9.68</c>
</texttable>
<t>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/&gt;100 IP address prefixes. The statistical results
are presented in Table. 3.</t>
<texttable title="Table. 3 Statistical results of four types of ROAs">
<ttcol>ROA types</ttcol>
<ttcol>ROA with 2-10 prefixes</ttcol>
<ttcol>ROA with 11-50 prefixes</ttcol>
<ttcol>ROA with 51-100 prefixes</ttcol>
<ttcol>ROA with &gt;100 prefixes</ttcol>
<ttcol>Total</ttcol>
<c>The number of ROAs</c>
<c>3263</c>
<c>496</c>
<c>60</c>
<c>40</c>
<c>3859</c>
<c>The ratio of ROAs</c>
<c>84.56%</c>
<c>12.85%</c>
<c>1.55%</c>
<c>1.04%</c>
<c>100.00%</c>
<c>The number of prefixes</c>
<c>12442</c>
<c>10365</c>
<c>4125</c>
<c>10435</c>
<c>37367</c>
<c>The ratio of prefixes</c>
<c>33.30%</c>
<c>27.74%</c>
<c>11.04%</c>
<c>27.93%</c>
<c>100.00%</c>
</texttable>
<t>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).</t>
<t>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.</t>
<t>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).</t>
</section>
<section title="Experimental analysis">
<t>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.</t>
<t>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.</t>
<figure title="Fig. 1 Scenario of ROA issuance">
<artwork><![CDATA[
+-----------+
| | 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 |
\\ //
\\\\ ////
--------------
]]></artwork>
</figure>
<t>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.</t>
<figure title="Fig. 2 Check the ROAs issued by ISP">
<artwork><![CDATA[ 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
2017-07-19T10:34:04Z 594CB167AF4E81424EBEA7C1A5FD8DDE216D5C69
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft
2017-07-19T10:34:04Z 17C98CBFB179D60D9D0A6D52C2629B7A8DEA8A9C
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/M74Rq1am9m4YUairntkXTRAx6Wg.roa
2017-07-19T09:20:20Z 0CFD927D1522BF43FC52B748F274646387569222
64500 192.0.2.128/28
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vulw_jMZBY7-KTN7nyhlpchBKZY.roa
2017-07-19T10:34:04Z 305866D0c4ee5e156ebeda811d3540bf0e094043
64501 198.51.100.128/28
]]></artwork>
</figure>
<t>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.</t>
<figure title="Fig. 3 Add a new authorization">
<artwork><![CDATA[ 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
2017-07-19T10:38:03Z 2606EAA75AB60BE7785AE0CB0599D984AFD5BDB5
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft
2017-07-19T10:38:03Z 10F3F9249F0A6A636BF8143075693681B45A4BC2
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/M74Rq1am9m4YUairntkXTRAx6Wg.roa
2017-07-19T09:20:20Z 0CFD927D1522BF43FC52B748F274646387569222
64500 192.0.2.128/28
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vO3whtjMpYxxyva4BxRqI2H8eqA.roa
2017-07-19T10:38:03Z 4B85FDBABEC567A9DD8DA5745B34A201390F4530
64501 198.51.100.128/28,203.0.113.128/28 ]]></artwork>
</figure>
<t>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.</t>
<t>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.</t>
<figure title="Fig. 4 Add an incorrect authorization by mistake">
<artwork><![CDATA[ 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
2017-07-19T12:39:47Z 2DD037213237D72AF6CE95F8F37D1F08E8B49A37
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/duPylfF7Hv31rpOa4dVVCZnRkmk.mft
2017-07-19T12:39:47Z 735D9723B8C6D8214DA78117D27E529AA47E14B6
rsync://ubuntu/rpki/IANA/APNIC/CNNIC/ISP/vO3whtjMpYxxyva4BxRqI2H8eqA.roa
2017-07-19T10:38:03Z 4B85FDBABEC567A9DD8DA5745B34A201390F4530
64501 198.51.100.128/28,203.0.113.128/28 ]]></artwork>
</figure>
<t>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").</t>
</section>
<section title="Problem statement">
<t>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.</t>
<t>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 &lt;AS,
ip_prefix&gt; 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 &lt;AS, ip_prefix&gt; 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.</t>
</section>
</section>
<section title="Suggestions and Considerations">
<t>Based on the statistical and experimental analysis, following
suggestions should be considered during the process of ROA issuance:</t>
<t>1) The issuance of ROAs containing a large number of IP prefixes may
lead to misconfigurations more easily than ROAs with fewer IP
prefixes.</t>
<t>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.</t>
<t>So it is also recommended in the last paragraph of the section 4.2.5
of <xref target="I-D.ietf-sidr-rpki-validation-reconsidered"/> 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.</t>
<t>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.</t>
<t>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.</t>
<t>3) A safeguard scheme is essential to protect the process of ROA
issuance</t>
<t>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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not request any IANA action.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thanks the valuable comments made by members of sidrops WG.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.6482'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.I-D.ietf-sidr-rpki-validation-reconsidered'?>
</references>
</back>
</rfc>