RPKI Recap

RFC Recap

ROA Scope
https://www.rfc-editor.org/rfc/rfc6482
There is only one ASN per ROA, even though that ROA may contain multiple prefixes. If additional ASNs are allowed to announce the same prefix(es), additional ROAs are required for each ASN.

ROAs for a more specific prefix with a different origin ASN are valid ROAs.

Validation state - order of preference
https://www.rfc-editor.org/rfc/rfc6483#section-2

In an environment of a collection of valid ROAs, a route's validity
state is considered to be "valid" if any ROA provides a "valid"
outcome. It's validity state is considered to be "invalid" if one
(or more) ROAs provide an "invalid" outcome and no ROAs provide a
"valid" outcome. Its validity state is considered to be "unknown"
(or, synonymously, "not found" [BGP-PFX]) when no valid ROA can
produce either a "valid" or an "invalid" validity state outcome.

Validation order of preference
https://www.rfc-editor.org/rfc/rfc6483#section-3

"valid" is to be preferred over
"unknown", which is to be preferred over
"invalid".

AS0 reserved as explicit "invalid" with lowest preference
https://www.rfc-editor.org/rfc/rfc6483#section-4

The route validation procedure, described in Section 2, will provide
a "valid" outcome if any ROA matches the address prefix and origin
AS, even if other valid ROAs would provide an "invalid" validation
outcome if used in isolation. Consequently, an AS 0 ROA has a lower
relative preference than any other ROA that has a routable AS as its
subject. This allows a prefix holder to use an AS 0 ROA to declare a
default condition that any route that is equal to or more specific
than the prefix to be considered "invalid", while also allowing other
concurrently issued ROAs to describe valid origination authorizations
for more specific prefixes.

Related to RFC6811
https://www.rfc-editor.org/rfc/rfc6811#section-2

We observe that no VRP can have the value "NONE" as its VRP ASN.
Thus, a Route whose Origin ASN is "NONE" cannot be Matched by any
VRP. Similarly, no valid Route can have an Origin ASN of zero [AS0].
Thus, no Route can be Matched by a VRP whose ASN is zero.

RPKI distribution protocols
https://www.rfc-editor.org/rfc/rfc6810#section-3

Global RPKI databases to caches -> rsync or RPKI RRDP (Repository Delta Protocol, which uses HTTPS)
Caches to routes -> RPKI to Router Protocol A.K.A "RTR Protocol"

Security hierarchy
https://www.rfc-editor.org/rfc/rfc6810#section-11

Transport Security: The RPKI relies on object, not server or
transport, trust. That is, the IANA root trust anchor is
distributed to all caches through some out-of-band means, and can
then be used by each cache to validate certificates and ROAs all
the way down the tree. The inter-cache relationships are based on
this object security model; hence, the inter-cache transport can
be lightly protected.

But, this protocol document assumes that the routers cannot do the
validation cryptography. Hence, the last link, from cache to
router, is secured by server authentication and transport-level
security. This is dangerous, as server authentication and
transport have very different threat models than object security.

So, the strength of the trust relationship and the transport
between the router(s) and the cache(s) are critical. You're
betting your routing on this.

 

Problems with RPKI

State Explosion

The major of network are a single ASN and originate all their prefixes from a single ASN. But one needs to create a ROA for every prefix even thought they all have the same origin. Why don't ROAs contain a list of prefixes which share the same origin. Then for most networks only one ROA is needed. This isn't massively reducing state. But if I have some prefixes which are announced by multiple ASNs I could also create a ROA with a list of prefixes and a list of origins. For any given set of prefixes, if they have the exact same set of origins, why can't that be a single ROA?

 

RPKI Doesn't Support RTBH

Non-RTBH routes are checked for RPKI validity. If they are invalid, they are dropped. Operators can't perform RPKI against RTBH host routes though because people aren't creating ROAs for host routes (/32s & /128s, I'm not even sure if you can?) and also because some people create ROAs for the exact prefix size like a /24, and not for /24 or-longer. The opportunity for abuse is that an evil customer could announce to an operator a RTBH route for IP space they are not allowed to originate, and the operator must skip the RPKI check because there aren't ROAs for host routes.

An evil customer can already announce IP space they aren't allowed to (without using RTBH community), if they add ASNs to their AS-SET and there is no ROA for the IP space under the newly added ASN. When operators support a RTBH community, an evil customer can announce space for which there is a valid ROA because the operator ignores RPKI validity for RTBH announcements. This means they can announce blackhole routes for any IP space they want, by adding it to their AS-SET.

 

Hijacking Unannounced Space

If there is a prefix which belongs to a certain ASN but they don't announce it publicly on the internet, they can sign the space with an origin of AS0. AS0 is not allowed in the public DFZ, and announcement of the IP space from any other ASN will fail RPKI validation. This prevents hijacks of space which is not announced by the owning ASN. However, the space can still be hijacked if a larger announcement is made, which covers the original IP space, and for which there is no ROA. E.g., 192.168.0.0/24 has a ROA with origin AS0. A hijacker can announce 192.168.0.0/23 in order to hijack that space as long as there is no ROA for the /23.

 

ROA Validation Fails Open

People will sign what they can, meaning what is good / valid. They won't sign what they can't, meaning what is bad / they shouldn't.

So we're left with valid stuff being signed, meaning we know what is good. But we have no signals for what is bad. So stuff that is not signed, we have no way to know if it's bad or not, instead we just have to class it as "unknown". This means we still have to accept it. This makes signing stuff somewhat redundant because we'll never get to a point of 100% ROA coverage which would allows us to reject "unknown". So unlike IRR based filter lists, which fail closed when filtering routing advertisements, ROA based filtering has to fail open.

So, if not signing doesn't stop us from accepting something, what does it stop? Virtually all applications use TLS so hijacking IPs is almost pointless these days (ROA invalid). Route leaks or path hijacks (ASPA invalid) traffic doesn't reach the intended destination and would be TLS invalid, is just a denial of service at best?

 

---