Creating Resource Public Key Infrastructure - Routing Origin Authorizations to prevent outages, detours, and unauthorized use of IP addresses

Steven Wallace ssw@internet2.edu

Director - Routing Integrity, Internet2

How would you stop someone from stealing your IP addresses?

• A bad actor on the other side of the Internet steals a /24 out of your /16 to conduct a phishing attack, using it for 20 mins before releasing it.
• Perhaps not a phishing attack, but something more serious such as stealing the /24 that hosts your SSO server for a few hours.
• Or perhaps it’s just a typo - your 129.79.0.0/16 is nearly the same as 129.78.0.0/16 when configuring a new internet connection.

​

How would you prevent or detect these incidents?

[ 2 ]

90% of Internet2-connected networks are less able to than they should be to mitigate these attacks; compared to 35% of the Commodity Internet

​

“Of the 179 prefixes labeled hijacked, only three were RPKI-signed before they were blocklisted. We infer that hijackers do not usually target RPKI-signed prefixes but rather target unallocated or unrouted non-RPKI signed address spaces.”

from - https://www-cs.stanford.edu/~gakiwate/papers/imc22-drop_roa.pdf

​

[ 3 ]

We can’t afford to have an Easy Button Gap!

[ 5 ]

The “Easy Button” is powerful, so be careful!

• Creating the wrong RPKI-ROA could disrupt your internet connection.
• The quickest way to recover from creating the wrong RPKI-ROA is to create the correct one!
• Stress-free RPKI-ROA creation takes planning.
• Let’s review the planning…

[ 6 ]

RPKI-ROA Planning

General Concepts:

• The list specific ROA is the most powerful!
• The following won’t permit anything specific, regardless of its origin ASN

​

If AS87 participated in LHCONE with subnet 129.79.5.0/25, it might need two prefixes in the ROAs, or two ROAs.

Why does the order matter?

[ 7 ]

RPKI-ROA Planning

(on-demand DDoS scrubbing providers that retain origin ASN)

​

If the on-demand scrubbing provider can scrub any of your /24s, you’ll need to ensure the covering ROA is appropriate:

​

However, if scrubbing will be limited to a subset of the /24s, then create a prefix or ROA for each of the potentially scrubbed subnets.

​

[ 8 ]

RPKI-ROA Planning

(on-demand DDoS scrubbing providers that retain origin ASN)

​

If you’re stuck with needing a long ROA, then consider the following as compensating technical controls:

​

• Always announce all the more specifics.
• You may want to suppress sending more specifics for subnets currently being scrubbed.
• Have monitoring in place so you can detect a hijack

[ 9 ]

RPKI-ROA Planning

(on-demand DDoS scrubbing providers that originate routes from their ASN )

​

If the on-demand scrubbing provider may scrub any of your /24s, you’ll need to ensure the covering ROA is appropriate, with your scrubbing provider’s ASN:

​

However, if scrubbing will be limited to a subset of the /24s, then create a prefix or ROA for each of the potentially scrubbed subnets.

​

[ 10 ]

RPKI-ROA Planning

(on-demand DDoS scrubbing providers that originate routes from their ASN)

​

As I said earlier…

​

If you’re stuck with needing a long ROA, then consider the following as compensating technical controls:

​

• Always announce all the more specifics.
• You may want to suppress sending more specifics for subnets currently being scrubbed.
• Have monitoring in place so you can detect a hijack

[ 11 ]

RPKI-ROA Planning

(always-on DDoS scrubbing providers that originate your routes)

​

Good to have your basic ROA, for when you want to directly originate the route.

Create ROAs that cover the always-on DDoS announcements:

[ 12 ]

A tool to check a proposed ROA

If you’re running Docker:

​

docker run -dp 8000:8000 stevenisfine/roa_checker:latest

[ 13 ]

This tool’s user interface is brittle, sorry, will improve later. It expects a prefix in the form 10.0.0.0/16 (and it must exist as a route in the global routing table), and the ASN must not include “AS”.

​

​

[ 14 ]

The proposed ROA, below, would effectively allow the /16, but not the /17, silently turning of their DDoS scrubbing service.

​

In this example, at least two ROAs are required, and the utility won’t check for the results of more than one ROA at a time. You could test each ROA separately and aggregate the results.

[ 15 ]

Tools to investigate ROAs

Public RPKI-ROA validators:

• Cloudflare
• RIPE
• Internet2’s Route Reports

[ 16 ]

RPKI-ROAs aren’t perfect

Evildoers can hijack both the prefix and the origin ASN. It’s harder, but possible.

​

Autonomous System Provider Authorization (ASPA) improves on RPKI-ROAs, by enabling a network to assert its valid providers. It makes hijacking even harder, but isn’t perfect path protection.

​

Ultimately we’ll likely see BGPSEC as the comprehensive solution for as-path protection.

[ 17 ]

RPKI-ROA Check List

• Will a scrubbing service:
• originate a more specific?
• originate from a different ASN?
• Have you doubled checked how the prefix is seen by other networks such as stat.ripe.net
• Did did you check with the ROA checker?
• Remember, you should create more specific ROAs first

[ 18 ]