Autonomous System Provider Authorization (ASPA)

Signing ASPAs?

An ASPA object is a signed RPKI Object that allows the holder of an AS number to authorise one or more other AS numbers to appear as their legitimate upstream providers in BGP.

As we will see later, the ASPA path validation process only requires upstream providers to be included. If you have a ‘complex relationship’ with a neighbor AS, i.e. this AS plays multiple peering roles, including the provider role, it should also be included as a provider in your ASPA object. Note that non-transparent route servers at an Internet exchange also appear in the BGP path in a provider role and should also be included. Otherwise, lateral peers and customers must not be included.

As with ROAs, if you choose to sign an ASPA object for your AS, make sure that you include all your upstream providers and keep this object up to date in lockstep with changes in your blend of upstream providers. The RIPE NCC RPKI Dashboard gives no hints or guidance about which providers are seen for your AS in BGP, so you will need to ensure this yourself. If you forget or neglect to include a provider, this can lead to the rejection of routes you send via the unlisted provider.

Just like signing ROAs, signing ASPA objects is therefore not without risk if you are not prepared to proactively maintain these objects as part of your network operations. However, by not signing ASPA you will not get the benefits this can give you:

• Most importantly, ASPA verification protects against certain types of route leaks.
• ASPA verification makes it harder for attackers to spoof a BGP path that includes your AS and the more AS holders sign their ASPA objects, the more difficult this becomes.

Verifying Paths from Customers

The ASPA verification process for paths that providers receive from their customers insists that each AS-to-AS hop on the received path has a plausible customer-to-provider relationship. Or rather, it rejects such paths if any of this is implausible for any such hops.

To do this, the process uses the ASPA “Provider Authorization Function” to evaluate each AS-to-AS hop starting from the origin. The following outcomes are possible:

• Provider
  There is an ASPA object signed by the prospective customer AS that includes the other AS among its providers.
  
• Not Provider
  There is an ASPA object signed by the prospective customer AS but it does NOT include the other AS among its providers.
  
• No Attestation
  There is no ASPA object signed by the prospective customer AS. Therefore, any other AS may appear as its provider.

The full path received from a customer can have the following status outcomes:

• Valid
  Each AS-to-AS Authorization Function yields “provider”.
  
• Invalid
  At least one AS-to-AS Authorization Function yields “not provider”.
  
• Unknown
  At least one AS-to-AS Authorization Function yields “no attestation”, but there is no occurrence of “not provider”.

Paths that are verifiably invalid should be rejected. Both valid and unknown paths should be accepted. The latter is important, not only because of partial adoption of ASPA signing, but also because dropping unknown paths would result in outages in case of any issue with RPKI validation itself.

Note that this allows providers, and also Tier-1 network providers, to effectively filter out many paths that would be invalid. Path spoofing gets harder with ASPA because an attacker would have to include longer and longer paths to avoid including implausible (not provider) hops.

Verifying Other Paths - Valley-Free Routing

The verification process for paths received from peers or providers is slightly different because it cannot assume that each hop starting from the origin represents a plausible (or not implausible) customer-to-provider relationship all the way to the receiver.

Instead, the verification process uses the concept of “valley-free” routing, which requires that routes can have only one “up(hill)” component, from customers to providers, and one “down(hill)” component, from providers to customers that meet in a single peak: a transit-free provider or two adjacent peers.

Any route that goes “up”, then “down”, and then “up” again, and presumably “down” again, has a “valley” in the middle. Such paths are considered harmful as they usually are route leaks that make routing less optimal (e.g. longer latency, congested links, potentially more expensive). In essence, the ASPA verification process yields invalid for any paths that it can prove to have such a valley.

To determine this, the process relies on finding the longest possible customer-to-provider paths from both directions in the path. These longest possible paths terminate at the first “not provider” AS to AS relationship that is found.

The path as a whole is invalid if the length of the “up” and “down” paths thus found, is smaller than the full path length. Or, in other words, they are separated by more than one adjacency indicating a valley.

If the “up” and “down” path do not overlap, but they meet at a single adjacency, then it is assumed that this is because of lateral peering. If the “up” and “down” paths meet in a single AS, then this is a shared provider, or it might be a peer with a complex relationship (that includes the provider role) to its neighbour. If there are multiple shared ASes, then this is likely because of partial adoption in ASPA signing. All these cases are either valid or unknown, and should be accepted.

For a more precise definition of the verification algorithm including differentiating between valid and unknown paths, please refer to the ASPA verification IETF draft. This ASPA-based AS Path Verification Examples document is another useful source.

Validation and Verification Toolchain

The ASPA validation and verification toolchain is the same as the toolchain that is used for Route Origin Validation:

• The RPKI tree and signed objects, such as in this case ASPA objects, are validated by RPKI validators, often referred to as Relying Party software.
• After validation, operators can optionally use SLURM filters to apply local exceptions to the validated content.
• Routers typically get this content using the RPKI to router (rpki-rtr) protocol.
• Routers can then perform ASPA verification of paths without the need to support any cryptographic signing or verification.

This means that deploying ASPA validation and verification is not duplicate work! Existing ROV-related infrastructure can serve multiple purposes. However, updated versions of components are needed in order to support ASPA.