Internet-Draft ASPA analysis June 2024
Geng, et al. Expires 31 December 2024 [Page]
Intended Status:
N. Geng
M. Huang
Y. Wang
Tsinghua University

An Analysis of ASPA-based AS_PATH Verification


Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies.

The document can help people deploy ASPA properly and provide some potential directions of enhancing ASPA.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 31 December 2024.

Table of Contents

1. Introduction

Autonomous System Provider Authorization (ASPA) is a technique for verifying AS_PATHs in BGP updates [I-D.ietf-sidrops-aspa-verification][I-D.ietf-sidrops-aspa-profile]. Each AS can register ASPA records (also ASPA objects) in the RPKI to authorize a set of ASes as its providers. An AS can obtain ASes' ASPA records through RTRv2 protocol [I-D.ietf-sidrops-8210bis] and conduct AS_PATH verification based the records. ASPA-based AS_PATH verification can detect and mitigate route leaks violating the valley-free principle and path manipulations such as forged-origin or forged-path-segment attacks.

ASPA can significantly enhance AS_PATH verification and is promising to be widely deployed. Despite of the strengths of ASPA, there are also some deficiencies. This document provides a detailed analysis on the strengths and deficiencies of ASPA.

The document can help people deploy ASPA properly and provide some potential directions of enhancing ASPA.

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. ASPA Strengths and Disclaimers

ASPA records can be registered by an AS to authorize all its provider ASes. For the two ASes with mutual transit relationship, the two ASes will put each other AS into its own ASPA record (i.e., each AS considers the other AS as its provider).

2.1. Protecting Against Route Leak

In full ASPA deployment (within a given region of interest), all "route leaks" (valley-free violations [RFC7908]) are detectable. Route leaks involve one of the following four valley-free violations:

  • A route is propagated through a P2C (Provider-to-Customer) link and then a C2P (Customer-to-Provider) link.

  • A route is propagated through a P2P (Peer-to-Peer) link and then a C2P link.

  • A route is propagated through a P2P link and then a P2P link.

  • A route is propagated through a P2C link and then a P2P link.

It is expected that in partial ASPA deployment, not all route leaks are detectable.

2.2. Protecting Against Path Manipulation

Path manipulation can be path forgery or path tampering (i.e., insertion or removal of unique ASN) in this document. Forged-origin hijack and fake link-based hijack are all path manipulations.

In full ASPA deployment (within a given region of interest), ASPA protects against a majority of forged-origin hijacks. Each AS can attest its upstream ASes, so provider or lateral peer cannot be deceived. Customer could be deceived because ASPA does not provide attestations to downstream ASes or peering ASes.

Even in full ASPA deployment, not all path manipulation attacks can be detected. ASPA does not guarantee path correctness like that provided by BGPsec [RFC8205].

3. ASPA Deficiencies

This section describes the deficiencies of ASPA-based AS_PATH verification in detail.

3.1. Hard to Detect Bogus Records

An AS can unilaterally authorize a set of its provider ASes. Under the one-direction authorization, an AS may intentionally or unintentionally register bogus records that are hard to be discovered. An AS maliciously registers bogus records that open a door to potential attacks.

Figure 1 shows an example of path manipulation attack based on bogus ASPA records. AS4 lies in that the nonadjacent AS3 is its provider in the ASPA record. The attack cannot be detected even when AS1, AS2, AS3, and AS5 register ASPA records correctly and enable ASPA-based AS_PATH verification locally. As a result, AS5 will wrongly consider its traffic to AS1 traverses AS3, while the real forwarding path to AS1 is through AS2 instead of AS3.

              |AS1(P1)|Originate route
     path[1] /        \
            /(C2P)     \(C2P)
    +-------+           +-------+
    |  AS2  |           |  AS3  |
    +-------+           +-------+
           \             *
  path[2,1] \(C2P)      * (faked C2P in AS4's
             \         *   bogus ASPA)
              +-------+ ASPA{AS4, [AS2, AS3]}
              |  AS4  | Offender
      path[4,3,1] |(C2P)
              |  AS5  | Victim
  * All ASes register ASPA records
  * AS4's record states a faked C2P link with AS3
  * AS5 enables ASPA-based path verification
Figure 1: Path manipulation based on bogus ASPA records

3.2. Fail to Detect AS_PATH Manipulation by a Provider

ASPA-based AS_PATH verification cannot effectively detect the AS_PATH maliciously shortened by a provider, which has been acknowledged in [I-D.ietf-sidrops-aspa-verification].

Figure 2 shows an example. AS1 originates the BGP route and propagates the route to other ASes. The AS_PATH received by AS5 is path[4,3,2,1]. However, AS5 maliciously shortens the path by falsely claim a fake link with AS2 before AS5 propagates the route to AS6. AS6's traffic to AS1 may be hijacked by AS5 if the path[5,2,1] is shorter than any other AS_PATHs. In the example, AS5 may not intend to drop data traffic from AS6. That is, AS5 (provider) wants AS6 (customer) to prefer AS5's transit path for increasing revenue.

In this case, the attack cannot be detected even when all the ASes register the correct ASPA records and all the ASes other than AS5 enable ASPA-based AS_PATH verification.

                  |  AS4  |    path[4,3,2,1]
      path[3,2,1]/         \               \
                /(C2P)      \               \(C2P)
        +-------+            \path[4,3,2,1] +-------+
        |  AS3  |             \             |  AS7  |
        +-------+              \            +-------+
  path[2,1] |             (C2P) \             /
      (C2P) |                    \ Offender  /
        +-------+ (Fake link) +-------+     /
        |  AS2  |*************|  AS5  |    /
        +-------+             +-------+   /path[7,4,3,2,1]
    path[1] |          path[5,2,1]|      /
      (C2P) |     (path shoterned)|(C2P)/(C2P)
        +-------+             +-------+/
        |AS1(P1)|             |  AS6  | Victim
        +-------+             +-------+
      Originate route
Figure 2: AS_PATH maliciously shortened by a provider

AS_PATH manipulation by a provider may also be used to do malicious route leaks. ASPA is not designed for defensing path manipulation. So, some malicious route leaks with path manipulation involved cannot be prevented.

Figure 3 shows an example. AS2 is AS1's provider and arguably it may not leak its customer's prefix (P2) intentionally. But to increase revenue, AS2 may maliciously leak P2 with a modified AS_PATH (i.e., AS3 is removed) to AS4 for attracting more traffic to traverse AS2. Sometimes this attack may happen and goes undetected.

        |  AS4  |-------------
        +-------+             \
P1 path[2,1]|                  \
P2 path[2,1]|                   \ P2 path[3,1]
       (C2P)|                    \(C2P)
        +-------+ P2 path[3,1]+-------+
Offender|  AS2  |-------------|  AS3  |
        +-------+    (P2P)    +-------+
               \             /
      P1 path[1]\           /P2 path[1]
                 \(C2P)    /(C2P)
                  |   AS1   |Originate route
                  | (P1&P2) |
Figure 3: Malicious route leak

3.3. Not Directly Applicable to IBGP Ingress and EBGP Egress Verification

IBGP ingress verification and eBGP egress verification are meaningful in many scenarios. IBGP ingress verification is to check the AS_PATH received through iBGP connections. IBGP ingress verification helps an AS do verification on any BGP routers like non-ASBRs. EBGP egress verification means verifying the AS_PATH before sending it to the neighbor AS. It can prevent an AS from sending routes with Invalid AS_PATH to its neighbor ASes (just like eBGP egress RPKI-ROV [RFC8893]).

However, current ASPA document [I-D.ietf-sidrops-aspa-verification] does not specify how to do iBGP ingress verification. For iBGP ingress verification, the router (e.g., an RR) conducting the verification may not have BGP sessions with the neighbor AS that propagates the route and thus does not know the local BGP role with respect to the neighbor AS. Even so, iBGP ingress verification is doable because the router can obtain the local BGP role from the ASPA records of local AS. In Figure 4, when RR wants to do iBGP ingress verification, it can look up AS2's own ASPA records. If AS1 is listed as a provider, then apply the Downstream verification algorithm. If AS1 is not listed as a provider, then apply the Upstream verfication algorithm. Such an iBGP ingress verification also works correctly in RS and RS-client scenarios.

          | AS2                           |
   path[1]| +-----+    +-----+    +-----+ |path[2,1]
AS1-------|->ASBR1|----> RR  |---->ASBR2|-|----->AS3
         /| +-----+   /+-----+    +-----+ |\
        / |          /                    | \
       /  +---------/---------------------+  \
      /            /                          \
  eBGP ingress   iBGP ingress              eBGP egress
Figure 4: IBGP and eBGP verification

[I-D.ietf-sidrops-aspa-verification] does not specify how to do eBGP egress verification either. To try to do this, the router should add its own AS (i.e., AS2) to the AS_PATH and then performs ASPA-based AS_PATH verification from the perspective of next-hop AS (see Section 7.2 in version-15 of [I-D.ietf-sidrops-aspa-verification]). According to the verification result, the router decides to propagate the route or not. In Figure 4, ASBR2 would add its own AS (i.e., AS2) to the AS_PATH. If the BGP role of ASBR2 with respect to AS3 is customer/lateral peer/RS/RS-client, the Upstream verification algorithm will be conducted. If the BGP role of ASBR2 with respect to AS3 is provider, the Downstream verification algorithm will be performed. The verification process also works well in mutual transit scenarios.

The relationship between AS1 and AS2 can sometimes be obtained by ASBR2 from AS2's ASPA records. If AS1 is listed as a provider in the AS2's ASPA records, then the above route leak can be detected and prevented. If AS1 is not listed in the AS2's ASPA records, ASBR2 cannot decide AS1 is a lateral peer or a customer. Therefore, the above route leak cannot be detected directly.

Overall, iBGP ingress verification is doable with help of local AS's own ASPA records, while it is not possible to do eBGP egress verification correctly without more complexity.

3.4. Not Applicable to Complex Relationship Scenarios

AS relationships in practical networks may be more complex than the traditional P2C/P2P model [as-rela-1][as-rela-2]. In ASPA, only the complex relationship of mutual transit relationship has been considered. The followings are some other complex scenarios that are not covered by ASPA:

  • Hybrid relationship [as-rela-1][as-rela-2]. Two ASes may agree to have different traditional relationships for different Points-of-Presence (PoPs). A hybrid relationship may be dependent on IP versions or/and PoP locations (see Figure 5 for examples), even prefixes (i.e., different relationships/policies for different prefixes).

+-------+  Europe P2C  +-------+
|       |-------------->       |
|  AS1  |              |  AS2  |
|       |-------------->       |
+-------+   Asia P2P   +-------+

      (a) Location-dependent

+-------+   IPv6 P2C   +-------+
|       |-------------->       |
|  AS1  |              |  AS2  |
|       |-------------->       |
+-------+   IPv4 P2P   +-------+

      (b) IP version-dependent
Figure 5: Hybrid relationship
  • Partial transit relationship [as-rela-1][as-rela-2]. For a customer, the provider offers transit only toward the provider's peers and customers (or specific regions), but not the provider's providers, or restricts transit to a specific geographic region. Figure 5 shows an example. AS2 is the partial transit provider of AS1. AS2 should only propagate AS1's route to AS4 (i.e., AS2's peer) and AS5 (i.e., AS2's customer), but should not propagate the route to AS3 (i.e., AS2's provider).

        |  AS3  |
  path[2,1] |
(route leak)|
        +-------+  path[2,1]  +-------+
Offender|  AS2  |-------------|  AS4  |
        +-------+    (P2P)    +-------+
     Partial|    \                |
     transit|     \ path[2,1]     | path[4,2,1]
            |      ----------     |
    path[1] |           (C2P)\    |(C2P)
        +-------+             +-------+
        |  AS1  |             |  AS5  |
        +-------+             +-------+
      Originate route
Figure 6: Partial transit relationship
  • Persistent valley-path (legitimate valley-path) ([valley-path]). There may be legitimate valley-paths, i.e., violating the valley-free principle but the AS_PATH is legitimate. According to BGP data analysis, the persistent valley-path can be 10% of all BGP paths.

  Originate route
    +-------+             +-------+
    |AS1(P1)|             |  AS3  |
    +-------+             +-------+
            \             /
      path[1]\           / path[2,1] (not route leak)
              \(C2P)    /(C2P)
              |   AS2   |
Figure 7: Persistent valley-path

ASPA records do not support the registration of complex relationships except the mutual transit relationship. As a result, in the complex scenarios, AS_PATH cannot be effectively protected by ASPA-based AS_PATH verification.

3.5. Reduced Protection Capability in Partial Deployment

To verfify an AS_PATH, ASPA verification algorithms need to check each hop of the AS_PATH. When ASPA records of the ASes along the path are partially registered, not all hops in the path can be checked. In such partial deployment scenarios, ASPA may have a reduced protection capacity.

Figure 8 shows two examples of partial deployment. In Figure 8 (a), AS3 cannot detect the route leak of P1 induced by AS2 if AS1 has no ASPA record registered. This is because the Hop-check(AS1, AS2) function returns "No Attestation" and the final verification result is Unknown. In Figure 8 (b), AS3 is deceived by AS2 who falsely claims AS1 is AS2's neighbor. The attack in the example is undetectable because AS1 registers no ASPA record and AS3 cannot judge the validity of the link between AS1 and AS2.

                            |  AS3  |
                           / path[2,1] (route leak)
   No ASPA                /(C2P)
  +-------+  (P2P)  +-------+
  |AS1(P1)|---------|  AS2  | Offender
  +-------+ path[1] +-------+
Originate route

      (a) Route leak in partial deployment

                            |  AS3  |
                           / path[2,1] (path manipulation)
   No ASPA (no adjacency) /(C2P)
  +-------+         +-------+
  |AS1(P1)|*********|  AS2  | Offender
  +-------+ path[1] +-------+
Originate route

      (b) Forged-origin attack in partial deployment
Figure 8: Partial deployment

4. Reasons of ASPA Deficiencies

This section summarizes three main reasons that result in deficiencies of ASPA:

5. Security Considerations

This document does not involve security problems.

6. IANA Considerations

No IANA requirements.

7. Acknowledgements

Much Thanks for the comments from Kotikalapudi Sriram.

8. References

8.1. Normative References

Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-verification-17, , <>.
Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-18, , <>.
Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

8.2. Informative References

Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Work in Progress, Internet-Draft, draft-ietf-sidrops-8210bis-12, , <>.
Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, , <>.
Bush, R., Volk, R., and J. Heitz, "Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export", RFC 8893, DOI 10.17487/RFC8893, , <>.
"Stable and Practical AS Relationship Inference with ProbLink", , <>.
"Inferring Internet AS Relationships Based on BGP Routing Policies", .
"Valley-free violation in Internet routing - Analysis based on BGP Community data", , <>.

Authors' Addresses

Nan Geng
Mingqing Huang
Yangyang Wang
Tsinghua University