draft-ietf-sidrops-aspa-verification.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std"
     docName="draft-ietf-sidrops-aspa-verification-19"
     submissionType="IETF"
     consensus="true"
     ipr="trust200902">

  <front>

    <title abbrev="ASPA-based AS_PATH Verification">
      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>
      <address>
        <postal>
          <street>Ulitsa Lva Tolstogo 16</street>
          <city>Moscow</city>
          <code>119021</code>
          <country>Russian Federation</country>
        </postal>
        <email>a.e.azimov@gmail.com</email>
      </address>
    </author>
    <author fullname="Eugene Bogomazov" initials="E." surname="Bogomazov">
      <organization showOnFrontPage="true">Qrator Labs</organization>
      <address>
        <postal>
          <street>1-y Magistralnyy tupik 5A</street>
          <city>Moscow</city>
          <code>123290</code>
          <country>Russian Federation</country>
        </postal>
        <email>eb@qrator.net</email>
      </address>
    </author>
    <author fullname="Randy Bush" initials="R." surname="Bush">
      <organization abbrev="IIJ &amp; Arrcus" showOnFrontPage="true">Internet Initiative Japan &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="Keyur Patel" initials="K." surname="Patel">
      <organization showOnFrontPage="true">Arrcus</organization>
      <address>
        <postal>
          <street>2077 Gateway Place</street>
          <street>Suite #400</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95119</code>
          <country>United States of America</country>
        </postal>
        <email>keyur@arrcus.com</email>
      </address>
    </author>
    <author fullname="Job Snijders" initials="J." surname="Snijders">
      <organization showOnFrontPage="true">Fastly</organization>
      <address>
        <postal>
          <street/>
          <code/>
          <city>Amsterdam</city>
          <country>Netherlands</country>
        </postal>
        <email>job@fastly.com</email>
      </address>
    </author>
    <author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">
      <organization abbrev="USA NIST" showOnFrontPage="true">USA National Institute of Standards and Technology</organization>
      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>MD</region>
          <code>20899</code>
          <country>United States of America</country>
        </postal>
        <email>ksriram@nist.gov</email>
      </address>
    </author>

    <date />

    <keyword>BGP</keyword>
    <keyword>Route leak</keyword>
    <keyword>Hijacks</keyword>

    <abstract>
      <t>
        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>

  <middle>

    <section title="Introduction" anchor="intro">
      <t>
        The Border Gateway Protocol (BGP) as originally designed is known to be vulnerable to prefix (or route) hijacks and BGP route leaks <xref target="RFC7908"/>.
        Some existing BGP extensions can partially solve these problems.
        For example, Resource Public Key Infrastructure (RPKI) based route origin validation (RPKI-ROV) <xref target="RFC6480"/> <xref target="RFC6482"/> <xref target="RFC6811"/> <xref target="RFC9319"/> can be used to detect and filter accidental mis-originations.
        <xref target="RFC9234"/> or <xref target="I-D.ietf-grow-route-leak-detection-mitigation"/> can be used to detect and mitigate accidental route leaks.
        While RPKI-ROV can prevent accidental prefix hijacks, malicious forged-origin prefix hijacks can still occur <xref target="RFC9319"/>.
        RFC9319 includes some recommendations for reducing the attack surface for forged-origin prefix hijacks.
      </t>
      <t>
        This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects <xref target="I-D.ietf-sidrops-aspa-profile"/> in the RPKI to verify properties of the BGP AS_PATH attribute of advertised routes.
        ASPA-based AS_PATH verification provides detection and mitigation of route leaks.
        It also provides protection, to some degree, against prefix hijacks with forged-origin or forged-path-segment (<xref target="property"/>).
        These new ASPA-based procedures automatically detect such anomalous AS_PATHs in BGP Updates that are advertised between ASes.
      </t>
      <t>
        Both route leaks and hijacks have similar effects on ISP operations.
        They redirect traffic and can result in denial of service (DoS), eavesdropping, increased latency, and packet loss.
        The level of risk, however, depends significantly on the extent of propagation of the anomalies.
        For example, a route leak or hijack that is propagated only to customers may cause bottlenecking within an ISP's customer cone, but if the anomaly propagates through lateral (i.e., non-transit) peers or transit providers, then the ill effects will likely be amplified and may be experienced worldwide.
      </t>
      <t>
        The ability to constrain the propagation of BGP anomalies to transit providers and lateral peers -- without requiring support from the source of the anomaly (which is critical if the source has malicious intent) -- should significantly improve the robustness of the global inter-domain routing system.
      </t>
    </section>

    <section title="Requirements Language" anchor="req">
        <t>
    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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>

    <section title="Terminology and List of Acronyms" anchor="terminology">
      <t>
       The following terms are used with special meanings.
      </t>
      <t>
        <list style="hanging">
          <t hangText="Route is ineligible:">
            The term has the same meaning as in <xref target="RFC4271"/>, i.e., "route is ineligible to be installed in Loc-RIB and will be excluded from the next phase of route selection."
          </t>
          <t hangText="CAS:">
            Customer AS (<xref target="I-D.ietf-sidrops-aspa-profile" sectionFormat="comma" section="1"/>).
          </t>
          <t hangText="PAS:">
            Provider AS (<xref target="I-D.ietf-sidrops-aspa-profile" sectionFormat="comma" section="1"/>).
          </t>
          <t hangText="SPAS:">
            Set of Provider ASes (<xref target="I-D.ietf-sidrops-aspa-profile" sectionFormat="comma" section="3"/>).
          </t>
        </list>
      </t>
      <t>
        For path verification purposes in this document, the peering relationships an AS can have in relation to a neighbor AS are Customer, Provider, Peer, Route Server (RS), RS-client, and Complex.
        These peering relationships are defined in <xref target="RFC9234"/>.
        All peering relationships are defined locally.
      </t>
    </section>

    <section title="ASPA Registration Recommendations" anchor="rec1">
      <t>
        A compliant AS or Route Server AS (RS AS) MUST have an ASPA.
        An AS MUST list in its SPAS the union of all its Provider AS(es) and non-transparent RS AS(es) at which it is an RS-client.
        An AS MUST include a Provider AS in its SPAS regardless of whether it provides connectivity for only IPv4 or only IPv6 or both.
      </t>
      <t>
        In the Complex relationship case, an AS MUST include the neighbor AS in its SPAS if neighbor plays Provider role for a subset of received or sent prefixes.
        If two ASes are exporting both customer and non-customer routes to each other, they MUST register its ASPA including the other AS in its SPAS.
      </t>
      <t>
        The ASes on the boundary of an AS Confederation MUST register ASPAs using the Confederation's global AS number (ASN) as the CAS.
      </t>
      <t>
        An ASPA object showing only AS 0 as a provider AS is referred to as an AS0 ASPA.
        A non-transparent Route Server AS (RS AS) is one that includes its AS number in the AS_PATH.
        Registering as AS0 ASPA is a statement by the registering AS that it has no transit providers, and it is also not an RS-client at a non-transparent RS AS.
        If that statement is true, then the AS MUST register an AS0 ASPA.
      </t>
      <t>
        Normally, a SPAS (see <xref target="terminology"/>) is not expected to contain both an AS 0 and other Provider ASes, but an unexpected presence of AS 0 has no influence on the AS path verification procedures (see <xref target="pair-validation"/>, <xref target="verif"/>).
      </t>
      <t>
        A compliant AS SHOULD register a single ASPA object.
        A single ASPA record for an AS ought to prevent race conditions during ASPA updates that might affect prefix propagation.
        The CA software that provides hosting for ASPA records SHOULD support enforcement of this practice.
      </t>
      <t>
        An AS may have providers that may be used on certain occasions, for an example in case of a DDoS attack.
        It is RECOMMENDED to add such providers in ASPA in advance, so there will be no race conditions between ASPA distribution and route propagation.
      </t>
      <t>
        During a transition process between different certificate authority (CA) registries, the ASPA records SHOULD be kept identical in all relevant registries.
      </t>
    </section>

    <section title="Provider Authorization Function" anchor="pair-validation">
      <t>
        A CAS is expected to register a single ASPA listing all its Provider ASes (see <xref target="rec1"/>).
        If a CAS has a single cryptographically valid ASPA, then the Union SPAS (U-SPAS) for the CAS equals to SPAS.
        In case a CAS has multiple cryptographically valid ASPAs, then the U-SPAS for the CAS is the union of AS listed in all SPAS of these ASPAs.
      </t>

      <t>
        Let AS x and AS y represent two unique ASes.
        A provider authorization function, authorized(AS x, AS y), checks if the ordered pair of ASNs, (AS x, AS y), has the property that AS y is an attested provider of AS x per U-SPAS of AS x.
        By term "Provider+" the function signals if AS y plays the role of Provider, or non-transparent RS.
        This function is specified as follows:
      </t>
      <t>
        <figure anchor="fig1" align="left" suppress-title="true" pn="figure-1">
          <name slugifiedName="HFC-illustration">Provider authorization function.</name>
          <artwork align="left" name="" type="" alt="">
<![CDATA[

                           /
                           | "No Attestation" if there is no entry
                           |   in U-SPAS table for CAS = AS x
                           |
authorized(AS x, AS y) =  / Else, "Provider+" if the U-SPAS entry
                           \   for CAS = AS x includes AS y
                           |
                           | Else, "Not Provider+"
                           \
]]>
</artwork>
        </figure>
       </t>
      <t>
        The "No Attestation" result is returned only when no ASPA is retrieved for the CAS or none of its ASPAs are cryptographically valid.
        The provider authorization function is used in the ASPA-based AS_PATH verification algorithms described in <xref target="Upflow"/> and <xref target="Downflow"/>.
      </t>

    </section>

    <section title="AS_PATH Verification" anchor="verif">
      <t>
        The procedures described in this document are applicable only to four-octet AS number compatible BGP speakers <xref target="RFC6793"/>.
        If such a BGP speaker receives both AS_PATH and AS4_PATH attributes in an UPDATE, then the procedures are applied on the reconstructed AS path (Section 4.2.3 of <xref target="RFC6793"/>).
        So, the term AS_PATH is used in this document to refer to the usual AS_PATH <xref target="RFC4271"/> as well as the reconstructed AS path.
      </t>
<!--      rephrase-->
      <t>
        The <xref target="RFC4271"/> defines
      </t>
      <t>
        If an attacker creates a route leak intentionally, they may try to strip their AS from the AS_PATH.
        To partly guard against that, a check is necessary to match the most recently added AS in the AS_PATH to the BGP neighbor's ASN.
        This check MUST be performed as specified in Section 6.3 of <xref target="RFC4271"/>.
        If the check fails, then the AS_PATH is considered a Malformed AS_PATH and the UPDATE is considered to be in error (Section 6.3 of <xref target="RFC4271"/>).
        The case of transparent RS MUST also be appropriately taken care of (e.g., by suspending the neighbor ASN check).
        If the AS_PATH is empty (zero length), then also the UPDATE is considered to be an error.
      </t>
      <t>
        <xref target="I-D.ietf-idr-deprecate-as-set-confed-set"/> specifies that "treat-as-withdraw" error handling <xref target="RFC7606"/> SHOULD be applied to routes with AS_SET in the AS_PATH.
        In the current document, routes with AS_SET are given Invalid evaluation in the AS_PATH verification procedures (<xref target="Upflow"/> and <xref target="Downflow"/>).
        See <xref target="mitigation"/> for how routes with Invalid AS_PATH are handled.
      </t>

	  <section title="Principles" anchor="principles">
        <t>
          Let the sequence {AS(N), AS(N-1),..., AS(2), AS(1)} represent the AS_PATH in terms of unique ASNs, where AS(1) is the origin AS and AS(N) is the most recently added AS and neighbor of the receiving/verifying AS.
          N is the length of the received AS_PATH in unique ASes.
          Let AS(N+1) represent the receiving/verifying AS.
        </t>
        <t>
          <figure anchor="fig2" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="ramp-illustration">Illustration of up-ramp and down-ramp. </name>
            <artwork align="left" name="" type="" alt="">
      <![CDATA[

                      AS(L) ............. AS(K)
                       /                     \
                   AS(L+1)                  AS(K-1)
                      .                       .
                     .                         .
      (down-ramp)   .                           .  (up-ramp)
                   .                             .
                  .                               .
                AS(N-1)                          AS(2)
                  /                                \
               AS(N)                               AS(1)
                /                                (Origin AS)
      Receiving & verifying AS (AS(N+1))
             (Customer)

          Each ramp has consecutive customer-to-provider hops in the bottom-to-top direction
      ]]>
      </artwork>
          </figure>
        </t>
        <t>
          The AS_PATH may in general have both an up-ramp (on the right starting at AS(1)) and a down-ramp (on the left starting at AS(N)).
          The up-ramp starts at AS(1) and each hop AS(i) to AS(i+1) represents Customer and Provider peering relationship.
          The down-ramp runs backward from AS(N) to AS(L).
          In the down-ramp, each pair AS(j) to AS(j-1) represents Customer and Provider peering relationship.
          If there are no hops or just one hop between the apexes of the up-ramp and the down-ramp, then the AS_PATH is valid (valley free).
        </t>
        <t>
          If the sum of lengths of up-ramp and down-ramp is less than N, it is invalid: the prefix was leaked or AS_PATH was malformed.
        </t>
        <t>
          ASPA can be used to check if AS y is an attested provider of AS x, and thus the provider authorization function can be used to measure the bounds on up-ramp and down-ramp lengths.
          The "Not Provider+" outcome of the provider authorization function can be used to calculate the upper boundary of ramp length and the 'No Attestation' outcome can be used to calculate its lower boundary.
          Below are the formal definitions.
        </t>

        <t>
          Determine the maximum up-ramp length as I, where I is the minimum index for which authorized(A(I), A(I+1)) returns "Not Provider+".
          If there is no such I, the maximum up-ramp length is set equal to the AS_PATH length N.
          This parameter is abbreviated as max_up_ramp.
          The minimum up-ramp length can be determined as I, where I is the minimum index for which authorized(A(I), A(I+1)) returns "No Attestation" or "Not Provider+".
          If there is no such I, the AS_PATH consists of only "Provider+" pairs; so the minimum up-ramp length is set equal to the AS_PATH length N.
          This parameter is abbreviated as min_up_ramp.
        </t>
        <t>
          Similarly, the maximum down-ramp length can be determined as N - J + 1 where J is the maximum index for which authorized(A(J), A(J-1)) returns "Not Provider+".
          If there is no such J, the maximum down-ramp length is set equal to the AS_PATH length N.
          This parameter is abbreviated as max_down_ramp.
          The minimum down-ramp length can be determined as N - J + 1 where J is the maximum index for which authorized(A(J), A(J-1)) returns "No Attestation" or "Not Provider+". If there is no such J, the minimum down-ramp length is set equal to the AS_PATH length N.
          This parameter is abbreviated as min_down_ramp.
        </t>

        <t>
          If the sum of max_up_ramp and max_down_ramp is less than N, the AS path is Invalid.
          Else, if the sum of min_up_ramp and min_down_ramp is less than N, enough information is not available to perform full AS path verification, and the outcome is set to Unknown.
          Else, the AS path is Valid.
        </t>

        <t>
          Below are formal procedures for path verification depending on the peering relationship between the receiving AS and its neighbor.
          These procedures use the compressed sequence representation of AS_PATH {AS(N), AS(N-1),..., AS(2), AS(1)} and the above-defined parameters max_up_ramp, min_up_ramp, max_down_ramp, and min_up_ramp
        </t>
      </section>

      <section title="Algorithm for Upstream Paths" anchor="Upflow">
        <t>
          The upstream verification algorithm described here is applied when a route is received from a Customer or Peer, or is received by an RS from an RS-client, or is received by an RS-client from an RS.
          In all these cases, the receiving/validating eBGP router expects the AS_PATH to have only an up-ramp (no down-ramp) for it to be Valid.
          Therefore, max_down_ramp and min_down_ramp are set to 0.
        </t>
        <t>
          The upstream path verification procedure is specified as follows:
        </t>
        <t>
          <list style="numbers">
            <t>
              If the AS_PATH is empty, then the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If the receiving AS is not an RS-client and the most recently added AS in the AS_PATH does not match the neighbor AS, then the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If the AS_PATH has an AS_SET, then the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If max_up_ramp &lt; N, the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If min_up_ramp &lt; N, the procedure halts with the outcome "Unknown".
            </t>
            <t>
              Else, the procedure halts with the outcome "Valid".
            </t>
          </list>
        </t>
      </section>

      <section title="Algorithm for Downstream Paths" anchor="Downflow">
        <t>
          The downstream verification algorithm described here is applied when a route is received from a Provider.
        </t>
        <t>
          <list style="numbers">
            <t>
              If the AS_PATH is empty, then the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If the most recently added AS in the AS_PATH does not match the neighbor AS, then the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If the AS_PATH has an AS_SET, then the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If max_up_ramp + max_down_ramp &lt; N, the procedure halts with the outcome "Invalid".
            </t>
            <t>
              If min_up_ramp + min_down_ramp &lt; N, the procedure halts with the outcome "Unknown".
            </t>
            <t>
              Else, the procedure halts with the outcome "Valid".
            </t>
          </list>
        </t>
      </section>

      <section title="Mitigation Policy" anchor="mitigation">
        <t>
         The specific configuration of a mitigation policy based on AS_PATH verification using ASPA is at the discretion of the network operator.
         However, the following mitigation policy is highly recommended.
        </t>
        <t>
        <strong>Invalid</strong>:
         If the AS_PATH is determined to be Invalid, then the route SHOULD be considered ineligible for route selection (see <xref target="terminology"/>) and MUST be kept in the Adj-RIB-In for potential future re-evaluation (see <xref target="RFC9324"/>).
        </t>
        <t>
        <strong>Valid or Unknown</strong>:
         When a route is evaluated as Unknown (using ASPA-based AS_PATH verification), it SHOULD be treated at the same preference level as a route evaluated as Valid.
        </t>
      </section>
    </section>

    <section title="Deployment Recommendations" anchor="deployment">
      <t>
        This section describes practical deployment recommendations.
      </t>

      <section title="Application of Verification Procedures" anchor="impl-verif">
        <t>
          The verification procedures described in this document MUST be applied to BGP routes with {AFI, SAFI} combinations {AFI 1 (IPv4), SAFI 1} and {AFI 2 (IPv6), SAFI 1} <xref target="IANA-AF"/> <xref target="IANA-SAF"/>.
          The procedures MUST NOT be applied to other address families by default.
        </t>
        <t>
          The procedures for ASPA-based AS_PATH verification are intended for implementation on edge routers on the ingress side.
          This includes edge routers on the boundary of an AS Confederation facing external ASes.
          However, the procedures are NOT RECOMMENDED for use on internal BGP (iBGP) sessions or eBGP sessions internal to an AS Confederation.
        </t>
      </section>

      <section title="BGP Roles" anchor="role">
        <t>
          The BGP Role configuration parameter and its cross-check in BGP OPEN message as specified in <xref target="RFC9234"/> are RECOMMENDED.
          The configured BGP Roles SHOULD be used to automate the use of the above-described AS path verification procedures helping to distinguish whether upstream or downstream procedures should be applied.
          The automatic BGP Role cross-check <xref target="RFC9234"/> should facilitate more accurate and effective deployment of ASPA. 
        </t>
      </section>

      <section title="Complex Peering Relationships" anchor="complex">
        <t>
          If multiple eBGP sessions can segregate the Complex peering relationship into eBGP sessions with normal peering relationships the receiving/verifying AS SHOULD select the algorithm (per <xref target="Upflow"/> or <xref target="Downflow"/>) for each of the normal sessions based on its peering relation type.
        </t>
        <t>
          If a Complex peering relation can't be segregated (i.e., when a Complex BGP relationship occurs within one single BGP session),an operator may want to achieve an equivalent outcome by applying an appropriate algorithm (<xref target="Upflow"/> or <xref target="Downflow"/>) on a per-prefix basis corresponding to the peering relation for the prefix.
          If this option is not feasible, the operator MAY apply <xref target="Downflow"/> to avoid false positive outcomes..
        </t>
      </section>

      <section title="Logging" anchor="logging">
        <t>
          For any route with an Invalid AS_PATH, the cause of the Invalid state SHOULD be logged for monitoring and diagnostic purposes.
          The cause of the Invalid state can be recorded in the form of listing the AS hops which were evaluated by the provider authorization function to be &quot;Not Provider+&quot;.
          The logging router, however, cannot necessarily determine the AS that caused the route leak.
        </t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <section title="Incongruence in IPv4 and IPv6 Connectivity">
        <t>
          The U-SPAS contains the union of Providers for a CAS for both IPv4 and IPv6 unicast connectivity.
          This design choice consequently means that if a customer-provider relationship exists for one address family but doesn't exist for the other address family, AS_PATH verification outcomes for the latter AFI will be as permissive as verification outcomes for the former AFI.
          That is believed to be a reasonable compromise as both the ASPA registration and verification processes are simplified, and no false positive outcomes are yielded (e.g. inadvertent Invalid evaluation).
        </t>
      </section>

      <section title="Provider as Trusted Point">
        <t>
          Since an upstream provider becomes a trusted point, in theory, it might be able to propagate some instances of hijacked prefixes with forged-origin or forged-path-segment or even routes with manipulated AS_PATHs, and such attacks might go undetected by its customers or upper providers.
        </t>
        <t>
          While such attacks may happen, it does not seem to be a realistic scenario.
          Normally a customer and their transit provider would have a signed agreement, and a policy violation (of the above kind) should have legal consequences or the customer can just drop the relationship with such a provider and remove the corresponding ASPA record.
        </t>
      </section>

      <section anchor="prepend" title="Manipulating AS_PATH Prepends">
        <t>
          The ASPA verification procedures cannot detect the removal (or addition) of repeats of AS numbers in the AS path.
          However, this attack by itself does not affect ASPA's route leak detection capability.
        </t>
      </section>

      <section title="Correctness of the ASPA">
        <t>
          Network operators must keep their ASPA objects correct and up to date <xref target="rec1"/>.
          The outdated and incorrect CAS may affect route propagation or limit route leak detection capabilities.
        </t>
      </section>
    </section>

    <section title="Comparison to Other Technologies">
      <section title="ROA">
        <t>
          ROAs <xref target="RFC6482"/> are digitally signed objects that bind an address to an AS number, and are signed by the address holder.
          ROV procedure <xref target="RFC6483"/> works by verifying that an AS is authorized to originate a specific prefix.
          The joint use of ROA and ASPA records and their corresponding verification procedures may establish security trusted chain capable to detect not only accidental route leaks but also AS_PATH manipulations <xref target="bgp-cycling"/>.
        </t>
      </section>

      <section title="BGPsec">
        <t>
          The BGPsec <xref target="RFC8205"/> protocol was designed to solve the problem of AS_PATH verification by including cryptographic signatures in BGP Update messages.
          It offers protection against unauthorized path modifications and assures that the BGPsec Update traveled the path shown in the BGPsec_PATH Attribute.
          However, it does not detect route leaks (valley-free violations).
          Thus, BGPsec and ASPA are complementary technologies.
        </t>
      </section>

      <section title="Peerlock">
        <t>
          The Peerlock mechanism <xref target="Peerlock"/> <xref target="Flexsealing"/> has a similar objective as the ASPA-based route leak protection mechanism described in this document.
          It is commonly deployed by large Internet carriers to protect each other from route leaks.
          Peerlock depends on a laborious manual process in which operators coordinate the distribution of unstructured Provider Authorizations through out-of-band means in a many-to-many fashion.
          On the other hand, ASPA's use of the RPKI allows for automated, scalable, and ubiquitous deployment, making the protection mechanism available to a wider range of network operators.
        </t>
        <t>
          The ASPA mechanism implemented in router code (in contrast to Peerlock's AS_PATH regular expressions) also provides a way to detect anomalies propagated from transit providers and IX route servers.
          ASPA is intended to be a complete solution and replacement for existing Peerlock deployments.
        </t>
      </section>

      <section title="Only to Customer (OTC) Attribute" anchor="otc">
        <t>
          While the ASPA-based AS_PATH verification method (<xref target="verif"/>, <xref target="mitigation"/>) detects and mitigates route leaks that were created by preceding ASes listed in the AS_PATH, it lacks the ability to prevent the local AS from initiating a route leak towards its neighbor.
          ASPA verification may also fail to detect route leaks in case of presence of Complex relations in the AS_PATH.
          The use of the Only to Customer (OTC) Attribute fills in that gap (see Section 5, <xref target="RFC9234"/>).
          The implementation of the procedures utilizing the OTC Attribute is RECOMMENDED to complement the ASPA-based AS_PATH verification.
        </t>
      </section>
    </section>

  <section anchor="IANA" title="IANA Considerations">
    <t>
      This document includes no request to IANA.
    </t>
  </section>

  <section removeInRFC="true">
    <name>Implementation Status</name>
      <t>
        This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft.
        The inclusion of this section here follows the process described in <xref target="RFC7942"/>.
        The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
        Please note that the listing of any individual implementation here does not imply endorsement by the IETF.
        Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.
        This is not intended as, and must not be construed to be, a catalog of available implementations or their features.
        Readers are advised to note that other implementations may exist.
      </t>
      <t>
        According to <xref target="RFC7942"/>, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
        It is up to the individual working groups to use this information as they see fit".
      </t>
      <t>
      <ul>
        <li>
          A BGP implementation <xref target="bgpd">OpenBGPD</xref> (version 7.8 and higher), written in C, was provided by Claudio Jeker, Theo Buehler, and Job Snijders.
        </li>
        <li>
          The implementation NIST-BGP-SRx <xref target="BGP-SRx"/> is a software suite that provides a validation engine (BGP-SRx) and a Quagga-based BGP router (Quagga-SRx).
          It includes unit test cases for testing the ASPA-based path verification.
          It was provided by Oliver Borchert, Kyehwan Lee, and their colleagues at US NIST.
          It requires some additional work to incorporate the latest changes in the draft specifications related to IXP RS AS and RS-client.
        </li>
        <li>
          Implementation of ASPA-based AS path verification in the BIRD Internet Routing Daemon [BIRD] is provided in a side branch (branch mq-aspa) by Katerina Kubecova and Maria Matejka. 
          Its release is expected after RTR v2 is finalized.
        </li>
      </ul>
      </t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.6480.xml"?>
      <?rfc include="reference.RFC.6482.xml"?>
      <?rfc include="reference.RFC.6811.xml"?>
      <?rfc include="reference.RFC.4271.xml"?>
      <?rfc include="reference.RFC.6793.xml"?>
      <?rfc include="reference.RFC.7606.xml"?>
      <?rfc include="reference.RFC.7908.xml"?>
      <?rfc include="reference.RFC.8174.xml"?>
      <?rfc include="reference.RFC.9234.xml"?>
      <?rfc include="reference.RFC.9324.xml"?>
      <?rfc include="reference.I-D.ietf-sidrops-aspa-profile.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.3779.xml"?>
      <?rfc include="reference.RFC.5280.xml"?>
      <?rfc include="reference.RFC.8205.xml"?>
      <?rfc include="reference.RFC.7942.xml"?>
      <?rfc include="reference.RFC.9319.xml"?>
      <?rfc include="reference.RFC.6483.xml"?>
      <?rfc include="reference.I-D.ietf-grow-route-leak-detection-mitigation.xml"?>
      <?rfc include="reference.I-D.ietf-idr-deprecate-as-set-confed-set.xml"?>
      <?rfc include="reference.I-D.ietf-sidrops-aspa-notation.xml"?>
      <reference anchor="Peerlock" target="https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf">
        <front>
          <title>Peerlock</title>
          <author fullname="Job Snijders" initials="J." surname="Snijders">
            <organization abbrev="NTT">NTT Communications</organization>
          </author>
          <date month="June" year="2016"/>
        </front>
      </reference>

      <reference anchor="Flexsealing" target="https://arxiv.org/pdf/2006.06576.pdf">
        <front>
          <title>Flexsealing BGP Against Route Leaks: Peerlock Active Measurement and Analysis</title>
          <author fullname="Tyler McDaniel" initials="T." surname="McDaniel">
            <organization>University of Tennesse</organization>
          </author>
          <author fullname="Jared M. Smith" initials="J." surname="Smith">
            <organization>University of Tennesse</organization>
          </author>
          <author fullname="Max Schuchard" initials="M." surname="Schuchard">
            <organization>University of Tennesse</organization>
          </author>
          <date month="November" year="2020"/>
        </front>
      </reference>

      <reference anchor="bgp-cycling" target="https://pc.nanog.org/static/published/meetings/NANOG76/1978/20190611_Azimov_Bgp_Route_Security_v1.pdf">
        <front>
          <title>BGP Route Security Cycling to the Future!</title>
          <author initials="A." surname="Azimov"><organization /></author>
          <date month="October" year="2019"/>
        </front>
        <seriesInfo name="NANOG-76, North American Network Operator Group Meeting," value="Slides archives from NANOG" />
      </reference>

      <reference anchor="nanog-aspa" target="https://storage.googleapis.com/site-media-prod/meetings/NANOG89/4809/20231017_Sriram_Aspa-Based_Bgp_As_Path_v1.pdf (slides)  https://www.youtube.com/watch?v=GdVnZGd7jMo (video)">
        <front>
          <title>ASPA-based BGP AS_PATH Verification and Route Leaks Solution</title>
          <author initials="K." surname="Sriram"><organization /></author>
          <date month="October" year="2023"/>
        </front>
        <seriesInfo name="NANOG-89, North American Network Operator Group Meeting," value="Slides/video archives from NANOG" />
      </reference>

      <reference anchor="IANA-AF" target="https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml" quote-title="true">
        <front>
          <title>Address Family Numbers</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
        <!-- <seriesInfo name="Reachable from" value="http://www.iana.org/numbers.html"/> -->
      </reference>

        <reference anchor="IANA-SAF" target="https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml" quote-title="true">
          <front>
            <title>Subsequent Address Family Identifiers (SAFI) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        <!-- <seriesInfo name="Reachable from" value="http://www.iana.org/numbers.html"/> -->
        </reference>

        <reference anchor="bgpd" target="http://www.openbgpd.org/">
          <front>
            <title>OpenBGPD</title>
            <author initials="C." surname="Jeker">
              <organization>OpenBSD</organization>
            </author>
            <date/>
          </front>
        </reference>

        <reference anchor="BGP-SRx" target="https://www.nist.gov/services-resources/software/bgp-secure-routing-extension-bgp-srx-software-suite">
          <front>
            <title>BGP Secure Routing Extension (BGP-SRx) Software Suite</title>
            <author initials="K." surname="Lee"><organization /></author>
            <author initials="O." surname="Borchert, et al."><organization /></author>
          </front>
          <seriesInfo name="NIST Open-Source Software" value=""  />
        </reference>
        <reference anchor="BIRD" target= "https://bird.nic.cz/en/">
          <front>
            <title>BIRD Internet Routing Daemon; branch mq-aspa </title>
            <author initials="K." surname="Kubecova"><organization /></author>
            <author initials="M." surname="Matejka"><organization /></author>
          </front>
          <seriesInfo name="CZ.NIC BIRD Open-Source Software" value=""  />
        </reference>
    </references>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>
        The authors wish to thank Claudio Jeker, Jakob Heitz, Amir Herzberg, Igor Lubashev, Ben Maddison, Russ Housley, Jeff Haas, Nan Geng, Nick Hilliard, Shunwan Zhuang, Yangyang Wang, Martin Hoffmann, Jay Borkenhagen, Amreesh Phokeer, Aftab Siddiqui, Dai Zhibin, Doug Montgomery, Padma Krishnaswamy, Rich Compton, Andrei Robachevsky, Rudiger Volk, Iljitsch van Beijnum, Tassilo Tanneberger, Matthias Waehlisch, Moritz Schulz, and Carl Seifert for comments, suggestions, and discussion on the path verification procedures or the text in the document.
        For the implementation and testing of the procedures in the document, the authors wish to thank Claudio Jeker and Theo Buehler <xref target="bgpd"/>, Kyehwan Lee and Oliver Borchert <xref target="BGP-SRx"/>, and Katerina Kubecova and Maria Matejka <xref target="BIRD"/>.
      </t>
    </section>

    <section title="Properties and Early Adoption Benefits" anchor="property">
      <t>
        The ASPA method has the properties (i.e., anomaly detection capabilities) listed below.
        Partial deployment scenarios and early adoption benefits are considered.
        In the case of Property 1, it is assumed that the attacks involve route leaks but not malicious removal of ASes with ASPA records from the AS path.
      </t>
      <t>
        <list style="">
          <t>
            <strong>Property 1 (Route Leak Detection):</strong> Let AS A and AS B be any two ASes in the Internet doing ASPA (registration and path verification) and no assumption is made about the ASPA deployment status of other ASes.
            Consider a route propagated from AS A to a customer or lateral peer.
            The route is subsequently leaked by an offending AS in the AS path before being received at AS B on a customer or lateral peer interface.
            The ASPA-based path verification at AS B always detects such a route leak though it may not be able to identify the AS that caused the leak.
          </t>
          <t>
            <strong>Corollary of Property 1:</strong> An observation that follows from Property #1 above is that if any two ISP ASes register ASPAs and implement the detection and mitigation procedures, then any route received from one of them and leaked to the other by an AS in their overlapping customer cones (ASPA compliant or not) will be automatically detected and mitigated.
            In effect, if most major ISPs are compliant, the propagation of route leaks in the Internet will be severely limited.
          </t>
          <t>
            <strong>Property 2 (Detection of Forged-Origin Prefix Hijack):</strong> Again, let AS A and AS B be any two ASes in the Internet doing ASPA (registration and path verification) and no assumption is made about the ASPA deployment status of other ASes.
            Consider a route received at AS B on a customer or lateral peer interface that is a forged-origin prefix hijack involving AS A as the forged-origin.
            Assume that the offending AS X is not included in the ASPA of AS A.
            The ASPA-based path verification at AS B always detects such a forged-origin prefix hijack.
          </t>
          <t>
             <strong>Property 3 (Detection of Forged-Path-Segment Prefix Hijack):</strong> This is an extension of Property 2 above to the case of prefix hijacking with a forged-path-segment.
             Such hijacking refers to the forging of multiple contiguous ASes in an AS path beginning with the origin AS.
             Again, let AS A and AS B be any two ASes in the Internet doing ASPA (registration and path verification).
             Assume that AS A's providers, AS P and AS Q, also register ASPA.
             No assumption is made about the ASPA deployment status of any other ASes in the Internet.
             Consider a route received at AS B on a customer or lateral peer interface that is a prefix hijack with a forged-path-segment {AS P, AS A} or {AS Q, AS A}.
             That is, the offending AS X attaches this path-segment at the beginning of its (AS X's) route announcement.
             Assume that AS X is not included in the ASPA of AS P or AS Q.
             The ASPA-based path verification at AS B always detects such a forged-path-segment prefix hijack.
             For a chance to be successful (remain undetected by AS B), the hijacker may resort to a forged-path-segment with three ASes including a provider AS of AS P (or AS Q).
             But even that can be foiled (detected) if the providers of AS P and AS Q also register ASPA.
             The forged-path-segment hijack in consideration is entirely prevented (for any forged-path-segment length) if all ASes in the contiguous C2P hops from AS A up to its Tier 1 have ASPA registrations.
          </t>
        </list>
      </t>
      <t>
        The above properties show that ASPA-based path verification offers significant benefits to early adopters.
        Limitations of the method with regard to some forms of malicious AS path manipulations are discussed in <xref target="security"/>.
      </t>
    </section>
  </back>
</rfc>