The Route Origin Authorisation (ROA)

A ROA is a cryptographically signed object that states which Autonomous System (AS) is authorised to originate a certain prefix. Because a ROA is a child object of a resource certificate, only the legitimate holder of a certain IP address block can create a valid ROA for one of the prefixes they hold.

The hosted system allows you to enter a ROA specification in the web interface. Using the information in the specification, a cryptographic ROA object will automatically be generated and published.

The ROA specification can contain the following information:

• An AS Number

• One or more prefixes

• A unique name describing the ROA

• Maximum length of each prefix

• Validity start and end date

The ROA specification screen in the hosted Resource Certification service in the LIR Portal

Autonomous System Number

The AS Number in the ROA is the origin network from which the prefixes will be announced. Please note that you can enter any AS Number here. You are not restricted to an AS Number that you hold.

If you are going to originate your prefixes from other AS Numbers as well, you should create additional ROAs for each of those AS Numbers. Otherwise, these announcements will be seen as unauthorised, i.e. hijacks.

Prefixes

These can be one or more IPv4 and IPv6 prefixes. Please note that within the user interface, you can only select a prefix of which you are the holder. After dragging the prefix into the ROA specification, you can click it to edit it, for example to make it smaller. Changing it into a prefix that you do not hold will result in an error message.

Maximum Length

This is an optional field. When present, this specifies the length of the most specific IP prefix that the AS is authorised to advertise. When it is left blank, the AS is only authorised to advertise exactly the prefix specified. Any more specific announcement of the prefix will be considered RPKI INVALID. This is a way to enforce aggregation and prevent hijacking through the announcement of a more specific prefix.

Validity Start and End Date

This is an optional field. If you leave it blank, the ROA will be valid for as long as you are the holder of the resources associated with it. The start and end date of a ROA allow you to specify before and after which date a ROA should be considered invalid. This can, for example, be useful if you are transitioning from announcing a prefix from one AS to another on a certain date.

RPKI Validity of BGP Announcements

A ROA is a statement that has an effect on the RPKI validity of one or more BGP announcements. These are the three possible states that a BGP announcement can have:

• 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

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

ROA

Example 2: Announcing more specific prefixes

BGP Announcements

ROAs (Loose option)

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)

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

ROAs

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.1.0.0/20, the 10.0.0.0/16 announcement from AS64500 will have the status RPKI UNKNOWN, because the /20 partially overlaps the /16.