Dear RIPE NCC,
On Tue, Feb 16, 2021 at 04:56:31PM +0100, Nathalie Trenaman wrote:
> On Monday, 15 February we encountered an issue with our RPKI software.
> This issue prevented us from publishing RPKI object updates from
> 08:07-18:06 (UTC).
>
> During this period, Certificate Authority activation and Route Origin
> Authorization configuration updates were delayed and therefore not
> visible in the RPKI repository.
It appears Certificate Authority revocation was also delayed.
> The updates were published after we restarted the system at 17:45
> (UTC), with full recovery completed by 18:06 (UTC). Since this
> non-publishing period is shorter than our default RPKI object validity
> period, set to 8 hours, existing objects that are not updated were
> still valid. No data was lost during this period.
Can the following phrase "default RPKI object validty period, set to 8
hours" please be clarified?
For objects produced in the RIPE-hosted RPKI environment I observe the
following validity periods are commonly used:
Object type | validity duration after issuance
-------------------+---------------------------------
CRLs | 24 hours
ROA EE certs | 18 months
Manifest eContent | 24 hours
Manifest EE certs | 7 days
CAs | 18 months
I'm just guessing, is the '8 hour' period a reference to RIPE-751
section 2.3?
"A certificate will be published within eight hours of being issued (or
deleted)."
The RIPE-751 CPS also states in section 4.9.8 ("Maximum latency for
CRLs"): CRLs will be published to the repository system within one hour
of their generation.
As the outage appears to have exceeded both the 1 hour revocation window
and 8 hour object publication window, RIPE NCC was not compliant with
its own CPS.
The multitude of RPKI service impacting events as a result from
maloperation of the RIPE NCC trust anchor are starting to give me me
cause for concern.
Kind regards,
Job
