Résumé

  • L’IESG a ouvert le 28 août le Last Call de draft-ietf-sidrops-publication-server-bcp-10, destiné au statut de Best Current Practice ; la consultation se termine le 11 septembre selon le Datatracker.
  • Le projet emploie les termes BCP 14 MUST, SHOULD et RECOMMENDED, tout en précisant qu’ils marquent ici l’importance opérationnelle et ne sont pas des exigences formelles de mise en œuvre.
  • Un BCP final établirait une pratique examinée par l’IETF. Il ne démontrerait ni l’adoption d’une mesure par un opérateur donné, ni son respect pendant un incident, ni l’existence d’une certification IETF.
  • Chaque service de publication devrait associer aux sections pertinentes un état versionné, une définition de mesure, les exceptions, les restaurations, les réinitialisations RRDP, les avis aux éditeurs et l’achèvement de la resynchronisation.
  • Aucun élément disponible ne permet de déclarer un RIR, un NIR, une autorité de certification, un prestataire de publication ou un CDN conforme ou non conforme.

Le Last Call porte sur une chaîne, pas sur un serveur isolé

Le document mis en consultation le 28 août ne crée pas un nouvel objet signé. Il traite de la manière dont les objets existants passent de l’intention d’une autorité de certification à la vue dont disposent les relying parties. Cette chaîne comprend le moteur de publication défini autour de RFC 8181, les dépôts publics RRDP et rsync, les couches éventuelles de cache ou de CDN, puis les logiciels qui récupèrent et valident les données.

Cette position intermédiaire rend le service difficile à résumer. Une ROA peut être correctement signée sans être encore visible. Un moteur peut répondre alors qu’un nœud public sert un état ancien. Une restauration peut remettre en ligne un ensemble cohérent mais antérieur. Un fichier de notification peut annoncer des deltas qui ne sont pas encore disponibles partout. La signature répond à la question de l’origine et de l’intégrité d’un objet ; elle ne donne pas, à elle seule, l’historique du transport, de la fraîcheur et de la reprise.

Version 10 du projet rassemble plus de dix ans de retour d’exploitation. Elle aborde la séparation des fonctions, la disponibilité, les pertes de données, la synchronisation entre éditeur et dépôt, les dépendances DNS et routage, les deux familles d’adresses, l’usage d’un CDN, l’ordre de visibilité des fichiers, l’équilibrage de charge et la cohérence des vues. Sa valeur vient précisément de cette granularité.

La portée exacte des majuscules

BCP 14 fournit un vocabulaire bien connu. RFC 2119 qualifie MUST d’exigence absolue de la spécification et demande qu’une dérogation à SHOULD soit justifiée par une compréhension complète de ses conséquences. RFC 8174 réserve ce sens particulier aux formes écrites en capitales.

Le projet RPKI reprend cette formule, puis ajoute une réserve propre à son objet. Les mots servent à insister sur l’importance pour l’exploitation ; ils ne sont pas requis comme exigences formelles de mise en œuvre.

Il faut lire les deux phrases ensemble. Si l’on ne conserve que la réserve, les prescriptions deviennent de simples conseils que chacun peut ignorer. Si l’on ne conserve que les majuscules, le futur BCP risque d’être présenté comme un référentiel de certification qu’il ne crée pas. Le texte choisit une troisième voie : une pratique fortement recommandée, issue d’une expérience collective, sans transformer l’IETF en autorité d’agrément des dépôts.

RFC 7841 aide à maintenir cette frontière. Le statut de BCP et la mention du processus de revue expliquent d’où vient l’autorité documentaire. Ils ne répondent pas à des questions d’exploitation : quel périmètre a été évalué, sur quelle période, avec quelles mesures, par qui, et que s’est-il passé lors de la dernière restauration ?

Le consensus établit la référence. Il ne remplit pas le rapport d’exécution d’un tiers.

Trois surfaces qui ne doivent pas partager un seul taux

Le projet demande une haute disponibilité du contenu public et du moteur de publication. Pourtant, ces deux surfaces ne produisent pas le même dommage lorsqu’elles s’arrêtent.

Si RRDP ou rsync est inaccessible, les relying parties ne peuvent plus récupérer normalement l’état courant. Si le moteur côté éditeur est indisponible, une autorité de certification ne peut plus publier une émission ou une révocation nouvelle. Une panne prolongée peut laisser vieillir manifestes, listes de révocation et objets signés. Un pourcentage global masque donc au minimum le canal d’écriture, le canal RRDP et le canal rsync.

Le projet recommande aussi de séparer le moteur des machines qui répondent aux requêtes publiques. L’objectif est d’éviter qu’une charge sur la lecture n’emporte l’écriture. Il invite les opérateurs à surveiller la boucle complète en comparant l’apparition attendue et l’apparition observée d’un objet réémis. Ce contrôle ne demande pas de révéler une architecture attaquable. Il demande de définir un départ, une arrivée, des points d’observation, une fenêtre et le sort des échecs.

La différence avec un simple test HTTP est fondamentale. Une page peut répondre pendant que le contenu attendu n’est pas apparu. À l’inverse, une brève indisponibilité peut ne pas produire de conséquence immédiate parce que les relying parties disposent de données valides en cache. Le temps restant avant obsolescence fait partie de l’état.

La restauration est le meilleur test de vérité

Une restauration depuis une sauvegarde ancienne peut faire régresser le contenu. Le projet prescrit alors une réinitialisation de session RRDP. Il recommande également d’informer les autorités de certification dépendantes afin qu’elles puissent effectuer une resynchronisation complète.

Ce scénario montre pourquoi un journal d’incident est plus utile qu’un badge. Il faut relier l’heure de restauration, l’ancienneté de la sauvegarde, la détection de la régression, le nouvel identifiant de session, l’avis envoyé, la requête de liste de l’éditeur, la republication complète et l’observation finale. Chacun de ces actes appartient à un responsable différent ou répond à une question différente.

RFC 8181 permet à un éditeur de demander la liste de l’état reconnu par le serveur. Le projet recommande d’effectuer cette comparaison avant l’envoi de changements et de regrouper les opérations qui doivent être atomiques dans une même requête à éléments multiples. Il déconseille une resynchronisation planifiée plus fréquente qu’une fois toutes les dix minutes, sauf accord, car le protocole ne fournit pas de mécanisme suffisant de limitation ou de recul demandé au client.

Ce sont des faits mesurables. La simple affirmation « la sauvegarde a fonctionné » ne dit pas si l’état récent des éditeurs, des objets et des retraits a été retrouvé.

Un numéro de série n’est pas un avis d’audit

RRDP utilise un identifiant de session et un numéro de série. Les deltas décrivent des événements successifs et un instantané permet une reprise complète. Le mécanisme réduit les transferts et offre une vue ponctuelle cohérente d’un dépôt.

Mais une série qui augmente ne prouve pas tout ce qui se trouve en amont et autour d’elle. Elle ne démontre pas que l’ensemble voulu par l’éditeur a été accepté, que tous les nœuds derrière l’équilibrage présentent les mêmes fichiers, ni que chaque relying party a vu la nouvelle version. C’est pourquoi le projet interdit de rendre visible un nouveau fichier de notification avant les instantanés et deltas qu’il référence. L’ordre de publication est une donnée de correction.

RFC 9286 apporte une autre preuve bornée. Le manifeste énumère les noms et condensats de fichiers, ce qui aide à détecter certaines substitutions anciennes, suppressions ou modifications. Il ne contrôle pas le délai de préavis d’une maintenance, la capacité IPv4/IPv6, l’âge d’une sauvegarde ou les réglages du CDN.

Parler de « conformité BCP » sans énumérer les sections et les tests reviendrait donc à transformer plusieurs preuves différentes en une conclusion introuvable dans les sources.

La consolidation ne crée pas un monopole de droit

Le document indique que les dépôts auto-hébergés rencontrent, en pratique, davantage de problèmes de disponibilité que ceux de grandes organisations spécialisées. Il souligne aussi que la multiplication des points de publication augmente le travail des relying parties. Il recommande aux autorités parentes d’offrir la publication à leurs enfants et aux enfants d’utiliser ce service lorsqu’il existe ; à défaut, un prestataire tiers fiable peut être préférable à un nouveau dépôt isolé.

Cette recommandation répond à une économie d’exploitation. Elle n’accorde pas une franchise exclusive à un RIR, un NIR ou une entreprise. Le même texte reconnaît qu’un petit dépôt peu changeant peut atteindre une haute disponibilité avec des moyens modestes. Il décrit également plusieurs arrangements pour une autorité « petite-fille ».

La fiche de mise en œuvre doit donc commencer par le modèle choisi : dépôt propre, service du parent, tiers ou mandataire. Une exigence peut être applicable, non applicable, planifiée, en exception ou inconnue. Non applicable accompagné d’une raison est plus honnête qu’un oui global. Il évite aussi de publier des détails sensibles qui n’ont pas à devenir publics.

Une fiche de mise en œuvre, section par section

La première partie identifie le service, l’opérateur, l’architecture et la version exacte du projet ou du RFC. La formule « selon le BCP IETF » n’est pas assez précise : la version 10 peut encore évoluer pendant le Last Call et l’évaluation de l’IESG.

La deuxième partie associe chaque pratique matérielle à un état et à une autorité d’attestation. Elle conserve la date de revue, la raison d’une exception et le périmètre. Les anciennes déclarations ne sont pas écrasées silencieusement.

La troisième décrit les mesures. Pour la publication en boucle complète : classe d’objet, événement de départ, observation d’arrivée, points de vue, période, percentiles, échecs et exclusions. Pour la disponibilité : dénominateurs séparés du moteur, de RRDP et de rsync. Pour le CDN : durée de cache du fichier de notification et contrôle observé. Pour l’équilibrage : test de cohérence sûr.

La quatrième porte sur les changements et incidents : maintenance, régression, réinitialisation RRDP, avis aux éditeurs, demande de resynchronisation, preuve d’achèvement et divergence restante.

La dernière qualifie la provenance. S’agit-il d’une déclaration interne, d’une mesure indépendante, d’un audit contractuel ou d’une revue d’incident ? Cette ligne empêche l’opérateur d’emprunter le nom de l’IETF comme s’il s’agissait de l’organisme certificateur.

La fiche ne promet pas un résultat de routage. Elle permet seulement de vérifier une affirmation d’exploitation dans son périmètre.

Ce qui n’est pas encore démontré

Le Last Call n’est pas une adoption. Le projet peut être modifié, évalué par l’IESG, publié ou ne pas aboutir. Aucun numéro de RFC ou de BCP n’est encore attaché à ce texte.

Les affiliations des auteurs ne sont pas des rapports d’audit de RIPE NCC, ARIN, APNIC ou d’une autre organisation. Aucun incident imputé à un opérateur nommé n’est présenté. Aucune source ne dit qu’un futur BCP remplacera un contrat, une obligation d’achat, une décision de justice ou le choix de routage d’un réseau.

La conclusion solide est limitée : l’IETF examine une description très détaillée des bonnes pratiques de publication RPKI. Si elle devient BCP, elle gagnera une forte provenance de consensus. Pour connaître la réalité d’un service, il faudra toujours demander ses preuves.

Sources

  1. IESG — Last Call du projet de BCP sur la publication RPKI
  2. IETF Datatracker — fiche courante du document
  3. IETF Datatracker — texte immuable de la version 10
  4. RFC 2119 — termes de niveau d’exigence
  5. RFC 8174 — clarification des capitales
  6. RFC 7841 — flux, catégories et mentions des RFC
  7. RFC 8181 — protocole de publication RPKI
  8. RFC 8182 — RPKI Repository Delta Protocol
  9. RFC 9286 — manifestes RPKI
  10. RFC 7115 — exploitation de la validation d’origine RPKI