Summary

  • APNIC’s 13 October security-patching window is scheduled for 08:00–09:00 UTC+10. The notice says rsync at rpki.sub.apnic.net may be unavailable for up to two minutes and that no interruption is expected to other RPKI services.
  • The endpoint matters: APNIC’s published CPS associates it with publication for self-hosted RPKI clients. The forecast does not establish how any client will retry, whether its cache will change, or whether routing will be affected.

Analysis

APNIC’s 9 October service notice sets a one-hour window for security patches to its RPKI system on Tuesday 13 October. It identifies a narrower interruption inside that window: the rsync service at rpki.sub.apnic.net will be unavailable for up to two minutes. APNIC says it does not expect other RPKI services to be interrupted.

Those are three separate claims: a one-hour work window, a possible interruption capped at two minutes on one named rsync service, and an expectation about the rest of the RPKI service set. Calling this a one-hour RPKI outage would enlarge the stated impact. Calling it no disruption would erase the warning for clients that use this endpoint.

The hostname also has a specific role in APNIC’s published Certification Practice Statement. That document distinguishes the repository used by APNIC’s certification authorities from a publication service for self-hosted RPKI clients. It lists rpki.sub.apnic.net for rsync and rrdp.sub.apnic.net for RRDP in the self-hosted service. The CPS says it took effect on 4 May 2021, so it provides published architectural context, not a fresh inventory of current client configurations.

That distinction changes how the notice should be read. The affected surface is not every APNIC RPKI function and not every network that consumes RPKI data. It is a named retrieval method at a repository endpoint. APNIC’s statement that other RPKI services are not expected to be interrupted is a forecast; the notice does not separately describe the behavior of every client or every access method.

The protocol layer explains why the distinction matters. RFC 8897 describes relying-party software retrieving signed objects through mechanisms supported by the target repository, including rsync or RRDP, and using them to update a local cache. RFC 8182 defines RRDP as an HTTPS-based repository-access protocol. These standards do not tell us which method a particular operator has configured, whether its software automatically changes methods, or when its cache would next refresh.

A short fetch interruption can therefore mean a delayed retrieval attempt for a client that depends on this rsync endpoint. It does not, by itself, show that the client’s existing cache becomes stale, that a route-origin authorization changes, or that a router changes its treatment of a route. The notice reports no client count, validator observation, route change or user impact. The work is still scheduled; no post-maintenance result exists yet.

The useful measure is scope: one hour reserved for work, up to two minutes of stated rsync unavailability at one endpoint, and no interruption expected to other RPKI services. After 13 October, APNIC’s service record and operators’ own relying-party logs would be the evidence needed to replace that forecast with an observed result.

Sources