<?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 --> encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="bcp" consensus="true" docName="draft-ietf-sidrops-roa-considerations-08"
ipr="trust200902"> number="9455" ipr="trust200902" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.17.1 -->
  <front>

    <title abbrev="ROA considerations">Avoidance of ROA Considerations">Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP
	Prefixes</title> Prefixes
</title>
    <seriesInfo name="RFC" value="9455"/>
    <seriesInfo name="BCP" value="238"/>
    <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>
          <city>Beijing</city>
          <code>100190</code>
          <country>China</country>
        </postal>
        <email>yanzhiwei@cnnic.cn</email>
      </address>
    </author>
    <author fullname="Randy Bush" initials="R." surname="Bush">
      <organization>IIJ Research Lab &amp; Arrcus, Inc.</organization>
      <address>
        <postal>
          <street>5147 Crystal Springs</street>
          <city>Bainbridge Island</city>
          <region>Washington</region>
          <code>98110</code>
          <country>United States of America</country>
        </postal>
        <email>randy@psg.com</email>
      </address>
    </author>
    <author fullname="Guanggang Geng" initials="G.G." initials="G." surname="Geng">
      <organization>Jinan University</organization>
      <address>
        <postal>
          <street>No.601, West Huangpu Avenue</street>
          <code>510632</code>
          <city>Guangzhou</city>
			<country>P.R. China</country>
          <country>China</country>
        </postal>
        <email>gggeng@jnu.edu.cn</email>
      </address>
    </author>
    <author fullname="Ties de Kock" initials="T." surname="de Kock" > Kock">
      <organization>RIPE NCC</organization>
      <address>
        <postal>
          <street>Stationsplein 11</street>
          <city>Amsterdam</city>
          <country>Netherlands</country>
        </postal>
        <email>tdekock@ripe.net</email>
      </address>
    </author>
    <author fullname="Jiankang Yao" initials="J." surname="Yao" > surname="Yao">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>No.4 South 4th Street, Zhongguancun</street>
			<city>Beijing, 100190</city>
			<country>P.R. China</country>
          <city>Beijing</city>
          <code>100190</code>
          <country>China</country>
        </postal>
        <email>yaojk@cnnic.cn</email>
      </address>
    </author>
    <date month="April" month="August" year="2023"/>
	<area>Operations and Management Area (ops)</area>
	<workgroup>SIDR Operations</workgroup>
    <area>ops</area>
    <workgroup>sidrops</workgroup>
    <keyword>ROA</keyword>
    <keyword>Route Origin Authorization</keyword>

    <abstract>
      <t>When using the Resource Public Key Infrastructure (RPKI),
      address space holders need to issue Route Origin Authorization (ROA)
      object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es).
      This memo discusses operational problems which that may arise from
      ROAs containing multiple IP prefixes and recommends that each ROA
      contains
      contain a single IP prefix.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
    <section>
      <name>Introduction</name>
      <t>In the RPKI, a ROA ROA, which is a digitally signed object which object, identifies that a
      single AS has been authorized by the address space
      holder to originate BGP routes to one or more IP prefixes within the related address
      space <xref target="RFC6482"/>.</t>
      <t>Each ROA contains an "asID" asID field and an "ipAddrBlocks" ipAddrBlocks field. The
      "asID"
      asID field contains a single AS number which that is authorized to
      originate routes to the given IP address prefix(es). The "ipAddrBlocks" ipAddrBlocks
      field contains one or more IP address prefixes to which the AS is
      authorized to originate the routes.</t>
      <t>If the address space holder needs to authorize more than one AS to
      advertise the same set of IP prefixes, multiple ROAs must be issued (one
      for each AS number <xref target="RFC6480"/>). Prior to this document,
      there was no guidance recommending the issuance of a separate ROA for each IP
      prefix or a single ROA containing multiple IP prefixes.</t>
    </section>

    <section title="Terminology">
      <t>The
    <section>
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
    </section>

    <section title="Problem Statement">
    <section>
      <name>Problem Statement</name>
      <t>An address space holder can issue a separate ROA for each of its
      routing announcements. Alternatively, for a given asID, it can issue a
      single ROA for multiple routing announcements, or even for all of its
      routing announcements. Since a given ROA is either valid or invalid, the
      routing announcements for which that ROA was issued will "share fate"
      when it comes to RPKI validation. Currently, no guidance is offered in existing RFCs to recommend provide recommendations about what kinds of ROA are issued: ROAs to issue: one per prefix, prefix
      or one ROA for multiple routing announcements. The problem of
      fate-sharing was not discussed or addressed.</t>

      <t>In
      <t>  In the RPKI trust chain, the Certification Authority (CA) certificate
  issued by a parent CA to a delegate delegatee of some resources may be revoked
  by the parent at any time resulting time, which would result in changes to resources specified
  in the
      <xref target="RFC3779"/> certificate extension. extensions defined in <xref target="RFC3779"/>. Any ROA object that
      includes resources which that are a) no longer entirely contained in the new CA
      certificate,
      certificate or b) contained in a new CA certificate that has not yet
      been discovered by Relying Party (RP) software, software will be rejected as invalid.
      Since ROA invalidity affects all routes specified in that ROA, unchanged
      resources with associated routes via that asID cannot be separated from
      those affected by the change in the CA certificate validity. They will
      fall under this invalid ROA even though there was no intention intent to change
      their validity. Had these resources been in a separate ROA, there would
      have been
      be no change to the issuing CA certificate, certificate and therefore no
      subsequent invalidity.</t>

      <t>CAs have to carefully coordinate ROA updates with updates to a resource certificate
      updates. certificate.
      This process may be automated if a single entity manages both
      the parent CA and the CA issuing the ROAs (Scenario D in <xref
      target="RFC8211"/> Section 3). target="RFC8211" sectionFormat="comma" section="3.4"/>). However, in other deployment scenarios,
      this coordination becomes more complex.</t>
      <t>As there is a single expiration time for the entire ROA, expiration
      will affect all prefixes in the ROA.
   Thus, any changes to the ROA for any of the prefixes must be synchronized
   with any changes to other prefixes, especially time-limitations on when authorization for a prefix.
   prefix is time bounded.
      Had these prefixes been in separately issued ROAs, the validity interval would be
      unique to each ROA, and invalidity would only be affected by re-issuance reissuance of
      the specific issuing parent CA certificate which issued them.</t> certificate.</t>
      <t>A prefix could be allowed to be originated originate from an AS only for a
      specific period of time, for example example, if the IP prefix was leased out
      temporarily. This If a ROA with multiple IP prefixes was used, this would be more difficult to manage, and potentially be more error-prone if a ROA with multiple IP prefixes was used. Similarly error-prone. Similarly,
      more complex routing may demand require changes in asID or routes for a subset of
      prefixes. Re-issuance
   Reissuance of the a ROA may cause change might result in changes to the validity for all of
   previously received BGP routes in covered by the affected ROA. If ROA's prefixes.
  There will be no change to the time limited validity of unaffected routes if
  a) the time-limited resources are in separate ROAs, or b) for more
  complex routing if routing, each change in asID or a change in routes for a
  given prefix is reflected in a change to a discrete ROA,
      then no change to validity of unaffected routes will be caused.</t> ROA. </t>
      <t>The use of ROA with a single IP prefix can minimize these
      side-effects.
      side effects. It avoids fate-sharing irrespective of the causes, cause, where
      the parent CA issuing each ROA remains valid and where each ROA itself
      remains valid.</t>
    </section>

    <section title="Recommendations">
    <section>
      <name>Recommendations</name>
      <t>Unless the CA has good reasons to the contrary, an issued ROA SHOULD <bcp14>SHOULD</bcp14>
      contain a single IP prefix.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>Issuing separate ROAs for independent IP prefixes may increase the
      file fetch
      file-fetch burden on the RP during validation. </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
      <t>This document does not request any has no IANA action.</t> actions.</t>
    </section>
  </middle>
  <back>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8211.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/>
      </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false">
      <name>Acknowledgements</name>

      <t>The authors wish to thank the following people for their review reviews and
      contributions to this document: George Michaelson, Tim Bruijnzeels, Job
      Snijders, Di Ma, Geoff Huston, Tom Harrison, Rob Austein, Stephen Kent,
      Christopher Morrow, Russ Housley, Ching-Heng Ku, Keyur Patel, Cuiling
      Zhang <contact fullname="George Michaelson"/>, <contact fullname="Tim Bruijnzeels"/>, <contact fullname="Job
      Snijders"/>, <contact fullname="Di Ma"/>, <contact fullname="Geoff Huston"/>, <contact fullname="Tom Harrison"/>, <contact fullname="Rob Austein"/>, <contact fullname="Stephen Kent"/>,
      <contact fullname="Christopher Morrow"/>, <contact fullname="Russ Housley"/>, <contact fullname="Ching-Heng Ku"/>, <contact fullname="Keyur Patel"/>, <contact fullname="Cuiling
      Zhang"/>, and Kejun Dong. <contact fullname="Kejun Dong"/>. Thanks are also due to Warren Kumari <contact fullname="Sean Turner"/> for the
      Security Area Directorate review. </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.xml'?>
      <?rfc include='reference.RFC.3779.xml'?>
      <?rfc include='reference.RFC.8174.xml'?>
      <?rfc include='reference.RFC.6482.xml'?>
      <?rfc include='reference.RFC.8211.xml'?>
      <?rfc include='reference.RFC.6480.xml'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.2629.xml'?>
    </references>

  </back>
</rfc>