Trust anchors are the entry points used for validation in any Public Key Infrastructure (PKI) system.
This RPKI Validator is preconfigured with the trust anchors for AFRINIC, APNIC, Lacnic and RIPE NCC. In order to obtain the trust anchor for the ARIN RPKI repository, you will first have to accept their Relying Party Agreement. Please refer to the README.txt for details on how to add trust anchors to this application.
Route Origin Attestations (ROAs) are used in the RPKI to authorise specific ASNs to originate prefixes. In addition, a ROA specifies the maximum prefix length that the AS is authorised to originate. Only the legitimate holder of the prefix can create a valid ROA.
ROAs are intended to be positive attestations, but the presence of a ROA for an ASN and prefix combination implies that announcements of this prefix from other origin ASNs, or for more specific prefixes, will be considered invalid.
More than one ROA may exist for the same prefix and as long as one of them matches the announcement it is considered valid. The announcement validation rules are defined in RFC 6483 and are explained in more detail in the Router section.
ROAs may invalidate certain announcements and you as an operator may want to override that. This RPKI Validator allows you to ignore all ROAs that would otherwise affect certain prefixes.
If you use this option, it will be as though no ROAs exist for this prefix.
You may actually want to add your own whitelist entries for announcements that don't have a corresponding ROA but that you think should have.
If you use this option, it will be as though a ROAs exist for this announcement.
You can configure your router to connect to this validator so that it can receive a full set of Route Origin Attestations (ROAs) based on all the ROAs that were validated, minus your ignore list entries, plus your own whitelist entries.
Once your router receives the ROAs, it can use this information to determine the validity outcome of the origin AS in BGP announcements. To do this, your router will match an announcement to each attestation in this way:
|Annoucement has||an origin AS matching the attestation||an origin AS that differs from the attestation|
|a prefix matching the attestation||VALID||INVALID|
|a prefix that is more specific than the attestation||INVALID||INVALID|
The final judgement on whether an announcement should be considered valid, invalid or unknown depends on all relevant attestations using the following reasoning:
|At least one VALID||VALID|
|No VALIDS, at least one INVALID||INVALID|
|None of the above||UNKNOWN|
This information is now available to your router and can be used to automatically change the preference of route announcements. The way this is configured differs between vendors, of course. The advice in the IETF standards is to prefer valid over unknown, and valid and unknown over invalid. But it's up to you as an operator to decide if and how you want to use this information.
The decision process described above takes place in your router. Only the router gets to see the actual BGP announcements, so only the router can make this assessment.
However, to help you analyse what your router will most likely see, we have created the BGP Preview page. On this page, we mimic the announcement validation process described above using a dump of announcements that are widely (>5 peers) seen by the RIPE NCC RIS Route Collectors.
This page is mainly provided for two reasons: