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