Skip to content
This repository has been archived by the owner on Feb 9, 2022. It is now read-only.

RPKI deployment options

Jump to bottom
Johannes Moos edited this page Feb 19, 2019 · 3 revisions

Objective

DE-CIX wants to provide RPKI origin validation filtering at the route server while making sure

  • Blackholing is still working (and also benefits from the additional security that RPKI provides)
  • not being affected to ROA maxLength vulnerabilities

Option 1 - Strict RPKI Origin Validation Filtering incl. Blackholes

Perform strict RPKI origin validation filtering, i.e. treat "RPKI invalid == reject" as such and implement no exception for blackholes. In case a customer wants to use blackholing and issues a ROA, especially a "minimal" ROA, for its IP space, this will require additional customer interaction: As BGP security practices (see RFC7454) prohibits the redistribution of > /24 for IPv4 and > /48 for IPv6 prefixes (e.g. see https://stat.ripe.net/specials/registered-ipv4-prefix-size-distribution), and blackholes typically are > /24 for IPv4 (> 97% of blackholes observed at DE-CIX are > /24, see https://www.net.t-labs.tu-berlin.de/papers/DFK-BIXPO-16.pdf) the customer needs to create the following ROAs:

  • A "minimal" ROA for the IP space
  • One or more "loose" ROAs to cover >/24 blackholes

Example

Let's assume the customer IP space is 46.31.120.0/23. The following ROAs would need to be created:

  • 46.31.120.0/23 max /23 (a "minimal" ROA)
  • 46.31.120.0/25 max /32 (a "loose" ROA)
  • 46.31.120.128/25 max /32 (a "loose" ROA)
  • 46.31.121.0/25 max /32 (a "loose" ROA)
  • 46.31.121.128/25 max /32 (a "loose" ROA)

To be clear, this is based on the assumption that good Internet citizens will not allow/route > /24 for IPv4 and > /48 for IPv6 anyway. Additionally, DE-CIX is currently considering to not accept blackholes < /25 for IPv4 and < /49 for IPv6 anymore.

Filtering at the Route Server

Filtering at the route server is executed like this:

RPKI origin validation will take place in between the two stages of our already in place IRRDB filtering.

First, the membership of the origin ASN in the customer cone is checked. Second, RPKI origin validation is performed only for routes that pass step 1. Third, the IRRDB prefix check will serve as a fallback if a route is validated as RPKI NotFound.

The filtering flow looks like this:

Option 2 - No RPKI Origin Validation Filtering for Blackholes

Perform strict RPKI origin validation filtering only for non-blackholes. This will require no additional customer interaction if a customer wants to use blackholing, regardless of if the customer issues a ROA or not.

The drawback is that blackholes are not secured by RPKI origin validation filtering.

Filtering at the Route Server

Filtering at the route server is executed like this:

  • Origin ASN needs to be in customer cone (IRRDB filter 1/2)
  • All routes which are not blackholes undergo RPKI validation (route origin/maxLength):
    • if the result RPKI Valid, the route is accepted
    • if the result is RPKI Invalid, the route is rejected
    • if the result is RPKI NotFound, the route is checked against IRRDB filter 2/2 and might get accepted or rejected depending on the result
  • For blackholes: Fall back to IRRDB validation

The filtering flow looks like this:

Option 3 - Strict RPKI Origin Validation Filtering for Non-Blackholes and Loose RPKI Origin Validation Filtering on Blackholes

Perform strict RPKI origin validation filtering on non-blackholes and loose RPKI origin validation filtering on blackhole. Loose RPKI validation filtering means the origin attribute of the ROA is honored while the maxLength attribute is ignored. This will require no additional customer interaction if a customer wants to use blackholing, regardless of if the customer issues a ROA or not.

The drawback is that blackholes are vulnerable to MaxLength attacks (see https://labs.ripe.net/Members/gih/an-update-on-securing-bgp).

Filtering at the Route Server

Filtering at the route server is executed like this:

  • Origin ASN needs to be in customer cone (IRRDB filter 1/2)
  • Is the route a blackhole?
    • If no, the route undergoes strict RPKI validation filtering (both origin and maxLength):
      • 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, the route is checked against IRRDB filter 2/2 and might get accepted or rejected depending on the result
    • If yes, the route undergoes loose RPKI validation filtering (origin only):
      • if the result RPKI Valid, the route is accepted
      • if the result is RPKI Invalid, the route is rejected
      • if the result is RPKI NotFound, the route is checked against IRRDB filter 2/2 and might get accepted or rejected depending on the result

The filtering flow looks like this:

Related Documentation

Clone this wiki locally