Résumé

  • La fenêtre de correctifs de sécurité d’APNIC est prévue le 13 octobre, de 08 h à 09 h UTC+10. L’avis prévoit jusqu’à deux minutes d’indisponibilité de rsync sur rpki.sub.apnic.net et n’attend pas d’interruption des autres services RPKI.
  • Ce point sert à la publication pour les clients RPKI auto-hébergés, selon la CPS publiée par APNIC. L’avis ne permet pas de déduire comment chaque client réessaiera, si son cache changera ou si le routage sera touché.

Analyse

L’avis de service publié par APNIC le 9 octobre réserve une heure, le mardi 13 octobre, à l’application de correctifs de sécurité au système RPKI. Il précise une interruption plus étroite à l’intérieur de cette fenêtre : le service rsync de rpki.sub.apnic.net sera indisponible pendant deux minutes au plus. APNIC ne prévoit pas d’interruption des autres services RPKI.

Il faut garder ces trois éléments distincts : une heure de travaux, une interruption possible plafonnée à deux minutes sur un service rsync nommé, et une attente concernant le reste des services RPKI. Parler d’une panne RPKI d’une heure élargirait l’impact annoncé. Dire qu’il n’y aura aucune perturbation ferait disparaître l’avertissement destiné aux clients qui utilisent ce point.

Le nom d’hôte a un rôle précis dans la CPS publiée par APNIC. Le document distingue le dépôt des autorités de certification d’APNIC d’un service de publication pour les clients RPKI auto-hébergés. Il indique rpki.sub.apnic.net pour rsync et rrdp.sub.apnic.net pour RRDP dans ce service. La CPS précise qu’elle est entrée en vigueur le 4 mai 2021 : elle décrit l’architecture publiée, pas un inventaire actualisé des configurations clientes.

Cette distinction permet de lire l’avis à la bonne échelle. La surface concernée n’est ni l’ensemble des fonctions RPKI d’APNIC ni tous les réseaux qui utilisent des données RPKI. C’est une méthode de récupération identifiée sur un point de dépôt. La phrase d’APNIC selon laquelle les autres services RPKI ne devraient pas être interrompus est une prévision ; l’avis ne décrit pas séparément le comportement de chaque client ou moyen d’accès.

La couche protocolaire explique l’enjeu. La RFC 8897 indique que les logiciels des relying parties récupèrent des objets signés par les mécanismes pris en charge par le dépôt visé, notamment rsync ou RRDP, afin de mettre à jour un cache local. La RFC 8182 définit RRDP comme un protocole d’accès aux dépôts fondé sur HTTPS. Ces textes ne précisent ni la méthode configurée par un opérateur donné, ni un basculement automatique de son logiciel, ni le moment de sa prochaine actualisation.

Une brève interruption peut donc retarder une tentative de récupération pour un client qui dépend de ce point rsync. Elle ne démontre pas, à elle seule, que le cache existant deviendra obsolète, qu’une autorisation d’origine de route changera ou qu’un routeur modifiera son traitement d’une route. L’avis ne donne ni nombre de clients, ni observation de validateur, ni changement de route, ni impact utilisateur. Les travaux sont encore prévus ; aucun résultat après maintenance n’est disponible.

La mesure utile est la portée annoncée : une heure réservée aux travaux, jusqu’à deux minutes d’indisponibilité rsync sur un point précis, et aucune interruption attendue des autres services RPKI. Après le 13 octobre, l’historique de service d’APNIC et les journaux des relying parties des opérateurs permettront de remplacer cette prévision par un constat.

Sources