[RPKI-Discuss] [Community-Discuss] 06 April 2019 RPKI incident - Postmortem report

Alex Band alex at nlnetlabs.nl
Thu Apr 11 13:48:26 UTC 2019


Hi Ben,

> On 11 Apr 2019, at 13:31, Ben Maddison <benm at workonline.africa> wrote:
> 
> Hi Alex,
>  
>  
>> On 2019-04-10 21:02:41+02:00 Alex Band wrote:
>> 
>> This is most certainly a corner case, but is at least theoretically possible given that all RIRs claim 0/0 in their root certs.
>> 
>> Corner case or not, in my opinion it’s a very slippery slope to use such an example. 
>> 
>> The RIRs have put in proper measures to make sure such a scenario doesn’t occur. For example, precisely for this reason the RIPE NCC have a more constrained “RIPE NCC Managed Resources” intermediate certificate in place, from which all Member Certificates are derived.
> 
> I'm not a fan of the default claims in the RIR root certs, and I'm not a fan of OOB workarounds that can't be verified cryptographically.

Me neither and it didn’t used to be this way, but it is what it is.

> My understanding is that this practise is in order to avoid re-issuing the root as the result of a transfer, but given that the cert which a TAL points at can change (as long as the keypair is the same) without touching the TAL, I've never understood why this workaround was necessary.

Actually, the full reason is documented here:

https://www.nro.net/regional-internet-registries-are-preparing-to-deploy-all-resources-rpki-service/
https://www.ietf.org/archive/id/draft-rir-rpki-allres-ta-app-statement-01.txt

> If you agree with the practise, I'm open to persuasion.

I think the RIRs are in a better position to do this, because I’m not entirely sure how each RIR operates their RPKI infrastructure. I know the RIPE NCC implementation a little better than the others of course; this is why I know they put a lot of weight behind getting the “RIPE NCC Managed Resources” intermediate certificate implemented in their infrastructure, precisely to put in these safeguards.  This is what triggered my response. 

For the other RIRs I’m not sure. Best I can find for APNIC is this blog post:

https://blog.apnic.net/2017/08/14/transitioning-single-rpki-trust-anchor/

> If we're going to be stuck with disjoint per-RIR RPKIs forever, we (RPs) should at least be able to verify that they are disjoint!

I agree some transparency in this regards would be good, and becomes more relevant now that RPKI is being used operationally in all regions.

Cheers,

Alex


More information about the RPKI-Discuss mailing list