<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="std" docName="draft-ietf-idr-deprecate-as-set-confed-set-18" number="9774" consensus="true" updates="4271, 5065" obsoletes="6472" ipr="trust200902" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2025-05-21T11:14:56" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set-18" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9774" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Deprecation of AS_SET and AS_CONFED_SET">Deprecation of AS_SET and AS_CONFED_SET in BGP</title>
    <seriesInfo name="RFC" value="9774" stream="IETF"/>
    <author fullname="Warren Kumari" initials="W" surname="Kumari">
      <organization showOnFrontPage="true">Google, Inc.</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 571 748 4373</phone>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <author fullname="Kotikalapudi Sriram" initials="K" surname="Sriram">
      <organization showOnFrontPage="true">USA NIST</organization>
      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>MD</region>
          <code>20899</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 301 975 3973</phone>
        <email>ksriram@nist.gov</email>
      </address>
    </author>
    <author fullname="Lilia Hannachi" initials="L" surname="Hannachi">
      <organization showOnFrontPage="true">USA NIST</organization>
      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>MD</region>
          <code>20899</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 301 975 3259</phone>
        <email>lilia.hannachi@nist.gov</email>
      </address>
    </author>
    <author fullname="Jeffrey Haas" initials="J." surname="Haas">
      <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>1133 Innovation Way</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>
          <country>United States of America</country>
        </postal>
        <email>jhaas@juniper.net</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <area>RTG</area>
    <workgroup>idr</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET
      AS_PATH segment types in the Border Gateway Protocol (BGP). This document
      advances that recommendation to a standards requirement in BGP; it
      prohibits the use of the AS_SET and AS_CONFED_SET path segment types
      in the AS_PATH.  This is done to simplify the design and implementation
      of BGP and to make the semantics of the originator of a BGP route clearer.
      This will also simplify the design, implementation, and deployment of
      various BGP security mechanisms. This document updates RFC 4271 by
      deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and
      updates RFC 5065 by deprecating the origination of BGP
      routes with AS_CONFED_SET (Type 4 AS_PATH segment).
      Finally, it obsoletes RFC 6472.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9774" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-the-requirements">Updates to the Requirements of RFCs 4271 and 5065</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-treatment-of-routes-with-as">Treatment of Routes with AS_SET in RPKI-Based BGP Security</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bgp-as_path-brief-aggregati">BGP AS_PATH "Brief" Aggregation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issues-with-brief-as_path-a">Issues with "Brief" AS_PATH Aggregation and RPKI-ROV</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recommendations-to-mitigate">Recommendations to Mitigate Unpredictable AS_PATH Origins for RPKI-ROV Purposes</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementing-consistent-bri">Implementing Consistent Brief Aggregation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-not-advertising-aggregate-r">Not Advertising Aggregate Routes to Contributing ASes</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mitigating-forwarding-loops">Mitigating Forwarding Loops</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-of-route-filtering-">Example of Route Filtering for Aggregate Routes and Their Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples-of-consistent-and-">Examples of Consistent and Inconsistent BGP Origin AS Generated by Brief Aggregation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scenario-1-first-one-route-">Scenario 1: First one route, then another, each with a fully disjoint AS_PATH</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="B.2" format="counter" sectionFormat="of" target="section-appendix.b.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scenario-2-first-one-route-">Scenario 2: First one route, then another, and the AS_PATHs overlap at the origin AS</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.3">
                <t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent="B.3" format="counter" sectionFormat="of" target="section-appendix.b.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scenario-3-first-one-route-">Scenario 3: First one route, then another, and the AS_PATHs overlap at the neighbor AS</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.4">
                <t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent="B.4" format="counter" sectionFormat="of" target="section-appendix.b.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-achieving-consistent-origin">Achieving Consistent Origin AS During Aggregation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discussion-on-forwarding-lo">Discussion on Forwarding Loops and AS_SETs</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"><xref target="BCP172" format="default" sectionFormat="of" derivedContent="BCP172"/> recommends not
      using AS_SET <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/> and AS_CONFED_SET <xref target="RFC5065" format="default" sectionFormat="of" derivedContent="RFC5065"/> AS_PATH path segment types in the Border
      Gateway Protocol (BGP).  This document advances the BCP recommendation to
      a standards requirement in BGP; it prohibits the use of the AS_SET and
      AS_CONFED_SET types of path segments in the AS_PATH. The purpose is to
      simplify the design and implementation of BGP and to make the semantics
      of the originator of a BGP route clearer. This will also simplify the design,
      implementation, and deployment of various BGP security mechanisms. In
      particular, the prohibition of AS_SETs and AS_CONFED_SETs removes any
      ambiguity about the origin AS in RPKI-based Route Origin
      Validation (RPKI-ROV)
      <xref target="RFC6811" format="default" sectionFormat="of" derivedContent="RFC6811"/> <xref target="RFC6907" format="default" sectionFormat="of" derivedContent="RFC6907"/>
        <xref target="RFC9319" format="default" sectionFormat="of" derivedContent="RFC9319"/>.</t>
      <t indent="0" pn="section-1-2"> The AS_SET path segment in the AS_PATH attribute (Sections <xref target="RFC4271" sectionFormat="bare" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-4.3" derivedContent="RFC4271"/> and <xref target="RFC4271" sectionFormat="bare" section="5.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-5.1.2" derivedContent="RFC4271"/> of <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>) is created by a router that is
      performing route aggregation and contains an unordered set of Autonomous
      Systems (ASes) that contributing prefixes in the aggregate have
      traversed.</t>
      <t indent="0" pn="section-1-3">The AS_CONFED_SET path segment <xref target="RFC5065" format="default" sectionFormat="of" derivedContent="RFC5065"/> in
      the AS_PATH attribute is created by a router that is performing route
      aggregation and contains an unordered set of Member AS Numbers in the
      local confederation that contributing prefixes in the aggregate have
      traversed. It is very similar to an AS_SET but is used within a
      confederation.</t>
      <t indent="0" pn="section-1-4">By performing aggregation, a router is combining multiple BGP routes
      for more specific destinations into a new route for a less specific
      destination (see <xref target="RFC4271" sectionFormat="comma" section="9.1.2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-9.1.2.2" derivedContent="RFC4271"/>). Aggregation
      may blur the semantics of the origin AS for the prefix being announced by
      producing an AS_SET or AS_CONFED_SET.  Such sets can cause operational
      issues, such as not being able to authenticate a route origin for the
      aggregate prefix in new BGP security technologies such as those that take
      advantage of X.509 extensions for IP addresses and AS identifiers
      (see <xref target="RFC6480" format="default" sectionFormat="of" derivedContent="RFC6480"/>, <xref target="RFC6811" format="default" sectionFormat="of" derivedContent="RFC6811"/>, <xref target="RFC6907" format="default" sectionFormat="of" derivedContent="RFC6907"/>, 
      <xref target="RFC8205" format="default" sectionFormat="of" derivedContent="RFC8205"/>, and <xref target="RFC9319" format="default" sectionFormat="of" derivedContent="RFC9319"/>).
      This could result in reachability problems for the destinations
      covered by the aggregated prefix.</t>
      <t indent="0" pn="section-1-5">From analysis of historical Internet routing data, it is apparent that
      aggregation that involves AS_SETs is very seldom used in practice on the
      public Internet (see <xref target="Analysis" format="default" sectionFormat="of" derivedContent="Analysis"/>).  When it is used, it
      is often used incorrectly; only a single AS in the AS_SET is
      the most common case <xref target="Analysis" format="default" sectionFormat="of" derivedContent="Analysis"/>. Also, very often the same AS appears in the
      AS_SEQUENCE and the AS_SET in the BGP update. The occurrence of reserved
      AS numbers <xref target="IANA-SP-ASN" format="default" sectionFormat="of" derivedContent="IANA-SP-ASN"/> is also somewhat frequent.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section anchor="recs" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-updates-to-the-requirements">Updates to the Requirements of RFCs 4271 and 5065</name>
      <t indent="0" pn="section-3-1">Unless explicitly configured by a network operator to do otherwise
         (e.g., during a transition phase), BGP speakers:
      </t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3-2">
        <li pn="section-3-2.1">
          <bcp14>MUST NOT</bcp14> advertise BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs and</li>
        <li pn="section-3-2.2">
          <bcp14>MUST</bcp14> use the "treat-as-withdraw" error handling
              behavior per <xref target="RFC7606" format="default" sectionFormat="of" derivedContent="RFC7606"/> upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH or AS4_PATH <xref target="RFC6793" format="default" sectionFormat="of" derivedContent="RFC6793"/>.</li>
      </ul>
      <t indent="0" pn="section-3-3">Per the above specifications, this document updates <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/> and <xref target="RFC5065" format="default" sectionFormat="of" derivedContent="RFC5065"/>
      by deprecating AS_SET (see <xref target="RFC4271" section="4.3" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-4.3" derivedContent="RFC4271"/>)
      and AS_CONFED_SET (see <xref target="RFC5065" section="3" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5065#section-3" derivedContent="RFC5065"/>), respectively.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-treatment-of-routes-with-as">Treatment of Routes with AS_SET in RPKI-Based BGP Security</name>
      <t indent="0" pn="section-4-1">Resource Public Key Infrastructure (RPKI) <xref target="RFC6480" format="default" sectionFormat="of" derivedContent="RFC6480"/> uses X.509
      extensions for IP addresses and AS identifiers <xref target="RFC3779" format="default" sectionFormat="of" derivedContent="RFC3779"/>.
      RPKI-ROV <xref target="RFC6811" format="default" sectionFormat="of" derivedContent="RFC6811"/> <xref target="RFC6907" format="default" sectionFormat="of" derivedContent="RFC6907"/>
      is a BGP security technology that never allows a route with AS_SET to be considered Valid.
      BGPsec <xref target="RFC8205" format="default" sectionFormat="of" derivedContent="RFC8205"/> and Autonomous System Provider Authorization (ASPA)
      <xref target="I-D.ietf-sidrops-aspa-verification" format="default" sectionFormat="of" derivedContent="ASPA-VERIFICATION"/> are also BGP security technologies
      based on RPKI. BGPsec does not support AS_SETs. In ASPA-based AS_PATH verification,
      a route with AS_SET is always considered Invalid and hence ineligible for route selection.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-bgp-as_path-brief-aggregati">BGP AS_PATH "Brief" Aggregation</name>
      <t indent="0" pn="section-5-1">Sections <xref target="RFC4271" sectionFormat="bare" section="9.1.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-9.1.4" derivedContent="RFC4271"/> and <xref target="RFC4271" sectionFormat="bare" section="9.2.2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-9.2.2.2" derivedContent="RFC4271"/> of <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>
      describe BGP aggregation procedures.  <xref section="F.6" target="RFC4271" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4271#appendix-F.6" derivedContent="RFC4271"/> describes a generally less utilized
      "Complex AS_PATH Aggregation" procedure.</t>
      <t indent="0" pn="section-5-2"><xref target="RFC4271" section="5.1.6" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-5.1.6" derivedContent="RFC4271"/>
        describes the ATOMIC_AGGREGATE Path Attribute and notes that:</t>
      <blockquote pn="section-5-3">
        <t indent="0" pn="section-5-3.1">When a BGP speaker aggregates several routes for the purpose of
          advertisement to a particular peer, the AS_PATH of the aggregated
          route normally includes an AS_SET formed from the set of ASes from
          which the aggregate was formed.  In many cases, the network
          administrator can determine if the aggregate can safely be advertised
          without the AS_SET, and without forming route loops.</t>
        <t indent="0" pn="section-5-3.2">If an aggregate excludes at least some of the AS numbers present in
          the AS_PATH of the routes that are aggregated as a result of dropping
          the AS_SET, the aggregated route, when advertised to the peer, <bcp14>SHOULD</bcp14>
          include the ATOMIC_AGGREGATE attribute.</t>
      </blockquote>
      <t indent="0" pn="section-5-4">When BGP AS_PATH aggregation is done according to the procedures in <xref target="RFC4271" section="9.2.2.2" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-9.2.2.2" derivedContent="RFC4271"/>,
        and any resulting AS_SETs are discarded, it is typically
        referred to as "brief" aggregation in implementations. That terminology is adopted here: In this document, brief aggregation refers to what is described in this section, in contrast to consistent brief aggregation as described in <xref target="consistent-brief" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.
        Brief aggregation results in an AS_PATH that has the following property (from
        <xref target="RFC4271" section="9.2.2.2" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-9.2.2.2" derivedContent="RFC4271"/>):</t>
      <blockquote pn="section-5-5">
        <t indent="0" pn="section-5-5.1">[D]etermine the longest leading sequence of tuples (as defined above)
          common to all the AS_PATH attributes of the routes to be aggregated.
          Make this sequence the leading sequence of the aggregated AS_PATH
          attribute.</t>
      </blockquote>
      <t indent="0" pn="section-5-6">The ATOMIC_AGGREGATE Path Attribute is subsequently attached to the
        BGP route, if AS_SETs are dropped.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-issues-with-brief-as_path-a">Issues with "Brief" AS_PATH Aggregation and RPKI-ROV</name>
        <t indent="0" pn="section-5.1-1">While brief AS_PATH aggregation has the desirable property of not
        containing AS_SETs, the resulting aggregated AS_PATH may contain an
        unpredictable origin AS.
        This is because the aggregating AS may be different from the purported origin AS (for the aggregate), which may vary as explained below.
        Such unpredictable origin ASes may result
        in RPKI-ROV validation issues:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5.1-2">
          <li pn="section-5.1-2.1">Depending on the contributing routes to the aggregate route, the
          resulting origin AS may vary.</li>
          <li pn="section-5.1-2.2">The presence of expected contributing routes may be unpredictable
          due to route availability from BGP neighbors.</li>
          <li pn="section-5.1-2.3">In the presence of such varying origin ASes, it would be necessary
          for the resource holder to register ROAs <xref target="RFC9582" format="default" sectionFormat="of" derivedContent="RFC9582"/> for each potential origin AS that
          may result from the expected aggregated AS_PATHs.</li>
        </ul>
      </section>
      <section anchor="consistent-brief" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-recommendations-to-mitigate">Recommendations to Mitigate Unpredictable AS_PATH Origins for RPKI-ROV Purposes</name>
        <t indent="0" pn="section-5.2-1">To ensure a consistent BGP origin AS is announced for
        aggregate BGP routes for implementations of "brief" BGP aggregation, the
        implementation <bcp14>MUST</bcp14> be configured to truncate the AS_PATH after the
        right-most instance of the desired origin AS for the aggregate.
        The desired origin AS could be the aggregating AS itself.
        A ROA would be necessary for the aggregate prefix with the desired origin AS.</t>
        <t indent="0" pn="section-5.2-2">This form of brief aggregation is referred to as "consistent
        brief" BGP aggregation.</t>
        <t indent="0" pn="section-5.2-3">If the resulting AS_PATH would be truncated from the otherwise
        expected result of BGP AS_PATH aggregation (an AS_SET would not be
        generated and possibly some ASes are removed from the "longest leading sequence" of
        ASes), the ATOMIC_AGGREGATE Path Attribute <bcp14>SHOULD</bcp14> be attached.  This is
        consistent with the intent of <xref target="RFC4271" section="5.1.6" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-5.1.6" derivedContent="RFC4271"/>.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-6-1">This section provides advice to operators regarding deployment and configuration.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-implementing-consistent-bri">Implementing Consistent Brief Aggregation</name>
        <t indent="0" pn="section-6.1-1">When aggregating prefixes, network operators <bcp14>MUST</bcp14> use
        consistent brief aggregation as described in
        <xref target="consistent-brief" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.
        In consistent brief aggregation, the AGGREGATOR and ATOMIC_AGGREGATE
        Path Attributes are included, but the AS_PATH does not have AS_SET or
        AS_CONFED_SET path segment types.
        See <xref target="brief-agg-example" format="default" sectionFormat="of" derivedContent="Appendix B"/> for examples of
        brief aggregation while keeping the origin AS unambiguous
        and generating appropriate ROAs.</t>
      </section>
      <section anchor="filtering-to-contributors" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-not-advertising-aggregate-r">Not Advertising Aggregate Routes to Contributing ASes</name>
        <t indent="0" pn="section-6.2-1">An aggregate prefix
        <bcp14>SHOULD NOT</bcp14> be announced to the contributing ASes. Instead, more specific
        prefixes (from the aggregate) <bcp14>SHOULD</bcp14> be announced to each contributing AS,
        excluding any that were learned from the contributing AS in
        consideration.  See <xref target="filter-example" format="default" sectionFormat="of" derivedContent="Appendix A"/> for an example of
        this filtering policy.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-mitigating-forwarding-loops">Mitigating Forwarding Loops</name>
        <t indent="0" pn="section-6.3-1">When both less specific and more specific destinations are present,
        it's possible to create forwarding loops between networks, as discussed in <xref target="RFC4632" section="5.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4632#section-5.1" derivedContent="RFC4632"/>.</t>
        <t indent="0" pn="section-6.3-2">As a reminder, Rule #2 in <xref target="RFC4632" section="5.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4632#section-5.1" derivedContent="RFC4632"/>
        requires that BGP implementations performing aggregation discard
        packets that match the aggregate route but do not match any of the
        more specific routes.
        </t>
        <t indent="0" pn="section-6.3-3">Further discussion of forwarding loops and their relationship to
        AS_SETs can be found in <xref target="forwarding-loop-discussion" format="default" sectionFormat="of" derivedContent="Appendix C"/>.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This document deprecates the use of aggregation techniques that create
      AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from BGP
      and the removal of the related code from implementations would potentially
      decrease the attack surface for BGP. Deployments of new BGP security
      technologies
      (e.g., <xref target="RFC6480" format="default" sectionFormat="of" derivedContent="RFC6480"/>, <xref target="RFC6811" format="default" sectionFormat="of" derivedContent="RFC6811"/>, and 
      <xref target="RFC8205" format="default" sectionFormat="of" derivedContent="RFC8205"/>) benefit greatly if AS_SETs and AS_CONFED_SETs are not used in BGP.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-sidrops-aspa-verification" to="ASPA-VERIFICATION"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <referencegroup anchor="BCP172" target="https://www.rfc-editor.org/info/bcp172" derivedAnchor="BCP172">
          <reference anchor="RFC6472" target="https://www.rfc-editor.org/info/rfc6472" quoteTitle="true">
            <front>
              <title>Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP</title>
              <author fullname="W. Kumari" initials="W." surname="Kumari"/>
              <author fullname="K. Sriram" initials="K." surname="Sriram"/>
              <date month="December" year="2011"/>
            </front>
            <seriesInfo name="BCP" value="172"/>
            <seriesInfo name="RFC" value="6472"/>
            <seriesInfo name="DOI" value="10.17487/RFC6472"/>
          </reference>
        </referencegroup>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" quoteTitle="true" derivedAnchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t indent="0">The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t indent="0">BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t indent="0">This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC4632" target="https://www.rfc-editor.org/info/rfc4632" quoteTitle="true" derivedAnchor="RFC4632">
          <front>
            <title>Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan</title>
            <author fullname="V. Fuller" initials="V." surname="Fuller"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <date month="August" year="2006"/>
            <abstract>
              <t indent="0">This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="122"/>
          <seriesInfo name="RFC" value="4632"/>
          <seriesInfo name="DOI" value="10.17487/RFC4632"/>
        </reference>
        <reference anchor="RFC5065" target="https://www.rfc-editor.org/info/rfc5065" quoteTitle="true" derivedAnchor="RFC5065">
          <front>
            <title>Autonomous System Confederations for BGP</title>
            <author fullname="P. Traina" initials="P." surname="Traina"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <author fullname="J. Scudder" initials="J." surname="Scudder"/>
            <date month="August" year="2007"/>
            <abstract>
              <t indent="0">The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.</t>
              <t indent="0">This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.</t>
              <t indent="0">This document obsoletes RFC 3065. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5065"/>
          <seriesInfo name="DOI" value="10.17487/RFC5065"/>
        </reference>
        <reference anchor="RFC6793" target="https://www.rfc-editor.org/info/rfc6793" quoteTitle="true" derivedAnchor="RFC6793">
          <front>
            <title>BGP Support for Four-Octet Autonomous System (AS) Number Space</title>
            <author fullname="Q. Vohra" initials="Q." surname="Vohra"/>
            <author fullname="E. Chen" initials="E." surname="Chen"/>
            <date month="December" year="2012"/>
            <abstract>
              <t indent="0">The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6793"/>
          <seriesInfo name="DOI" value="10.17487/RFC6793"/>
        </reference>
        <reference anchor="RFC7606" target="https://www.rfc-editor.org/info/rfc7606" quoteTitle="true" derivedAnchor="RFC7606">
          <front>
            <title>Revised Error Handling for BGP UPDATE Messages</title>
            <author fullname="E. Chen" initials="E." role="editor" surname="Chen"/>
            <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"/>
            <author fullname="P. Mohapatra" initials="P." surname="Mohapatra"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <date month="August" year="2015"/>
            <abstract>
              <t indent="0">According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.</t>
              <t indent="0">This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7606"/>
          <seriesInfo name="DOI" value="10.17487/RFC7606"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Analysis" target="https://github.com/ksriram25/IETF/blob/main/Detailed-AS_SET-analysis.txt" quoteTitle="true" derivedAnchor="Analysis">
          <front>
            <title>Detailed analysis of AS_SETs in BGP updates</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
            <date month="March" year="2022"/>
          </front>
          <refcontent>commit ef3f4a9</refcontent>
        </reference>
        <reference anchor="I-D.ietf-sidrops-aspa-verification" target="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-22" quoteTitle="true" derivedAnchor="ASPA-VERIFICATION">
          <front>
            <title>BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects</title>
            <author fullname="Alexander Azimov" initials="A." surname="Azimov">
              <organization showOnFrontPage="true">Yandex</organization>
            </author>
            <author fullname="Eugene Bogomazov" initials="E." surname="Bogomazov">
              <organization showOnFrontPage="true">Qrator Labs</organization>
            </author>
            <author fullname="Randy Bush" initials="R." surname="Bush">
              <organization showOnFrontPage="true">Internet Initiative Japan &amp; Arrcus, Inc.</organization>
            </author>
            <author fullname="Keyur Patel" initials="K." surname="Patel">
              <organization showOnFrontPage="true">Arrcus</organization>
            </author>
            <author fullname="Job Snijders" initials="J." surname="Snijders"/>
            <author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">
              <organization showOnFrontPage="true">USA National Institute of Standards and Technology</organization>
            </author>
            <date day="23" month="March" year="2025"/>
            <abstract>
              <t indent="0">This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-aspa-verification-22"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="IANA-SP-ASN" target="https://www.iana.org/assignments/iana-as-numbers-special-registry" quoteTitle="true" derivedAnchor="IANA-SP-ASN">
          <front>
            <title>Special-Purpose Autonomous System (AS) Numbers</title>
            <author initials="" surname="">
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date month="" year=""/>
          </front>
        </reference>
        <reference anchor="RFC3779" target="https://www.rfc-editor.org/info/rfc3779" quoteTitle="true" derivedAnchor="RFC3779">
          <front>
            <title>X.509 Extensions for IP Addresses and AS Identifiers</title>
            <author fullname="C. Lynn" initials="C." surname="Lynn"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <author fullname="K. Seo" initials="K." surname="Seo"/>
            <date month="June" year="2004"/>
            <abstract>
              <t indent="0">This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3779"/>
          <seriesInfo name="DOI" value="10.17487/RFC3779"/>
        </reference>
        <reference anchor="RFC6480" target="https://www.rfc-editor.org/info/rfc6480" quoteTitle="true" derivedAnchor="RFC6480">
          <front>
            <title>An Infrastructure to Support Secure Internet Routing</title>
            <author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6480"/>
          <seriesInfo name="DOI" value="10.17487/RFC6480"/>
        </reference>
        <reference anchor="RFC6811" target="https://www.rfc-editor.org/info/rfc6811" quoteTitle="true" derivedAnchor="RFC6811">
          <front>
            <title>BGP Prefix Origin Validation</title>
            <author fullname="P. Mohapatra" initials="P." surname="Mohapatra"/>
            <author fullname="J. Scudder" initials="J." surname="Scudder"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="R. Bush" initials="R." surname="Bush"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <date month="January" year="2013"/>
            <abstract>
              <t indent="0">To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6811"/>
          <seriesInfo name="DOI" value="10.17487/RFC6811"/>
        </reference>
        <reference anchor="RFC6907" target="https://www.rfc-editor.org/info/rfc6907" quoteTitle="true" derivedAnchor="RFC6907">
          <front>
            <title>Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties</title>
            <author fullname="T. Manderson" initials="T." surname="Manderson"/>
            <author fullname="K. Sriram" initials="K." surname="Sriram"/>
            <author fullname="R. White" initials="R." surname="White"/>
            <date month="March" year="2013"/>
            <abstract>
              <t indent="0">This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6907"/>
          <seriesInfo name="DOI" value="10.17487/RFC6907"/>
        </reference>
        <reference anchor="RFC8205" target="https://www.rfc-editor.org/info/rfc8205" quoteTitle="true" derivedAnchor="RFC8205">
          <front>
            <title>BGPsec Protocol Specification</title>
            <author fullname="M. Lepinski" initials="M." role="editor" surname="Lepinski"/>
            <author fullname="K. Sriram" initials="K." role="editor" surname="Sriram"/>
            <date month="September" year="2017"/>
            <abstract>
              <t indent="0">This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8205"/>
          <seriesInfo name="DOI" value="10.17487/RFC8205"/>
        </reference>
        <reference anchor="RFC9319" target="https://www.rfc-editor.org/info/rfc9319" quoteTitle="true" derivedAnchor="RFC9319">
          <front>
            <title>The Use of maxLength in the Resource Public Key Infrastructure (RPKI)</title>
            <author fullname="Y. Gilad" initials="Y." surname="Gilad"/>
            <author fullname="S. Goldberg" initials="S." surname="Goldberg"/>
            <author fullname="K. Sriram" initials="K." surname="Sriram"/>
            <author fullname="J. Snijders" initials="J." surname="Snijders"/>
            <author fullname="B. Maddison" initials="B." surname="Maddison"/>
            <date month="October" year="2022"/>
            <abstract>
              <t indent="0">This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="185"/>
          <seriesInfo name="RFC" value="9319"/>
          <seriesInfo name="DOI" value="10.17487/RFC9319"/>
        </reference>
        <reference anchor="RFC9582" target="https://www.rfc-editor.org/info/rfc9582" quoteTitle="true" derivedAnchor="RFC9582">
          <front>
            <title>A Profile for Route Origin Authorizations (ROAs)</title>
            <author fullname="J. Snijders" initials="J." surname="Snijders"/>
            <author fullname="B. Maddison" initials="B." surname="Maddison"/>
            <author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
            <author fullname="D. Kong" initials="D." surname="Kong"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="May" year="2024"/>
            <abstract>
              <t indent="0">This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9582"/>
          <seriesInfo name="DOI" value="10.17487/RFC9582"/>
        </reference>
      </references>
    </references>
    <section anchor="filter-example" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-example-of-route-filtering-">Example of Route Filtering for Aggregate Routes and Their Contributors</name>
      <t indent="0" pn="section-appendix.a-1">	
       The illustration presented below shows how an AS_SET is not used when
       aggregating and how data plane route loops are avoided.
       Consider that p1/24 (from AS 64501), p2/24 (from AS 64502), p3/24 (from AS 64503),
       and p4/24 (from AS 64504) are aggregated by AS 64505 to p/22.
       AS_SET is not used with the aggregate p/22 but AGGREGATOR and ATOMIC AGGREGATE are used.
       Data plane route loops are avoided by not announcing the aggregate p/22
       to the contributing ASes, i.e., AS 64501, AS 64502, AS 64503, and AS 64504.
       Instead, as further illustrated, p1/24, p2/24, and p4/24 are announced to AS 64503.
       The routing tables (post aggregation) of each of the ASes are depicted in the diagram below.
      </t>
      <artwork type="ascii-art" align="center" name="" alt="" pn="section-appendix.a-2">
 (       )     (       )           (       )     (       )
( AS64501 )   ( AS64502 )         ( AS64503 )   ( AS64504 )
 (       )     (       )           (       )     (       )
   p1/24         p2/24               p3/24         p4/24
     |             |                   |             |
     |             +--&gt;  (       )  &lt;--+             |
     |                  ( AS64505 )                  |
     +----------------&gt;  (       )  &lt;----------------+
                            p/22
                             |
                             V

AS 64501                      AS 64502
==========================    ==========================
p1/24 AS_PATH ""              p1/24 AS_PATH "64505 64501"
p2/24 AS_PATH "64505 64502"   p2/24 AS_PATH ""
p3/24 AS_PATH "64505 64503"   p3/24 AS_PATH "64505 64503"
p4/24 AS_PATH "64505 64504"   p4/24 AS_PATH "64505 64504"


AS 64503                      AS 64504
==========================    ==========================
p1/24 AS_PATH "64505 64501"   p1/24 AS_PATH "64505 64501"
p2/24 AS_PATH "64505 64502"   p2/24 AS_PATH "64505 64502"
p3/24 AS_PATH ""              p3/24 AS_PATH "64505 64503"
p4/24 AS_PATH "64505 64504"   p4/24 AS_PATH ""

AS 64505
==========================
p/22  AS_PATH "" AGGREGATOR 64505 ATOMIC_AGGREGATE
p1/24 AS_PATH "64501"
p2/24 AS_PATH "64502"
p3/24 AS_PATH "64503"
p4/24 AS_PATH "64504"</artwork>
    </section>
    <section anchor="brief-agg-example" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-examples-of-consistent-and-">Examples of Consistent and Inconsistent BGP Origin AS Generated by Brief Aggregation</name>
      <t indent="0" pn="section-appendix.b-1">
      The examples below illustrate how brief aggregation
      may result in an inconsistent origin AS.
      </t>
      <t indent="0" pn="section-appendix.b-2">AS 64500 aggregates more specific routes into 192.0.2.0/24.</t>
      <t indent="0" pn="section-appendix.b-3">Consider the following scenarios where brief aggregation is done
      by AS 64500 and what the resultant origin ASes would be.</t>
      <artwork type="ascii-art" align="left" name="" alt="" pn="section-appendix.b-4">
Routes:
R1 - 192.0.2.0/26   AS_PATH "64501"
R2 - 192.0.2.64/26  AS_PATH "64502"
R3 - 192.0.2.128/26 AS_PATH "64504 64502"
R4 - 192.0.2.192/26 AS_PATH "64504 64501"

           (       )                        (       )
          ( AS64501 )                      ( AS64502 )
           (       )                        (       )
192.0.2.0/26    192.0.2.192/26    192.0.2.128/26  192.0.2.64/26
     |                      |      |                 |
     |                      |      |                 |
     |                      \/    \/                 |
     |                     (        )                |
     |                    (  AS64504 )               |
     |                     (        )                |
     |                      |      |                 |
     |                   R4 |      | R3              |
     |                      |      |                 |
     |                      \/    \/                 |
     |             R1      (         )      R2       |
     +-------------------&gt;(  AS64500  )&lt;-------------+
                           (         )
                                |
                                | (announcing
                                |  aggregate 192.0.2.0/24)
                               \/</artwork>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b.1">
        <name slugifiedName="name-scenario-1-first-one-route-">Scenario 1: First one route, then another, each with a fully disjoint AS_PATH</name>
        <t indent="0" pn="section-appendix.b.1-1">Receive R1. Aggregate 192.0.2.0/24 AS_PATH "64501"</t>
        <t indent="0" pn="section-appendix.b.1-2">Alternate "bug?": Aggregate 192.0.2.0/24 AS_PATH "[ 64501 ]"</t>
        <t indent="0" pn="section-appendix.b.1-3">(Note: AS numbers within square brackets represent an AS_SET.)</t>
        <t indent="0" pn="section-appendix.b.1-4">Receive R2.  Aggregate 192.0.2.0/24 AS_PATH "[ 64501 64502 ]"</t>
        <t indent="0" pn="section-appendix.b.1-5">If brief aggregation is in use, the AS_PATH would be truncated to
        the empty AS_PATH, "".</t>
        <t indent="0" pn="section-appendix.b.1-6">The resulting AS_PATH is thus not stable and depends on the presence
        of specific routes.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b.2">
        <name slugifiedName="name-scenario-2-first-one-route-">Scenario 2: First one route, then another, and the AS_PATHs overlap at the origin AS</name>
        <t indent="0" pn="section-appendix.b.2-1">Receive R1.  Aggregate 192.0.2.0/24 AS_PATH "64501"</t>
        <t indent="0" pn="section-appendix.b.2-2">Receive R4.  Aggregate 192.0.2.0/24 AS_PATH "[ 64504 64501 ]"</t>
        <t indent="0" pn="section-appendix.b.2-3">If brief aggregation is in use,  the AS_PATH is truncated to "".</t>
        <t indent="0" pn="section-appendix.b.2-4">The resulting AS_PATH is thus not stable and depends on the presence
        of specific routes.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b.3">
        <name slugifiedName="name-scenario-3-first-one-route-">Scenario 3: First one route, then another, and the AS_PATHs overlap at the neighbor AS</name>
        <t indent="0" pn="section-appendix.b.3-1">Receive R3.  Aggregate 192.0.2.0/24 AS_PATH "64504 64501"</t>
        <t indent="0" pn="section-appendix.b.3-2">Receive R4.  Aggregate 192.0.2.0/24 AS_PATH "64504 [ 64501 64502 ]"</t>
        <t indent="0" pn="section-appendix.b.3-3">If brief aggregation is in use, the AS_PATH is truncated to "64504".</t>
        <t indent="0" pn="section-appendix.b.3-4">The resulting AS_PATH is thus not stable and depends on the presence
        of specific routes.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b.4">
        <name slugifiedName="name-achieving-consistent-origin">Achieving Consistent Origin AS During Aggregation</name>
        <t indent="0" pn="section-appendix.b.4-1">In the three scenarios above, the aggregating AS 64500 is using
        brief aggregation.  This results in inconsistent
        origin ASes as the contributing routes are learned.  This motivates the
        "consistent brief" BGP aggregation mentioned in
        <xref target="consistent-brief" format="default" sectionFormat="of" derivedContent="Section 5.2"/> and discussed further
        with examples below.</t>
        <t indent="0" pn="section-appendix.b.4-2">The trivial solution to addressing the issue is to simply discard
        all of the ASes for the contributing routes. In simple BGP aggregation
        topologies, this is likely the correct thing to do.  The AS originating
        the aggregate, 192.0.2.0/24 in this example, is likely the resource
        holder for the route in question.  In such a case, simply originating
        the route to its BGP upstream neighbors in the Internet with its own
        AS, 64500, means that a consistent ROA
        could be registered in the RPKI for this prefix.  This satisfies the
        need for a consistent (unambiguous) origin AS.</t>
        <t indent="0" pn="section-appendix.b.4-3">If the contributing ASes are themselves multihomed to the Internet
        outside of their connections to AS 64500, then additional ROAs would
        need to be created for each of the more specific prefixes.</t>
        <t indent="0" pn="section-appendix.b.4-4">In more complex proxy aggregation scenarios, there may be a desire
        to permit some stable (i.e., common) portion of the contributing AS_PATHs to be kept in the
        aggregate route.  Consider the case for Scenario 3, where the neighbor
        AS is the same for both R3 and R4 -- AS 64504.  In such a case, an
        implementation may permit the aggregate's brief AS_PATH to be "64504", and
        a ROA would be created for the aggregate prefix with 64504 as the origin AS.
</t>
      </section>
    </section>
    <section anchor="forwarding-loop-discussion" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-discussion-on-forwarding-lo">Discussion on Forwarding Loops and AS_SETs</name>
      <t indent="0" pn="section-appendix.c-1">Although BGP-4 was designed to carry Classless Inter-Domain Routing (CIDR) routes,
      <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/> does not discuss the installation of "discard"
      or "null" routes when implementing its aggregation procedures.  Implementations
      could originate an aggregate prefix without a covering route
      for a more specific prefix (subsumed by the aggregate prefix) present in the local
      routing table.</t>
      <t indent="0" pn="section-appendix.c-2">When aggregating more specific routes according to
      the aggregation procedures of <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>, the aggregating BGP
      speaker will place contributing routes into the generated AS_PATH, perhaps
      using AS_SETs.  As a result, a contributing AS will not install the
      aggregated route into its RIB since the route is an AS_PATH loop.  This
      provides a form of protection against forwarding loops created by BGP
      aggregation.</t>
      <t indent="0" pn="section-appendix.c-3">When brief aggregation methods are used, a BGP speaker may receive a
      route containing a less specific destination covering a local more specific
      destination and install it in its routing table since it is not
      prevented from doing so by BGP AS_PATH loop detection. This gives rise to
      the possibility of forwarding loops. To help prevent forwarding loops,
      it is critical to adhere to the following:</t>
      <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-appendix.c-4">
          <li pn="section-appendix.c-4.1" derivedCounter="1.">Rule #2 in <xref target="RFC4632" section="5.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4632#section-5.1" derivedContent="RFC4632"/>: </li>
      </ol>
      <blockquote pn="section-appendix.c-5">
          A router that generates an aggregate route for multiple,
          more-specific routes must discard packets that match the
          aggregate route, but not any of the more-specific routes.  In other
          words, the "next hop" for the aggregate route should be the null
        destination.</blockquote>
      <ol start="2" indent="adaptive" spacing="normal" type="1" pn="section-appendix.c-6">
        <li pn="section-appendix.c-6.1" derivedCounter="2.">Not advertising aggregate routes to contributing ASes
          as specified in <xref target="filtering-to-contributors" format="default" sectionFormat="of" derivedContent="Section 6.2"/>
          of this document (also see <xref target="filter-example" format="default" sectionFormat="of" derivedContent="Appendix A"/>).</li>
      </ol>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.d">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.d-1">The authors would like to thank <contact fullname="Alvaro Retana"/>,
      <contact fullname="John Scudder"/>, <contact fullname="Ketan       Talaulikar"/>, <contact fullname="Keyur Patel"/>, <contact fullname="Susan Hares"/>, <contact fullname="Claudio Jeker"/>, <contact fullname="Nick Hilliard"/>, <contact fullname="Robert Raszuk"/>,
      <contact fullname="John Heasley"/>, <contact fullname="Job Snijders"/>,
      <contact fullname="Jared Mauch"/>, <contact fullname="Jakob Heitz"/>,
      <contact fullname="Tony Przygienda"/>, <contact fullname="Douglas       Montgomery"/>, <contact fullname="Randy Bush"/>, <contact fullname="Curtis Villamizar"/>, <contact fullname="Danny McPherson"/>,
      <contact fullname="Chris Morrow"/>, <contact fullname="Tom Petch"/>,
      <contact fullname="Ilya Varlashkin"/>, <contact fullname="Enke Chen"/>,
      <contact fullname="Tony Li"/>, <contact fullname="Florian Weimer"/>,
      <contact fullname="John Leslie"/>, <contact fullname="Paul Jakma"/>,
      <contact fullname="Rob Austein"/>, <contact fullname="Russ Housley"/>,
      <contact fullname="Sandra Murphy"/>, <contact fullname="Steven M.       Bellovin"/>, <contact fullname="Steve Kent"/>, <contact fullname="Steve       Padgett"/>, and <contact fullname="Alfred Hoenes"/> for comments and
      suggestions. The comments and suggestions received from the IESG
      reviewers are also much appreciated.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Warren Kumari" initials="W" surname="Kumari">
        <organization showOnFrontPage="true">Google, Inc.</organization>
        <address>
          <postal>
            <street>1600 Amphitheatre Parkway</street>
            <city>Mountain View</city>
            <region>CA</region>
            <code>94043</code>
            <country>United States of America</country>
          </postal>
          <phone>+1 571 748 4373</phone>
          <email>warren@kumari.net</email>
        </address>
      </author>
      <author fullname="Kotikalapudi Sriram" initials="K" surname="Sriram">
        <organization showOnFrontPage="true">USA NIST</organization>
        <address>
          <postal>
            <street>100 Bureau Drive</street>
            <city>Gaithersburg</city>
            <region>MD</region>
            <code>20899</code>
            <country>United States of America</country>
          </postal>
          <phone>+1 301 975 3973</phone>
          <email>ksriram@nist.gov</email>
        </address>
      </author>
      <author fullname="Lilia Hannachi" initials="L" surname="Hannachi">
        <organization showOnFrontPage="true">USA NIST</organization>
        <address>
          <postal>
            <street>100 Bureau Drive</street>
            <city>Gaithersburg</city>
            <region>MD</region>
            <code>20899</code>
            <country>United States of America</country>
          </postal>
          <phone>+1 301 975 3259</phone>
          <email>lilia.hannachi@nist.gov</email>
        </address>
      </author>
      <author fullname="Jeffrey Haas" initials="J." surname="Haas">
        <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
        <address>
          <postal>
            <street>1133 Innovation Way</street>
            <city>Sunnyvale</city>
            <region>CA</region>
            <code>94089</code>
            <country>United States of America</country>
          </postal>
          <email>jhaas@juniper.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
