When people talk about ‘AS0’ in Resource Public Key Infrastructure (RPKI), they may be referring to one of two things: the AS0 Trust Anchor Locator (TAL) or an AS0 Route Origin Authorization (ROA).
In this post, I will clarify the two to mitigate any confusion.
What is the AS0 TAL?
A TAL is a file that points to the location of a Trust Anchor (TA), and gives the public key you should expect to see in that TA.
TAs are fundamental to the Public Key Infrastructure (PKI). They are the understood basis of trust, which ‘anchor’ all other calculations of trust based on the application of cryptographic signatures over the contents of the PKI system as a whole. Without a TA, you cannot anchor the assertions in trust you are validating.
The TA defines a key, whose signatures are simply accepted. You can have more than one TA, and you can have processes to revoke and reject a TA (we don’t currently have those in RPKI).
Most people never consciously interact with their set of TAs; they are typically managed for you by your employer, or even by your browser vendor. For example, many updates to Chrome, Firefox and other browsers, are updating a list of TAs installed in the browser software, to change what is trusted in the public web.
APNIC operates an AS0 TAL, which is a distinct TA locator pointing to a completely independent RPKI TA also operated by APNIC. This APNIC AS0 TAL only ever signs over resources that APNIC does not believe are meant to be in use in the public Internet.
The APNIC AS0 TAL publishes AS0 ROAs (as I’ll describe further below), as do individual resource holders of Internet addresses (except in their case under the main RPKI TA). It is used exclusively to sign AS0 ROAs, which associate these undelegated resources with origin-AS AS0s to ensure they are seen to be ‘disavowed’ for routing use in the Border Gateway Protocol (BGP).
APNIC removes resources from the AS0 ROAs it publishes, under the APNIC AS0 TAL as the resources are delegated, and adds resources as they are terminated or returned to APNIC or when new resources are received from IANA.
APNIC recommends its Members use APNIC AS0 TAL as a routing information service only. It doesn’t recommend including the TAL in the system that provides validity signals to your production BGP systems.
This means AS0 ROAs published under the APNIC AS0 TAL are not expected to be used to configure your BGP production systems directly. This doesn’t mean you should ignore AS0 ROAs made by resource holders under the production RPKI. These are products of the individual resource holders, and are strong indications of routing intent, and you should continue to use these directly when configuring BGP. If you enable the use of RPKI-RTR, you can trust the feed of information that is informed by these delegate-produced AS0 ROAs.
What is an AS0 ROA?
An AS0 ROA is an administrative ‘trick’ defined in the RPKI RFCs to declare that without some other RPKI ROA object specifying a valid origin-as, no BGP route with this prefix (or its children, more specific prefixes) should be accepted.
As a reminder, a ROA declares a valid (testable, cryptographically) origin-AS to associate with a given set of prefix/length/max-length resources.
Learn more about Resource Public Key Infrastructure
This works because AS0 — the null AS — is not to be seen in routing, so a declaration that a prefix ‘can be routed by AS0’ is the same as declaring it is not to be routed. Because there is no ‘not to be routed’ objects, we are using the ROA mechanism to declare an origin, which cannot be used in the BGP.
Does this exclude the prefix from being seen in the BGP?
No. Even in RPKI-filtered BGP, it only forces the prefix, or more specifics to be routed by origin-AS with a valid ROA. In effect, it is a giant on-off switch, which means only RPKI protected origin-ASes should be accepted by BGP speakers that respect RPKI information about validity. You use AS0 to stop non-RPKI signed origins being valid, because the RPKI validation process includes ‘unknown’ — there is no visible RPKI state to validate things. AS0 forces all the otherwise ‘unknown’ routes, to become invalid routes.
How does this all work?
This works because of a fundamental principle of RPKI: cryptographic validation. The existence of any valid cryptographic chain of trust over an assertion, which anchors into any TA you accept, validates the object. It doesn’t matter that under another TA or certificate chain it is not able to be validated, the existence of any cryptographically valid information is valid.
Since AS0 is declared origin-AS and means ‘not to be routed’ it does not invalidate any other ROA with another origin-AS that you want to be routed. Instead it only excludes all the origin-ASes you don’t issue a ROA for, for all the address space covered in the ROA.
But I can trust an AS0 ROA from the main RPKI TAL, right?
Irrespective of what APNIC recommends about its AS0 TAL and other products, it does not make any ROA about any resources in the main RPKI system, except about ranges it manages itself. So, any AS0 ROA you see has been made by a resource holder who holds address space under RIR policy, and who chooses to make an AS0 ROA about their own space, to inform their own BGP origin intentions.
It is not a statement made by APNIC, and it is not meant to be validated under the APNIC AS0 TAL. It is valid, if it is about APNIC-managed ranges, if the chain of trust over the certificates for the ROA are valid under the APNIC main TA.
You can trust objects, no matter what origin-AS they have, made in the main RPKI system, and you should be free to decide to configure your BGP from these ROAs, even if they are AS0 ROA, because they are provable statements of intent made by the resource holder who controls the prefix in question.
This is quite distinct from the cryptographic validity of AS0 ROA, made by APNIC Members, under the main RPKI TA. APNIC recommends these be used to configure your BGP as normal.
Will my resources appear on the AS0 TAL?
The short answer is no: APNIC does not and will not add resources deliberately to the APNIC AS0 TAL that it knows to be validly delegated by APNIC, or an NIR, to a resource holder. This is completely against its operating model, which only uses the resources marked as ‘available’ in the RIR extended delegated statistics reports, which APNIC publishes daily.
Of course it is possible they make a mistake, and I encourage anyone who sees resources listed in the APNIC AS0 TAL to contact the APNIC Heldesk immediately if they think this is in error.
It is possible during an address reclaim that APNIC will be marking resources as reclaimed — they have a normal process to hold these from being re-marked as ‘available’ for an extended period (subject to policy) and so these will not normally be included in the APNIC AS0 TAL if they are still in dispute or subject to ageing in reclamation. The resources should only be included in the APNIC AS0 TAL at the end of the reclamation process, when they are confirmed available for reuse.
APNIC manages redelegation and delegations in general, to ensure that resources are removed from the APNIC AS0 TAL within five minutes of delegation to an APNIC or NIR member. APNIC is not operating the AS0 TAL as a ‘control’ mechanism, and for similar reasons it did not recommend direct inclusion of the AS0 ROA in BGP calculations — that’s a step beyond its role as a delegation authority.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.