Managing ROAs

Introduction

1. Certified Resources

2. Route Origin Authorisations (ROAs)

3. BGP Route Validity

4. Creating and Editing ROAs

5. Verifying the Effect of ROAs on your BGP Announcements

6. Alerts

ROA Examples

 

Introduction

The hosted Resource Certification (RPKI) service in the LIR Portal 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 product tour in the ROA Management interface. Each step of the tour has links to the detailed information below.

To get started, open the Resource Certification (RPKI) service in the LIR Portal.

1. Certified Resources


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. 

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:

  1. The AS Number that is authorised
  2. The prefix that may be originated from the AS
  3. 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:
      1. There is a ROA for this prefix for another AS, but no ROA authorising this AS; or
      2. This could be a hijacking attempt
    • The announcement is more specific than is allowed by the maximum length set in a ROA that matches the prefix
  • 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 "Suggest ROAs" 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. You can add ROAs one by one, or add and clone them so you don't have to enter items again that stay identical, such as the AS Number of the prefix.

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.

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 this overview:

Route Validity Preview

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 Changes". Within a few minutes, all ROAs are automatically published in a repository hosted by the RIPE NCC.

6. Alerts

AlertsThe 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.

An orange badge with the number of announcements that require your attention will be displayed in the left-hand menu. In addition, 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 tick the box next to the route and click the "Suppress Alerts" button. You won't be warned about the validity state anymore. You can undo this by ticking the box next to the routes that have suppressed alerts and clicking "Enable Alert".

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.