Reaching out to ARIN members about their RPKI INVALID prefixes

Tue Sep 18 21:34:57 UTC 2018

On Tue, Sep 18, 2018 at 12:04:19PM -0700, Owen DeLong wrote:
> > Perhaps said another way: 
> > 
> > "How would you figure out what prefixes your bgp peer(s) should be sending you?"
> >    (in an automatable, and verifiable manner)
> 
> In theory, that’s what IRRs are for.

You may be overlooking the fact that the semantics of an IRR route
object are subtly different than those of a RPKI ROA. The Prefix-to-AS
Mapping Database concept as introduced Section 2 of RFC 6811 is a huge
step forward compared to the (somewhat loosely defined) semantics of IRR
route objects.

RPKI ROAs are more than "IRR with crypto": IRR objects are basically a
list of unverifiable attestations with no proof of termination. Whereas
when that same information is published through the RPKI, we now know
two things: (1) the owner of the resource consented to the creation of
the object and (2) any BGP UPDATE that conflicts with covering RPKI ROAs
is invalid.

In other words, RPKI and the Prefix-to-AS validation procedure give us
much more definitive inputs for routing policies compared to what can be
derived from the IRR.

I simply view RPKI as a successor to the IRR system with some much
needed improvements.

> In practice, while they offer better theoretical capabilities if
> stronger authentication were added, the current implementation and
> acceptance leaves much to be desired.

Luckily multiple projects are passing through the pipeline to reduce the
risk some IRRs represented.

https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation
https://teamarin.net/2018/07/12/the-path-forward/

Considering that RPKI and IRR will co-exist in one form or another for a
wihle it is encouraging to see success in patching loopholes.

> However, even in theory, RPKI offers nothing of particular benefit
> even in its best case of widespread implementation.

I can't really wrap my head around how you can arrive at such a
conclusion in light of all the information that has been provided to
you. So perhaps we'll have to agree to disagree.

RPKI is useful in context of a defense in depth strategy. If one
combines "peerlock" AS_PATH filters with origin validation the end
result is bullet proof. Even if NTT is the only one to deploy this
combination, the benefits are notable.

Kind regards,

Job