[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reaching out to ARIN members about their RPKI INVALID prefixes
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
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
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
> 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.
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.