Unpacking the First Route Leak Prevented by ASPA

On 25 January, a fascinating email arrived in my inbox via the Secure Inter-Domain Routing Operations (SIDROPS) mailing list with the subject line “first route leak prevented by ASPA”.

The email was sent by Claudio Jeker, who is the lead developer at Route Server Support Foundation (RSSF) and also a developer for OpenBGPD and one of the main contributors to rpki-client, a major Resource Public Key Infrastructure (RPKI) relying party software.

In the email, Claudio shares a copy of a terminal message showing that the prefix 2606:b0c0:b00b::/48 originates from AS945 and its origin validation state is ‘Valid’ (V). I was able to confirm this information by checking the ROA validity, something you can do for any route via route-views route collector or Cloudflare RPKI explorer:

ROA Version:    0 
SigningTime:    2022-12-18T13:31:34Z 
asID:           945 
 addressFamily: 2 
     IPAddress: 2606:b0c0:b00b::/48 

However, the ! also indicates its aspa validation state is ‘Invalid’.

What is ASPA? 

Autonomous System Provider Authorization (ASPA) objects are created and distributed the same way as Route Origin Authorizations (ROAs). While ROAs state which ASNs are authorized to announce given prefixes, ASPAs state which ASNs are allowed to propagate their routes. 

The following is an example of the information available in an ASPA object, as defined in the draft-ietf-sidrops-aspa-profile.

   ASProviderAttestation ::= SEQUENCE { 
     version [0]   INTEGER DEFAULT 0, 
     customerASID  ASID, 
     providers     ProviderASSet } 

   ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS 

   ProviderAS ::= SEQUENCE { 
     providerASID  ASID, 
     afiLimit      AddressFamilyIdentifier OPTIONAL } 

   ASID ::= INTEGER (0..4294967295) 

   AddressFamilyIdentifier ::= OCTET STRING (SIZE (2))  

On 17 December 2022, the ASPA object created by AS945 shows four providers are allowed to propagate its routes: AS1299, AS6939, AS32097, and AS50058.

This is different from the BGP announcement from 26 January, which shows two providers propagating 945 routes: AS50058 and AS61138.

01/26/23 01:54:24 A 2606:b0c0:b00b::/48 13830 3356 6939 61138 945 
01/26/23 01:54:24 A 2606:b0c0:b00b::/48 13830 50058 50058 50058 50058 945 
01/26/23 01:54:24 A 2606:b0c0:b00b::/48 14907 6939 61138 945 
01/26/23 01:54:24 A 2606:b0c0:b00b::/48 14907 50058 50058 50058 50058 945 
01/26/23 01:54:24 A 2606:b0c0:b00b::/48 206499 6939 61138 945 

The first, AS50058, exists in the ASPA object. However, AS61138 doesn’t exist, which is why it returned an ASPA ‘Invalid’ record.

Claudio later confirmed that it was an oversight from AS945 and after highlighting this issue they added AS61138 to their list of providers that are allowed to propagate their routes, as seen below:

This example shows that ASPA objects can mitigate these types of misconfiguration issues that can lead to route leaks.

Special thanks to Claudio for providing the details, and to the developers at OpenBGPD (including Claudio and Job Snijders) and Krill (NLnetlabs) for implementing ASPA in their software. For a full list of contributors please check ASPA Profile draft.

How to Check ASPA Objects Yourself

If you’re interested in reading the content of ASPA objects, you can check any of the repositories used by your choice of relying party software or download a whole repository dump from the RPKI Views website. ASPA records are also available on the rpki-client website. I used rpki-client to view the .asa file. rpki-client is the only tool available to view ASPA objects thanks to Job Snijders for implementing ASPA support in rpki-client.

You can also view .roa files using RPKI Utils, a project sponsored and supported by ISOC research.

The MANRS initiative, being technology agnostic, fully supports all technologies that can help mitigate route misorigination and route leaks. We strongly recommend all network operators not only create ROAs for all their address space but also move towards validating those routes (ROV). Once ASPA becomes a standard (most likely soon), we will encourage operators to document their BGP relationship, which can then be verified.