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
