Skip to main content

Using the Hosted Certification Authority

Introduction

The Hosted RPKI Certification Authority (CA) service allows you to authorise all legitimate BGP announcements made using your address space through an intuitive web interface.

1. Create a Certification Authority

To get started, log in to the Resource Certification (RPKI) dashboard. You will need to log in using your RIPE NCC Account that is associated with one or more RIPE NCC members (LIRs). 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.

Note that, if your RIPE NCC Access account is associated with more than one member or PI or legacy holding organisation, then you can switch between them using the drop-down menu on the top right of the page.

If you have not yet created your CA, then you will need to do so before you can start managing your ROAs. You have a choice between creating a “Hosted” or “Delegated” CA. On this page, we describe how to use the Hosted Certification Authority. If you choose to run a Delegated CA instead, then please consult the documentation of your CA software.

2. Overview Page

If you have an active Hosted CA, then you will land on the Overview page where you will see the following sections:

  • BGP Announcements and Route Origin Authorizations (ROAs)
  • Alert Configuration
  • History
  • Certified Resources
  • Hosted Certification Authority

BGP Announcements and Route Origin Authorizations (ROAs)

A Route Origin Authorization (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.

ROA Objects and ROA Configurations

An RFC 9582 ROA object is a signed RPKI Object that authorises an Origin AS Number to make announcements for one or more prefixes, that can each have an optional max length field to allow more specific prefixes. All prefixes on the ROA object need to be held by the CA that signs it, but the origin AS does not need to be held by that CA. This is useful because it allows a holder of an IP prefix to authorise a third party as their BGP provider.

So, in summary, ROA *objects* can only contain one AS and multiple prefixes. But, the hosted CA service provided by the RIPE NCC uses an abstraction of this and lets users manage ROA *configurations* instead that each has:

  • One Origin AS
  • One IPv4 or IPv6 prefix
  • One maximum length

Where the maximum length is by default equal to the prefix length (in which case it will not be encoded on the ROA object).

The hosted system is then responsible for signing, publishing and renewing ROA objects based on this information. This means that as a user of the hosted CA system, you do not need to worry about managing these objects directly. For instance, ROA objects can expire, but the system will renew them well ahead of time based on the configurations.

Route Origin Validation (ROV)

ROAs and other RPKI files are downloaded by RPKI validation software, often referred to as Relying Party (RP) software, that performs cryptographic validation and makes the ROA content, often referred to as Validated ROA Payloads (VRPs), available to routers that implement Route Origin Validation (ROV).

For ROV each BGP announcement is evaluated against all known VRPs that *cover* the BGP announcement prefix, i.e. the VRP prefix matches the announcement prefix exactly, or it is less specific. The resulting ROV state is then determined as follows:

  • Not Found
    There are no VRPs that cover the announcement.
  • Valid
    The route announcement is authorised by at least one VRP.

    A covering VRP authorises an announcement if the ASN and prefix are both authorised. The optional 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.

    The use of the Maximum Length field is discouraged. This is a way to prevent hijacking through the announcement of a more specific prefix.
  • Invalid
    The route announcement is covered by at least one VRP, but it is not authorised by any VRP.

Note that multiple VRPs may cover an announcement, particularly if a prefix is announced from multiple ASNs. In that case, a VRP should be created for each origin ASN for that prefix ensuring that there is at least one VRP that authorises that announcement. Announcements for the prefix for any other ASN are still considered invalid because they are covered by these VRPs, but not authorised by any of them.

Create ROAs for Known Announcements

The easiest way to create ROAs for existing known announcements is by using the “Create ROA” button on the announcements tab. This will create a ROA that matches your announcement exactly, meaning that the Max Length will use the recommended default and be equal to the prefix length and therefore be omitted from the actual signed ROA object.

Note that you can also select multiple announcements to create multiple ROAs in one operation.

Create or Edit ROAs Manually

ROAs can also be created or edited manually in the “ROAs” tab. This is particularly useful in case you need to create a ROA for an announcement that is planned for the future, but which is not (yet) seen in BGP by the RIPE RIS Route Collectors.

This way you can also choose a Max Length that is longer than the prefix length. This will authorise more specific prefixes, up to the specified length, to be announced by the Origin AS. This may be useful in case you need to pre-provision e.g. a /24 that could be announced towards an anti-DDoS service provider.

But, as explained in RFC 9319, the use of max length is considered harmful in case you don’t also announce each most specific prefix thus allowed, because otherwise, your covering prefix is vulnerable to hijacking through the announcement of such a prefix in combination with address spoofing.

Apply Now or Pending Changes

When you create a ROA, especially if you create it by hand, then it may be that its creation would result in one or more of your known BGP announcements becoming invalid.

If you choose to apply this change, then you will see the following pop-up where you will need to confirm that this is intentional.

Alternatively, you can also add the ROA to “Pending Changes” in which case you can continue to make more changes that can be published in one atomic operation. This is especially useful in cases where you need multiple ROAs for a single prefix, e.g. because they are announced from multiple ASNs. Continuing with our example ROA we would see that a pending ROA was added that affects one announcement.

By clicking the, in this case, red number under the affected announcements column we can see in detail how known announcements are going to be affected. A “Create ROA” button is shown for announcements that are, or will become ROV invalid. This button can be used to add a pending ROA that matches the announcement. But of course, it is also possible to create more pending ROAs manually.

All pending ROAs can be reviewed and edited on the Pending Changes tab, and can then all be applied as a set. Note that if you have any pending ROAs you cannot apply any new ROA individually. But of course, you can discard all changes and just apply a single ROA if that would be desired.

3. Alert Configuration

You can configure one or more email addresses to receive alerts about BGP announcements with your address space that are ROV “invalid” or optionally “not found”. Emails can be sent daily or weekly.

Under the “Current Alerts” tab you will find all current known alerts and you have the option to mute or re-enable notifications for specific announcements.

4. History

The overview page shows the latest change that happened in your CA. By clicking on this section you will be taken to a searchable overview of your CA’s history.

5. Certified Resources

The overview page shows the address space on your resource certificate.

Your resource certificate is automatically updated when your resources change, e.g. because new resources are allocated to you, or if resources are transferred into or out of your organisation, or if resources are returned.

If resources are removed for which you have current ROA configurations then your published ROAs will be updated automatically.

6. Hosted Certification Authority

In this section, you can “revoke” your Hosted Certification Authority. This action will delete and remove your CA entirely, including all its ROA configurations and history.

You need to use this option in case you want to migrate to running a Delegated instead of a Hosted Certification Authority. Note that it’s currently not possible to do a “make-before-break” migration, so you will need to revoke your current CA first before reactivating it.