service information

RPKI at the DE-CIX route servers

In 2019, DE-CIX deployed RPKI at the DE-CIX route servers in order to increase the security of the Internet routing system and support the adoption of RPKI. The adoption was essential to Internet security, and the benefits were visible from day one for all peers and their customers.

As the combination of RPKI and Blackholing can increase the operational burden, three implementation options were discussed. Option 3 was selected: Strict RPKI origin validation filtering for non-blackholes and loose RPKI origin validation filtering on blackholes. 

In the following, you will find some basic information about RPKI and its deployment at DE-CIX. RPKI was implemented at all DE-CIX exchanges except for our exchanges in India, and the exchanges in Berlin, Moscow and St. Petersburg.

If you have any questions, please do not hesitate to contact us.

General RPKI FAQs

  • RPKI means Resource Public Key Infrastructure. It can be used to support secure Internet routing, especially to prevent route hijacking and other attacks.

    More information can be found in RFC 6480 or at RIPE. A very good community-driven FAQ about RPKI is available here.

  • RPKI is useful to prove that a given IP prefix is really yours. For that, you get a certificate which is signed by the entity that asigns you that prefix  (RIPE, ARIN, or your regional Internet registry). With this signed certificate, you can prove to a third party like DE-CIX that a prefix is really yours and that you legitimately announce it to our route servers.

  • ROA means Route Origin Authorization. An ROA connects a prefix and an originating Autonomous System. It also states if the prefix must be announced as a whole or if sub-announcements are allowed. For example:

    Origin AS: 64496
    Prefixes: 
    192.0.2.0/24 (max length /24)
    198.51.100.0/24 (max length /24)
    203.0.113.0/24 (max length /32)

  • RPKI validation means that a validator (a piece of software) checks existing ROAs. A router (e.g. the DE-CIX route servers) queries this validator, and as a result, three values are possible:

    Valid: There is an ROA and it covers the BGP announcement (originator AS, prefix, and prefix length are covered by an ROA). This is the best case.

    Invalid: There is an ROA for this prefix, but either for a different originator AS or the prefix length does not match. These prefixes will be filtered out by DE-CIX route servers.

    NotFound/Unknown: There is no ROA for this prefix. DE-CIX route servers will distribute them if they can be successfully verified against IRRDB data.

  • Please note: This example is based on the RIPE region. Other RIRs provide similar tools.

    To create ROAs, please have a look at the RPKI Dashboard in the LIR Portal. RIPE will show you prefixes that originate from your ASN(s) with the help of their route collectors. You just have to select the prefix you want to create a ROA for.

    If your announcement is currently not found in BGP, use the Route Origin Authorisations (ROAs) tab and create the ROA manually.

    More on RPKI at other RIRs:

    AFRINIC
    APNIC
    ARIN
    LACNIC

RPKI deployment at DE-CIX FAQs

  • No. We want to provide a high level of basic routing security on the DE-CIX route servers.

  • No. However, if you have RPKI ROAs configured then your announcements of prefixes must be covered by these ROAs. If these announcements of prefixes are not covered by your ROAs, the DE-CIX route servers will filter out these prefixes; this means, the DE-CIX route servers will not re-distribute those prefixes to other DE-CIX peers.

  • Then the RPKI validation status is NotFound/Unkown, and the DE-CIX route servers will accept your prefix only if the IRRDB fallback check succeeds.

  • With the addition of RPKI validation to our IRRDB filters, an incoming route is validated as follows*:

    1) The origin ASN needs to be in the customer cone (IRRDB filter 1/2)

    2) Is the route a blackhole?

    • If not, the route undergoes strict RPKI validation filtering (both origin and maxLength):
      f the result is RPKI Valid, the route is accepted
      If the result is RPKI Invalid, the route is rejected
      If the result is RPKI NotFound/Unknown, the route is checked against IRRDB filter 2/2 and might get accepted or rejected depending on the result
    •  
    • If it is, the route undergoes "loose" RPKI validation filtering (origin only):
      If the result is RPKI Valid, the route is accepted
      If the result is RPKI Invalid, the route is rejected
      If the result is RPKI NotFound/Unknown, the route is checked against IRRDB filter 2/2 and might get accepted or rejected depending on the result

    *Please see the diagram at the bottom of the page for more information. Please note: The diagram does not contain basic route hygiene, e.g. rejecting bogons.

  • We only perform loose RPKI validation on blackholes. That means that we honor the origin ASN attribute of the ROA but ignore the maxLength attribute. We will allow a maxLength value of /32 for IPv4 and /128 for IPv6. For conventional routes, both ROA attributes are honored.

  • Yes, you can see both in the DE-CIX Looking Glass. Search for your prefixes in the global search, and you will get all routes (accepted and filtered).

    There is also a little icon to the left of the route indicating the validation status:

    • Green: RPKI Valid (route got accepted)
    • Blue: RPKI NotFound/Unknown (route got accepted because IRRDB fallback succeeded)
    • Red: RPKI Invalid (route got rejected)
RPKI validation at the DE-CIX route servers
How does DE-CIX implement RPKI validation at the DE-CIX route servers? *Each entry in this table will have the max. applicable length available applied (e.g. /32 for IPv4)