Reaching out to ARIN members about their RPKI INVALID prefixes

Tue Sep 18 21:44:30 UTC 2018

> On Sep 18, 2018, at 2:34 PM, Job Snijders <job at ntt.net> wrote:
> 
> 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

Right… Hence my call for IRRs with stronger authentication and validation.
(i.e. IRRs run by RIRs that have the same level of maintenance authentication and
authorization requirements as current RPKI implementations).

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

Yes, but, what you don’t know is whether any BGP UPDATE that contains the valid
origin ASN as origin came from the origin ASN it claims.

Instead, you provided a cryptographically signed recipe for believable spoofing.

Actually, they’re quite a bit less… They provide no path data.

ROAs are useful for one hop level validation. At the second AS hop they are 100% useless.

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

Please explain to me how you distinguish good from bad in the following scenario…

You peer with AS6939.

You receive routes for 2001:db8:f300::/48 with the following AS Paths

	1. 6939 1239 54049 2312 1734
	2. 6939 44046 12049 174 1734

Which one is valid? Which one is not? How did the ROA tell you this?

With the IRR, I can (theoretically) compare an AS Path to the valid set of path
associations documented in RPSL. (modulo lack of participation/implementation,
which RPKI likewise suffers from). With RPKI, I can’t tell anything.

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

Your view is, IMHO, very distorted.

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

Yep… Properly implemented and adopted, IRRs show some progress for actual path
validation abilities, including origin.

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

See above. What is it you believe RPKI offers beyond 1 hop that is anything more than
a cryptographically signed recipe for believable spoofing?

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

Indeed, if peerlock gets wider deployment, it might prove useful. But unless I’m
really misunderstanding peerlock, I don’t see that RPKI brings much else to
the table in addition.

Owen