Re: [Sidrops] ARIN RPKI Repository issue - Wednesday 24 October 2018

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 25 Oct 2018, at 09:36, John Curran <[e-mail]> wrote:
> 
> ARIN experienced an RPKI Repository issue yesterday afternoon (Wednesday 24 October 2018) which resulted in the number of objects in the repository dropping from its normal hundreds of objects to only 7 objects.  The root cause for the failure was too many ROAs for a resource cert that led to an untested situation whereby we exceeded the MTU for the HSM and an invalid manifest in repository..  It appeared that some validators stop processing after the invalid manifest, thus resulting in a greatly reduced count of objects published. 

So this caused the existing the MFT to go *stale* after 48 hours, while the embedded EE certificate had not yet expired (it uses 7 days from what I can see).

Validator software treats these cases differently, because the standards are vague on this, I believe too vague:
https://tools.ietf.org/html/rfc6486#section-6.4 <https://tools.ietf.org/html/rfc6486#section-6.4>

There are many words here. And some seem contradictory, but let me quote:
[…]the entity that has published the stale manifest at this publication point, SHOULD be viewed as somewhat suspect, but MAY be used by the RP as per local policy.

There is similar vagueness around discrepancies between repository content and manifests. Also.. local policy.

As a result the RIPE NCC RPKI Validator 2.x series leave this local policy as a choice to the user, but defaults to rejecting all stale MFTs. RIPE NCC RPKI Validator 3.x accepts stale MFTs with warnings, but only rejects when the EE certificate is expired. I do not know what RPSTIR does, but Rcynic does the same I believe. As does NLnet Lab's ‘Routinator 3000’ - coming real soon now :)

I am not 100% sure about RPSTIR but all other validators use the ‘local’ policy that the MFT is the authoritative signed statement of what is current for a CA. In other words anything not listed on a MFT, or objects with a different hash, are rejected.

In my opinion it would be best if the relevant sections in the MFT RFC (6486) were updated to ensure that there are no unexpected differences between RP implementations. Accepting stale, rejecting expired && only processing what is on a valid manifest seems the sane way forward to me, and reflects most of the operational reality.

I would be happy to come up with text for people to shoot at :)

Tim