<?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-ietf-sidrops-roa-considerations-02"
     ipr="trust200902">
  <front>
    <title abbrev="ROA considerations">Avoidance for ROA Containing Multiple IP 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="Randy Bush" initials="R." surname="Bush">
      <organization>Internet Initiative Japan</organization>
      <address>
        <email>randy@psg.com</email>
      </address>
    </author>
    
<author fullname="Guanggang Geng" initials="G.G." surname="Geng"> 
<organization>Jinan University</organization> <address> <postal> <street>No.601, West Huangpu Avenue</street> <code>510632</code> <city>Guangzhou</city> 
<country>China</country> </postal> <email>gggeng@jnu.edu.cn</email> </address> 
</author>

   <author	fullname="Jiankang Yao" initials="J." surname="Yao" >
	  <organization>CNNIC</organization>
	  <address>
        <postal>
          <street>No.4 South 4th Street, Zhongguancun</street>
          <city>Beijing, 100190</city>
          <country>P.R. China</country>
        </postal>
	  <email>yaojk@cnnic.cn</email>
	  </address>
	</author>

	
	

    <date month="April" year="2022"/>

    <area>Operations and Management Area (ops)</area>

    <workgroup>SIDR Operations</workgroup>

    <keyword>ROA</keyword>

    <abstract>
      <t>In RPKI, the address space holder needs to issue an ROA object when authorizing one or more ASes to originate routes to IP prefix(es). During ROA issurance process, the address space holder may need to specify an origin AS for a list of IP prefixes. Additionally, the address space holder is free to choose to put multiple prefixes into a single ROA or issue separate ROAs for each prefix according to the current specification. This memo analyzes some operational problems which may arise from ROAs containing multiple IP prefixes and recommends avoiding placing multiple IP prefixes in one ROA.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>In Resource Public Key Infrastructure (RPKI), Route Origin Authorization (ROA) is a digitally signed object which identifies 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"/>.</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. 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 for each AS number. However, at present there are no mandatory requirements describing that the address space holders must issue a separate ROA for each prefix or a ROA containing multiple prefixes.</t>    
   
    </section>

    <section title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

    </section>

    <section title="Problem statement and Analysis">
        
       <t>Currently, there are about 24% ROAs containing two or more prefixes. Among them, the average number of prefixes per ROA exceeds 10. </t>
 
        <t>For ROAs containing multiple prefixes, adding or deleting one &lt;AS, ip_prefix&gt; pair, the entire ROA must be withdrawn and reissued, or covered by a new ROA. That is, although aggregating multiple IP prefixes can reduce the number of issued ROA, updating an ROA containing multiple IP address prefixes will result in redundant transmission between RP and BGP routers because in reality just the changed IP prefix needs to be updated by the new ROA. Updating these ROAs frequently will increase the convergence time of BGP routers and reduce the stability of RPKI and BGP system.</t>
        
        <t>In addition, ROAs have a long validity period in default, during which the prefix ownership is more likely to change (of course, resource shrink may happen at any time), which will lead to the withdrawal or reissue of the whole set of prefixes aggregated within the same ROA. This will increase the mis-configuration possibility and operational complexity <xref target="RFC8211"/>. If one prefix is included in the list by mistake, the whole ROA will not be generated successfully. </t>
      </section>

    <section title="Suggestions">
      <t>The following suggestions should be considered during the process of ROA issurance:</t>

      <t>1) It's the most important to guarantee the stability and security of RPKI and BGP system, and it is recommended to include a single IP prefix in each ROA in default.</t>

      <t>2) In some special scenarios, where the resource is very stable or a CA has operational problems producing increased number of individual ROAs, multiple IP prefixes may be aggregated in one ROA.</t>

    

    </section>

    <section anchor="Security" title="Security Considerations">
     <t>This memo does not give rise to additional security risks.</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 and the list will be updated later.</t>
      <t>This work was supported by the Beijing Nova Program of Science and Technology under grant Z191100001119113.</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.2629'?>
      <?rfc include='reference.RFC.8174'?>
      </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.6482'?>
      <?rfc include='reference.RFC.8211'?>
    </references>
    
        <section anchor="APPENDIX" title="ROA Analysis">
       <t>
        In order to illustrate the situations of the current ROA database, the following analysis is made.       
        </t>
        
 <figure anchor="fig:global" title="Statistical results of global ROAs">
      <artwork><![CDATA[       
 +-------------- -+----------------------+-------------------------+
 | The total      | The number of ROAs   | The number of ROAs with |
 | number of ROAs | with a single prefix | multiple prefixes       |
 +----------------+----------------------+-------------------------+
 | 105542         | 81759                | 23783                   |
 +----------------+----------------------+-------------------------+
    ]]></artwork>
      </figure>


<t>As shown in Figure. 1, by April 24th 2022, the total number
 of ROA objects issued is about 105542. Based on the further analysis on these ROA
 objects, it is found that the number of ROAs containing only one
 prefix is about 81759 (77.47% of all ROA objects), and the
 number of ROAs containing two or more prefixes is about 23783 (22.53% of all ROA objects).</t>

 <t>In the 23783 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 Figure. 2.</t>
  
  <figure anchor="fig:Number" title="Statistical results of the ROAs with multiple prefixes">
      <artwork><![CDATA[   
 +----------------+----------------+--------------------------------+
 | The number of  | The number of  | The average number of prefixes |
 | prefixes       |  ROAs          |  in each ROA                   |
 +----------------+----------------+--------------------------------+
 | 248693         | 23783          |  10.46                         |
 +----------------+----------------+--------------------------------+
     ]]></artwork>
      </figure>
      

<t>As described in Figure. 2, there are 248693 IP address prefixes in the
 23783 ROA objects. And the average number of prefixes in each ROA is
 10.46 (248693/23783). In addition, four types of ROAs are analyzed and
 calculated within the 23783 ROAs: ROAs each contains
 2-10/11-50/51-100/>100 IP address prefixes. The statistical results
 are presented in Figure. 3.</t>
 
   <figure anchor="fig:ROAs" title="Statistical results of four types of ROAs">
      <artwork><![CDATA[   
 +----------+----------+----------+----------+----------+-------+
 | ROA      | ROA with | ROA with | ROA with | ROA with | Total |
 | types    | 2-10     | 11-50    | 51-100   | >100     | number|
 |          | prefixes | prefixes | prefixes | prefixes |       |
 +----------+----------+----------+----------+----------+-------+
 | The      |  20286   |   2880   |    322   |    295   | 23783 |
 | number   |          |          |          |          |       |
 | of ROAs  |          |          |          |          |       |
 +----------+----------+----------+----------+----------+-------+
 | The      | 85.30%   |  12.11%  |  1.35%   |  1.24%   | 100%  |
 | ratio of |          |          |          |          |       |
 | ROAs     |          |          |          |          |       |
 +----------+----------+----------+----------+----------+-------+
 | The      |  74504   |  59015   |  22244   |  92930   |248693 |
 | number   |          |          |          |          |       |
 | of       |          |          |          |          |       |
 | prefixes |          |          |          |          |       |
 +----------+----------+----------+----------+----------+-------+ 
 | The      | 29.96%   | 23.73%   |  8.94%   | 37.37%   | 100%  |
 | ratio of |          |          |          |          |       |
 | prefixes |          |          |          |          |       |
 +----------+----------+----------+----------+----------+-------+
     ]]></artwork>
      </figure>
      
<t>As shown in Figure. 3, taking the first type of ROA as an example,
 there are 20286 ROAs (85.3% of the 23783 ROA objects)
 which each contains 2-10 IP address prefixes, and the total number of
 IP prefixes in these 20286 ROAs is 74504 (29.96% of the
 248693 prefixes).</t>

<t>It shows that the address space holders tend to issue each ROA
 object with fewer IP prefixes (more than 95% of ROAs containing less
 than 50 prefixes), but they still tend to put multiple prefixes into
 one single ROA.</t>
 
<t>The longest and shortest validity periods of a single ROA is 28854 days and 2 days. In addition, the average validity period of each ROA is 707.83 days.</t>
      
    </section>
  
  
    
    
    
  </back>
  
  
 
  
</rfc>
