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

RPKI Doesn't Dupport RTBHR

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.

---