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

Mon Oct 1 08:36:34 UTC 2018

On 1/Oct/18 10:26, John Curran wrote:

>
> Of course, this presumes correct routing configuration by the ISP when setting up RPKI route validation; while one would hope that the vast majority handle this situation correctly, there is no assurance that will be true without exception. If RPKI routing validation is widely deployed, tens of thousands of ISPs will be setting up such a configuration, with customer impact during an RPKI CA outage occurring for those who somehow failure to fall back to using NotFound routes.  If only a small percentage get this wrong, it will still represent dozens of ISPs going dark as a result. 

It is equally important to understand how vendors have interpreted the
RFC for default treatment of RPKI data.

When we started testing IOS and IOS XE back in 2014/2015, we hit an
issue where Cisco were automatically applying policy to RPKI state
without configuration from the operator. This was fixed in later code,
but goes to show that one should not assume that vendors are always
doing the right thing, or at the very least, fully understand what their
view on RPKI might be on the wider Internet, in real production.

So before deploying network-wide, I encourage operators to test what
their equipment will do when RPKI is enabled but without any manual
policy applied.

> Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR?

Any equipment misconfigurations should be the responsibility of the
operator.

Responsibility for ROA's should lie with the resource holder, in
ensuring that not only is the information true, but that also all
announced prefixes are covered by a ROA.

An RIR CA outage would, in my mind, be the responsibility of the RIR.
But this comes back to my question of how this handled with an "all
resource" TA.

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