Résumé

  • La suggestion ARIN 2026.11 demande à rpki.arin.net et rrdp.arin.net de répondre aux requêtes ICMP Echo. La page publique indique « Confirmed », sans calendrier ni preuve de mise en service.
  • Une réponse Echo ne renseigne que sur la joignabilité depuis une sonde donnée. Elle ne prouve pas qu’un relying party a récupéré le dépôt, synchronisé son dernier état ou validé les objets signés.
  • Les opérateurs doivent distinguer la joignabilité réseau, la récupération du dépôt et la fraîcheur des données signées. Le ping n’est utile que si ses limites restent visibles.

Le statut précède le calendrier

La fiche publique de la suggestion 2026.11 de l’ARIN est brève. Déposée le 6 octobre 2026 par Job Snijders, elle demande que rpki.arin.net et rrdp.arin.net répondent aux requêtes ICMP Echo. Son auteur estime que cela aiderait à diagnostiquer la connectivité, à surveiller la joignabilité et à optimiser les chemins. La page affiche le statut « Confirmed », mais précise que le calendrier n’est pas spécifié. Les rubriques visibles « Tracking Information » et « ARIN Comment » ne contiennent ni réponse ni détail de publication.

Ce sont les faits publics. « Confirmed » est le libellé affiché par la page ; celle-ci n’en définit pas le sens dans le cycle de traitement. Il ne faut pas le transformer en « mis en œuvre », « planifié » ou en promesse d’une sortie imminente. La fiche ne rapporte aucune mesure des points de terminaison, aucun résultat utilisateur ni aucun incident.

La suggestion affirme également que trois autres services de l’ARIN répondent déjà aux requêtes Echo et que les autres RIR rendent leurs points de terminaison publics Rsync et RRDP joignables par ping. Ces comparaisons sont celles de la soumission. Elles n’ont pas fait l’objet de mesures indépendantes pour cet article.

Ce qu’une réponse Echo peut indiquer

ICMP Echo est un outil de diagnostic familier parce que la question est simple : une réponse est-elle revenue de l’adresse visée vers cette sonde ? La réponse vaut pour un point de mesure, une famille d’adresses, un chemin et un instant. Elle peut aider à examiner un problème apparent de chemin ou de joignabilité. Elle ne teste pas toutes les voies applicatives utilisant le même nom d’hôte ; le silence ne prouve pas, à lui seul, que le service de dépôt est en panne.

Cette limite compte particulièrement pour le RPKI. L’ARIN décrit son service comme publiant des certificats de ressources et des déclarations d’origine signées que les opérateurs récupèrent et valident. Le dépôt fournit des données aux relying parties ; la réponse ICMP n’est pas une déclaration signée et ne fait pas partie de leur résultat de validation.

Trois questions, trois observations

La première porte sur la joignabilité réseau. Une réponse Echo indique qu’une sonde a reçu une réponse au niveau réseau. Un système de surveillance devrait aussi préciser le point de mesure, la famille d’adresses et l’heure. Une sonde qui réussit ne constitue pas un relevé global.

La deuxième concerne la récupération et la synchronisation du dépôt. RRDP possède son propre échange applicatif. La RFC 8182 décrit un fichier de notification avec un identifiant de session, un numéro de série, un instantané courant et, le cas échéant, des deltas. Le relying party récupère ces fichiers et en vérifie les empreintes avant la synchronisation. Rsync constitue une autre transaction de service. Une réponse ICMP n’effectue aucune de ces opérations.

La troisième porte sur l’état et la validité des données. La RFC 9286 définit des manifestes signés qui répertorient les objets du dépôt et leurs empreintes, avec des informations d’actualisation. Les exigences applicables aux relying parties décrivent l’évaluation des manifestes, y compris lorsqu’ils sont périmés ou invalides. Un serveur peut répondre au ping alors qu’une vérification distincte de récupération ou de fraîcheur signale un problème ; un ping peut aussi échouer alors que le téléchargement applicatif réussit. Aucun de ces écarts ne prouve un incident à l’ARIN. Ils montrent pourquoi il faut garder les signaux séparés.

Une fiche de suivi utile garderait les couches distinctes

Si l’ARIN met la suggestion en œuvre, une fiche destinée aux opérateurs pourrait nommer le point de terminaison, le périmètre de la sonde et la date de publication, puis séparer les résultats : réponse Echo ; récupération de la notification RRDP et des objets ; récupération Rsync ; session et numéro de série RRDP observés ; fraîcheur du manifeste et résultat de validation. Chaque champ devrait avoir son propre horodatage et sa source de mesure. Une note de version pourrait préciser les points de terminaison et familles d’adresses concernés, le moment de déploiement en production et les contrôles effectués ensuite.

Il s’agit d’une proposition de présentation, pas d’une promesse de l’ARIN. Elle n’impose pas non plus à chaque relying party d’utiliser ICMP. Un réseau peut décider d’inclure Echo dans ses propres diagnostics tout en vérifiant le dépôt avec le protocole qu’il consomme réellement.

Cette distinction peut accélérer le diagnostic. Si Echo échoue alors que RRDP fonctionne depuis le même point de mesure pertinent, le premier résultat ne doit pas être présenté comme la preuve d’un échec de publication RPKI. Si Echo réussit mais que RRDP ne récupère pas de notification ou d’objet, la réponse ne doit pas neutraliser l’alerte applicative. Si les fichiers arrivent mais que le manifeste signé est périmé ou invalide, la joignabilité réseau n’est pas le fait déterminant. Chaque résultat appelle une enquête différente.

La demande ICMP est donc utile précisément parce qu’elle reste modeste. Elle ajoute un signal de diagnostic ; elle ne modifie pas la confiance RPKI. Il ne faut pas lui attribuer davantage d’autorité qu’elle n’en possède.

Ce qui reste inconnu

Au 14 octobre 2026, la page publique de la suggestion ne donne ni date de livraison ni preuve de mise en œuvre. Le comportement actuel des deux hôtes n’a pas été mesuré indépendamment ici. Les sources citées n’établissent ni panne, ni dépôt périmé, ni validation échouée, ni effet sur le routage, ni préjudice pour un client. Le libellé de statut ne répond pas à ces questions.

La règle pratique pour les opérateurs est simple : consigner la joignabilité comme telle, la synchronisation du dépôt comme telle, et la validation cryptographique comme telle. Si la suggestion passe du libellé de statut à une modification déployée, la trace publique devrait rendre ce passage visible. D’ici là, « Confirmed » reste un statut publié, pas un second signal.

Sources