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-implem... 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