Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage)

Mon Oct 1 14:39:03 UTC 2018

On 1 Oct 2018, at 1:20 AM, Mark Tinka <mark.tinka at seacom.mu<mailto:mark.tinka at seacom.mu>> wrote:
On 1/Oct/18 01:21, John Curran wrote:

It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome.   There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion.

John, in the instance where all RIR's transition to a single "All Resource" TA, what would, in your mind, be the (potential) liability considerations?

Mark -

If there were to be an RIR CA outage, it would not appear that the RIRs use of “All Resources” TAs would materially affect the resulting operational impact to the Internet.  (As noted earlier, the impact would be predominantly proportional to the number of ISPs that fail to follow best practices in route processing and fall back properly when their received routes end up with status NotFound, i.e. no longer match against their cache of validate ROAs since the cache has expired)

The “All Resources” TA used by each RIR done to avoiding CA invalidation due to overclaiming (as detailed in https://datatracker.ietf.org/doc/rfc8360) – it reduces the probability of a different and hopefully rare RPKI failure scenario (involving the possible accidental invalidation of an RIR CA) until such time as a slightly different RPKI validation algorithm can be deployed that would limit any such invalidation solely to the resources in the overlap.

(That’s my high-level understanding of the situation; comments on this question from those closer to the actual network bits would be most welcome…)

Thanks!
/John

John Curran
President and CEO
ARIN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181001/82065f97/attachment.html>