Managing ROAs
Introduction
The hosted Resource Certification (RPKI) service allows you authorise all legitimate BGP announcements that are made with your address space in an intuitive web interface. In order to help you get familiar with the workflow, we have created a quick video tour:
1. Certified Resources
To get started, open the Resource Certification (RPKI) service (requires authentication). The resource certification dashboard displays an overview of all eligible address space on your resource certificate. If new resources are allocated to you, your certificate is automatically updated. Also, if you return resources to the RIPE NCC, a new, updated certificate is automatically published.
All address space is eligible for certification. If you are not a RIPE NCC member, but the holder of Provider Independent (PI) or Legacy resources, please follow this guide to get started.
In case an Internet number resource is moved or transferred (for example if an End User becomes an LIR or due to a transfer), the organisation object listed in the RIPE Database will change, therefore the certificate will change.
This means that the underlying ROAs will be removed and must be re-created.
2. Route Origin Authorisations (ROAs)
A Route Origin Authorisation (ROA) is a cryptographically signed object that states which Autonomous System (AS) is authorised to originate a certain prefix. This means ROAs say something about the BGP announcements that are done with your address space.
A ROA contains three informational elements:
- The AS Number that is authorised
- The prefix that may be originated from the AS
- The Maximum Length of the prefix
Maximum Length specifies the length of the most specific IP prefix that the AS is authorised to advertise. When it is not set, the AS is only authorised to advertise exactly the prefix specified. Any more specific announcement of the prefix will be considered unauthorised. This is a way to enforce aggregation and prevent hijacking through the announcement of a more specific prefix.
Read more about creating and editing ROAs.
3. BGP Route Validity
The dashboard displays an overview of all BGP announcements that are done with your certified address space, as seen by the RIPE NCC Route Collectors.
The routes that our Route Collectors see may differ from what your routers see, so please use this overview as a guideline only. In addition, please take the following into account when using this information:
- We only display announcements that are seen by more than five peers.
- Data can be up to nine hours old, so recent changes might not be reflected.
- We display less specific announcements that overlap with the certified address space that you do not announce to make you aware of hijacks of your unannounced address space; however,
- Any less specific announcement of your unannounced address space that is larger than a /8 IPv4 or /12 IPv6 is filtered out.
For each BGP announcement, the RPKI validity state is indicated. They can be one of the following:
- VALID
- This route announcement is covered by at least one ROA
- INVALID
- The prefix is announced from an unauthorised AS. This means:
- There is a ROA for this prefix for another AS, but no ROA authorising this AS; or
- This could be a hijacking attempt
- The prefix is announced from an unauthorised AS. This means:
- UNKNOWN
- The prefix in this announcement is not covered (or only partially covered) by an existing ROA
Suggest ROAs
The resource certification system has the ability to suggest ROAs for the BGP announcements that have the state "Unknown" or "Invalid". Tick the boxes next to the routes you would like to authorise and click the "Create ROAs for selected BGP Announcements" button. The ROAs that the system will suggest will be the most conservative possible, and they will only authorise exactly the announcements you have selected. If you would like to have more flexibility or a looser authorisation, please create a ROA manually, as described in the next section.
4. Creating and Editing ROAs
To create a ROA, enter the AS Number that you authorise, the prefix that is being originated from it and, lastly, the Maximum Length, which determines the most specific prefix that the AS may originate out of the aggregate.
There are several ways to authorise a BGP origin with a ROA. For example, you can authorise the entire aggregate to be originated – including all more specific announcements – with a single ROA. Or you can authorise each announcement with a ROA individually. The benefits and downsides of each approach are explained in the examples below. We have also created a short video to explain the correct usage of Maximum Length.
Keep in mind that a single ROA can make the announcement of a prefix from an authorised AS valid, but at the same time, it makes the announcement from an unauthorised (hijacking) AS invalid. You should create as many ROAs as needed to make all legitimate announcements valid.
Once you have specified a new ROA or deleted an existing one, your changes are not immediately published. You will first have a chance to review the effect of your changes on the BGP announcements that are done with your address space. Once you are satisfied with the result, you can click "Publish Changes" to save and publish the set you have created or edited.
In case you no longer hold a prefix, because of a transfer or a closure of your LIR account, we will remove the associated ROA.
5. Verifying the Effect of ROAs on your BGP Announcements
As you are adding or editing ROA specifications, you can see the effect on the validity of your BGP announcements in the "Review and publish changes" section:
During this process you can keep adding ROAs manually, or you can ask the system to suggest a ROA for you. Once all of the BGP announcements that you authorise are Valid, you can click "Publish!". Within a few minutes, all ROAs are automatically published in a repository hosted by the RIPE NCC.
6. Alerts
The Resource Certification system has the ability to alert you when one of the BGP announcements with your address space has the status Unknown or Invalid. You can configure an email address where an overview of your alerts is sent to you once every 24 hours.
Alerts will be triggered in the following cases:
- Invalid: An unauthorised AS originates one of your prefixes
- Unknown: Announcements are made with your prefixes that are not matched by a ROA
This means that when an AS starts originating a new BGP announcement with your address space that causes it to be Unknown or Invalid, you will be notified to take action. If you would like to ignore certain alerts, you can mute them by clicking the bell icon next to the BGP announcement. You won't be warned about the validity state anymore.
ROA Examples
In all examples, you are the holder of 10.0.0.0/16. The goal of each example is to make the BGP announcements get the status RPKI VALID.
Example 1: Announcing the Entire Aggregate
BGP Announcement
Origin AS | Prefix |
---|---|
AS64500 |
10.0.0.0/16 |
ROA
AS Number | Prefix | Maximum Length |
---|---|---|
AS64500 |
10.0.0.0/16 |
16 |
Example 2: Announcing More Specific Prefixes
BGP Announcements
Origin AS | Prefix |
---|---|
AS64500 |
10.0.10.0/22 |
AS64500 |
10.0.20.0/24 |
ROAs (Loose Option)
AS Number | Prefix | Maximum Length |
---|---|---|
AS64500 |
10.0.0.0/16 |
24 |
The advantage of creating a ROA that authorises the entire aggregate is that it requires no changes when additional announcements from the address block are made from the same ASN. The disadvantage is that it opens you up to a certain type of hijack: when an attacker spoofs AS64500 and starts originating 10.0.30.0/24 (which you don't announce), it will be seen as an RPKI VALID announcement. You can prevent this by creating the following ROAs:
ROAs (Strict Option)
AS Number | Prefix | Maximum Length |
---|---|---|
AS64500 |
10.0.10.0/22 |
22 |
AS64500 |
10.0.20.0/24 |
24 |
The result is that any other announcement – from the real AS, or a spoofed one by an attacker – will be seen as RPKI INVALID. The disadvantage is that every time you want to start announcing another prefix out of the aggregate, additional ROAs need to be created.
Example 3: Announcing from Multiple ASNs
BGP Announcements
Origin AS | Prefix |
---|---|
AS64500 |
10.0.0.0/16 |
AS64511 |
10.0.16.0/20 |
ROAs
AS Number | Prefix | Maximum Length |
---|---|---|
AS64500 |
10.0.0.0/16 |
16 |
AS64511 |
10.0.16.0/20 |
20 |
In this example, you must create a ROA for both BGP announcements to make them RPKI VALID.
If you do not create a ROA to authorise AS64511, the announcement will be RPKI INVALID. This is because the /20 prefix is completely covered by the /16 aggregate, and it is announced from an unauthorised ASN.
Conversely, If you only create a ROA that authorises AS64511 to originate 10.0.16.0/20, the 10.0.0.0/16 announcement from AS64500 will have the status RPKI UNKNOWN, because the /20 partially overlaps the /16.