An Analysis of ASPA-based AS

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).

Protecting Against Route Leak In full ASPA deployment (within a given region of interest), all "route leaks" (valley-free violations ) 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.

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 .

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

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

Path manipulation based on bogus ASPA records

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 . 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.

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. 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.

Malicious route leak

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 ). However, current ASPA document 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 , 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.

IBGP and eBGP verification ASBR1|----> RR |---->ASBR2|-|----->AS3 /| +-----+ /+-----+ +-----+ |\ / | / | \ / +---------/---------------------+ \ / / \ eBGP ingress iBGP ingress eBGP egress ]]> 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 ). According to the verification result, the router decides to propagate the route or not. In , 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.

Not Applicable to Complex Relationship Scenarios AS relationships in practical networks may be more complex than the traditional P2C/P2P model . 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 . 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 for examples), even prefixes (i.e., different relationships/policies for different prefixes).

Hybrid relationship | | AS1 | | AS2 | | |--------------> | +-------+ Asia P2P +-------+ (a) Location-dependent +-------+ IPv6 P2C +-------+ | |--------------> | | AS1 | | AS2 | | |--------------> | +-------+ IPv4 P2P +-------+ (b) IP version-dependent ]]>

Partial transit relationship . 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. 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).

Partial transit relationship

Persistent valley-path (legitimate 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.

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.

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. shows two examples of partial deployment. In (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 (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.

Partial deployment