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

Wed Apr 10 19:39:04 UTC 2019

> On Apr 10, 2019, at 7:00 AM, Ben Maddison <benm at workonline.africa> wrote:
> 
> Hi Owen,
>  
> On 2019-04-10 15:00:28+02:00 Owen DeLong wrote:
> 
>  
>> 
>> On Apr 10, 2019, at 3:57 AM, Ben Maddison via Community-Discuss <community-discuss at afrinic.net <mailto:community-discuss at afrinic.net>> wrote:
>>  
>> Hi all,
>>  
>> On 2019-04-10 12:10:22+02:00 Noah wrote:
>> 
>> +1 and Ack @saul
>>  
>> On Wed, 10 Apr 2019, 12:57 Saul Stein, <saul at enetworks.co.za <mailto:saul at enetworks.co.za>> wrote:
>> Agreed.
>> 
>>  
>> There is a bigger issue at stake here: I have yet to see any evidence that AFRINIC takes RPKI seriously.
>> 
>> 
>> Until relatively recently, this attitude may have been understandable, since the RPKI was largely a curiosity with almost no impact on operations.
>> This is no longer the case, and all of the RIRs have serious work to do to improve operations in this area. This is clearly the case in this region.
> Absent a badly flawed implementation, there’s no serious consequence to an RPKI outage… It merely reverts routing back to it’s previous unauthenticated state.
> 
> That's not entirely true. A partial outage (where for example a single TAL becomes unverifiable, as in this case) may lead to a missing ROA for a prefix that remains covered by other ROAs issued under other TALs.
> 
> Consider ROAs:
> {prefix: 2001:db8::/32, maxLength: 48, asn: 65000, tal: AFRINIC}
> {prefix: 2001:db8:f00::/48, maxLength: 48, asn: 65001, tal: RIPE}
> 
> With the above, a route 2001:db8:f00::/48 via 65000_65001 will have a status Valid.
> If the RIPE TAL fails verification, it will become Invalid.

If I understand it correctly, however, ALL of the RIRs mirror all of the other RIRs data, so you should be able to get a complete set of data from any RIR. The TAL is very long term cacheable (at least 30 days).

What happened in this instance wasn’t an issue of the TAL becoming unavailable, but the TAL (and related certificates) going past their expiration date without being renewed.

Further, absent inter-RIR IPv6 transfers (which to the best of my knowledge are only permitted from RIPE to RIPE), that circumstance cannot occur.

> This is most certainly a corner case, but is at least theoretically possible given that all RIRs claim 0/0 in their root certs.

Only if Inter-RIR IPv6 transfers are permitted. So, this is, in fact, a valid argument against a current ARIN proposal to allow such transfers, but in the current instance, it’s not actually a concern.

> A more likely scenario is that an existing mis-origination that is being dropped as Invalid suddenly becomes Not Found, and wins path selection, thereby misdirecting traffic.

I did mention that as a possible consequence below.

> I'm not aware of any such cases on our network from this last outage, but it's possible that they went undetected. The likelihood of this case increases substantially as more operators begin to drop Invalids.

My point earlier was that it actually shouldn’t. If there is growth in the number of rejected routes from RPKI, that indicates that
operators aren’t doing their due diligence when that happens. A route should only be dropped by RPKI for a very short period
of time while the originating ASN and/or upstreams of the originating ASN are contacted to cease and desist the announcement
of this route.

> I’m not convinced that all of the RIRs have serious work to do here. I think some of the RIRs have stable, reliable operations in this regard. I’m not yet convinced that the level of stability in AfriNIC operations here is impactful, let alone seriously impactful to operations.
>  
>> 
>> The last issue I had, when no ROAs could be added, deleted etc, it was admitted that the issue was known about for over two weeks without anything on the announce list or being fixed! After escalation to the CEO and others it was fixed in a couple of hours!
>> 
>> 
>> As an operator community, we need to have a serious conversation about what we expect from afrinic (and the other RIRs). 24x7 availability comes with a price tag, as everyone on this list should be all too aware.
> Any availability comes with a price tag. The higher the level of availability, the higher the price tag.
>  
>> 
>> It is quite clear however, both from recent experience and from the postmortem below, that the current system is unfit for purpose.
> Is it? I’m unconvinced at this time…
> 
> A system, whether human or computerised, that fails to mitigate an impending and predictable failure, and then takes several hours to correct it is, in my book the very definition of unfit for purpose.

Not necessarily. It is certainly the definition of a system which can be improved and which has flaws in its inherent design.

>> RPKI is serious and needs to be taken seriously. We can’t continuously be having issues with it. It  is like customs at immigration being offline!
>> 
> RPKI is operational. I’m not sure how serious it is, as I have trouble taking seriously a system which, at best, tells you what you need to prepend. It’s a nice protection from fat fingers, but, in its current state, it provides little to no protection beyond that for anyone but the largest operators.
> 
> Becoming bestpath in a densely-interconnected network using a forged-origin hijack in the face of a ROA that has all it's covered prefixes in the DFZ is actually not trivial, and often not possible, because you loose on path-length.

If you’re forging a major provider’s origin AS, sure. If you’re forging a remote single-homed customer of a small rural ISP that buys from a reseller of a reseller of a transit backbone, it gets fairly trivial if you can find a cooperative (or inattentive) network close to a major IX (not so hard currently).

> This is even more true in networks that filter peers and customers by prefix, as you have less chance of exploiting a higher local-pref to overcome path-length.
> As a result, the protection that OV offers is not meaningless.

Yes, but you only need to tie the path length, and you don’t necessarily need to hijack 100% of traffic to achieve a useful result, depending on the goal of your particular hijack.

> OV is also a prerequisite for validating the entire path against stated policy, various mechanisms for which are currently WIP in SIDROPS and GROW.

Yes, but none of those has much promise of producing a useful result in the foreseeable future.  Once they do, then I might consider this serious vs. merely operational.

> Nonetheless, even if one wants to take RPKI seriously, a quick review of the RFCs and IETF guidance on the matter shows that the worst case scenario for an RIR outage on ROA publication should be that routing reverts to its pre-RPKI unauthenticated state. It should not cause any sort of outage (except to the extent you might start accepting routes you previously rejected).
> If you’re rejecting routes for RPKI validation failure, you should be tracking down the advertisers and getting those situations corrected. If you’re doing that, then any such outages should be somewhere between minimal and non-existent.
> If issuing party tools are unavailable to resource holders, they will be unable to effect the correction.

True. But it’s going to take longer to get to the point of being ready to make the correction than my understanding of the duration of this outage.

> Did any packets go the wrong way due to the AfriNIC outage? Was there any actual operational impact?
> I suspect not. I suspect that this is a lot of handwaving about a non-issue.
> 
> I suspect some, though certainly few. The same incident at a time when more networks are performing OV could look very different, and I'm simply suggesting that we look closely at the options before that happens.

As I understand it, AfriNIC has already modified their human procedures to address exactly this. What am I missing?

I suspect no actual packets were harmed in the making of this email thread.

> Don’t get me wrong, I’m all for making AfriNIC’s systems more resilient and more available, but, I think we also need to consider the actual impact of failures and not over-react to failures without impact.
> Based on the information in the post mortem, it does not look like a systems failure, but purely human error. Taking the humans out of the loop on that monthly maintenance would involve compromising the integrity of the private key and thus reduce the validity of the RPKI data. As such, I’m not convinced that there is a problem here to solve beyond the procedural changes that AfriNIC says they have already implemented.
> 
> I'm not arguing for any specific change. I would point out that when there are humans in the system, then a human failure *is* a system failure, and we should be clear on what failure modes can and cannot be tolerated.

Yep… And the design specs of RPKI call for this kind of failure to be tolerable. If that’s not acceptable, then go address the RFCs and redesign RPKI to be more resilient.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/community-discuss/attachments/20190410/29155c82/attachment.html>