Résumé

  • Le guide actuel de RIPE NCC demande au titulaire d’un AS d’inscrire tous ses fournisseurs amont, les voisins multirôles lorsqu’ils agissent comme fournisseurs et les serveurs de routes non transparents ; il indique pourtant que le tableau de bord RPKI ne fournit aucun indice tiré de BGP.
  • Le plan d’activités 2026 envisage des suggestions fondées sur les AS que RIPE NCC pense être des fournisseurs amont. Cette formulation décrit une inférence et ne fixe ni date de livraison ni vérité contractuelle.
  • La bonne interface doit présenter une preuve située — source, point d’observation, période, famille d’adresses et incertitude — puis laisser l’opérateur accepter, refuser ou qualifier chaque candidat. L’ASPA signé demeure l’autorisation.

Un formulaire vide peut être une marque de prudence. Il peut aussi cacher le travail le plus risqué.

Dans le tableau de bord RPKI de RIPE NCC, le titulaire d’un système autonome dispose du pouvoir de créer un ASPA, une attestation signée qui désigne les AS autorisés à lui fournir du transit. La cryptographie garantit alors l’origine et l’intégrité de la déclaration. Elle ne garantit pas que la liste a été correctement composée.

Le guide public de RIPE NCC ne minimise pas cette difficulté. Il demande d’inscrire tous les fournisseurs amont et de maintenir l’objet au même rythme que leurs changements. Un voisin qui cumule plusieurs rôles doit figurer dans l’ASPA dès lors que l’un de ces rôles est celui de fournisseur. Un serveur de routes non transparent d’un point d’échange doit également y figurer. À l’inverse, les pairs latéraux et les clients ne doivent pas être ajoutés.

L’omission a une conséquence potentielle précise : les routes envoyées par l’intermédiaire d’un fournisseur absent peuvent être rejetées. Puis le texte expose la limite du service : le tableau de bord RPKI ne donne ni indice ni orientation sur les fournisseurs vus pour l’AS dans BGP. C’est à l’opérateur de s’en assurer.

Le titulaire reçoit donc le stylo avant de recevoir l’inventaire que RIPE NCC pourrait tirer de ses propres observations. Ce décalage ne rend pas l’ASPA invalide. Il révèle l’endroit où l’autorité de signer rencontre l’incertitude des données.

Une liste courte peut être aussi fausse qu’une liste longue

Les projets actuels de l’IETF décrivent deux erreurs de sens opposé. Le profil ASPA, dans sa révision 29 au moment de la capture, demande qu’un AS client utilisant plusieurs fournisseurs les inscrive tous, y compris les serveurs de routes non transparents. Il recommande un objet unique contenant l’ensemble complet.

Le projet sur la vérification, alors en révision 28, explique le coût des erreurs. Ajouter à tort un fournisseur diminue la capacité de détecter les fuites de routes. Oublier un fournisseur peut, plus tard, faire apparaître des routes légitimes comme ASPA Invalid. Les deux textes restent des Internet-Drafts : ils peuvent évoluer avant de devenir des RFC.

Cette symétrie imparfaite doit guider l’interface. Une suggestion trop généreuse affaiblit la protection. Une suggestion trop parcimonieuse prépare un faux négatif opérationnel au moment où un chemin oublié se réveille. La réussite ne se mesure donc pas au nombre d’AS proposés ni au nombre de clics économisés, mais à la qualité de la décision que la proposition permet.

Le cas le plus facile est un fournisseur de transit quotidien, visible dans les deux familles d’adresses et connu de toute l’équipe. Les cas utiles sont justement les autres : transit de secours rarement activé, fournisseur régional limité à une zone, relation multirôle, session héritée d’une acquisition, serveur de routes dont le mode n’est pas évident, ou circuit en cours de retrait.

BGP observe une trajectoire, pas un contrat

Une adjacence dans un chemin AS possède une provenance. Elle a été vue depuis un point donné, à une heure donnée, après une chaîne de décisions d’exportation. Un collecteur public ne voit pas la totalité des chemins disponibles. Deux collecteurs peuvent donner des images différentes. IPv4 et IPv6 peuvent emprunter des routes distinctes. Une maintenance de quelques minutes peut faire apparaître un fournisseur de secours ; une fuite peut rapprocher deux AS qui n’ont aucune relation autorisée.

Même la télémétrie BMP interne ne tranche pas le statut économique. Elle améliore considérablement l’observation parce qu’elle peut conserver l’Adj-RIB-In avant politique, routeur par routeur et voisin par voisin. Elle montre ce qui a été reçu. Elle ne dit pas ce qui a été convenu, ni le rôle que les parties entendent attribuer à chaque session.

La formule « fournisseur observé » doit donc rester grammaticalement incomplète : observé où, quand, dans quelle famille, dans quelle direction et sous quelle politique ? Sans ces compléments, un fait de routage est élevé au rang de titre juridique ou commercial qu’il ne possède pas.

Il faut garder quatre plans séparés. Les collecteurs et la télémétrie produisent des observations. Les contrats, l’inventaire de sessions et l’architecture du réseau qualifient les rôles. Le titulaire de l’AS décide de l’autorisation. RIPE NCC publie l’objet signé, que validateurs et routeurs pourront ensuite exploiter selon une norme encore mouvante et une politique locale.

Le plan 2026 nomme déjà la bonne prudence

Le plan d’activités et budget 2026 de RIPE NCC annonce une amélioration des informations BGP destinées à la gestion des ROA et des ASPA. Pour les ROA, il vise une information proche du temps réel. Pour les ASPA, il parle de suggestions similaires fondées sur ceux que RIPE NCC pense être les fournisseurs amont.

Le verbe implicite compte autant que le substantif. RIPE NCC « pense » reconnaître des fournisseurs. Il ne déclare pas les connaître. La phrase ouvre ainsi la voie à une aide probatoire, sans transférer au registre la maîtrise des relations d’interconnexion.

Elle ne donne toutefois pas de date. La page de planification RPKI capturée pour le troisième trimestre 2026, mise à jour le 11 juin, publie quatre chantiers : la révocation automatique des autorités de certification déléguées durablement défaillantes, le remplacement des clés API par des clés fondées sur OpenID Connect, les travaux de conformité et, sous réserve de capacité, la prise en charge API des Resource Signed Checklists. Les suggestions ASPA n’y sont pas nommées.

Cette absence n’est pas la preuve d’un retard ou d’un abandon. Elle établit seulement que la fonction ne figure pas parmi les quatre éléments de ce trimestre. Lui attribuer une échéance que le plan annuel ne contient pas transformerait une interrogation légitime en accusation sans source.

Le rapport annuel 2025 fournit le point de départ vérifiable : RIPE NCC y consigne le lancement de la prise en charge des ASPA dans le tableau de bord le 26 novembre 2025. Le droit de publier a donc été livré avant l’aide à l’inventaire envisagée pour la suite. Pour un lancement prudent, l’ordre est compréhensible. Pour les premiers signataires, il laisse toutefois tout le coût de découverte dans l’organisation locale.

Ne rien suggérer protège contre une fausse autorité

La meilleure défense du formulaire actuel mérite d’être prise au sérieux. RIPE NCC ne connaît pas nécessairement les contrats privés, les plans de secours, les rôles d’un voisin sur plusieurs sessions ni le caractère transparent d’un serveur de routes. Préremplir une liste avec le ton d’une certitude institutionnelle encouragerait l’utilisateur à confondre la qualité d’une observation avec la validité d’une relation.

Dans un service de signature, le lieu de la recommandation lui confère du poids. Une hypothèse affichée à côté du bouton de publication peut être acceptée parce qu’elle paraît déjà validée par le registre. Une case vide accompagnée d’un avertissement honnête évite cette délégation silencieuse.

Mais la prudence n’impose pas l’aveuglement. L’interface peut montrer ce qu’elle voit, expliquer pourquoi elle le montre et demander une décision. Elle n’a pas besoin de transformer l’inférence en réponse.

Transformer la suggestion en dossier de décision

Chaque AS candidat devrait arriver avec une fiche de preuve. Celle-ci commencerait par la source : RIS ou autre collecteur public, jeu de points d’observation, ou télémétrie fournie par l’opérateur. Elle indiquerait la date de la capture, le début et la fin de la période, la famille d’adresses, la position dans le chemin et la fréquence de l’adjacence.

Elle devrait ensuite montrer la distribution. Le candidat apparaît-il partout ou seulement depuis quelques points ? Est-il stable, intermittent, limité à une région ou visible uniquement pendant une bascule ? Se rencontre-t-il en IPv4, en IPv6 ou dans les deux ? Existe-t-il un indice public de serveur de routes et, le cas échéant, son ASN est-il visible dans le chemin ?

La fiche doit aussi énoncer ses incapacités. L’adjacence ne prouve ni le contrat, ni le rôle de fournisseur, ni la permission, ni l’exhaustivité. Un score de confiance doit mesurer la solidité de l’observation, pas certifier la nature commerciale. La version de la règle ou du modèle qui produit la suggestion doit rester consultable.

L’opérateur a besoin de davantage qu’un bouton « accepter ». Il doit pouvoir confirmer le fournisseur, rejeter un pair ou un client, qualifier une relation multirôle, signaler un secours temporaire ou différer le choix. Une référence locale peut pointer vers un contrat ou un inventaire de sessions sans rendre ce document public.

Au moment de signer, le service conserverait la proposition initiale, les décisions, la différence entre l'ancien et le nouvel ensemble, l’utilisateur responsable, l’heure et le hachage de l’objet publié. La correction suivante renverrait à ce reçu. Ainsi, un futur exploitant saurait si une absence était délibérée, provisoire ou simplement oubliée.

L’ASPA public continue d’être l’autorisation. Le reçu n’est pas une nouvelle base mondiale des relations commerciales ; il documente le passage de l’observation à la décision.

Voir l’effet après coup ne suffit pas

Une contribution communautaire publiée sur RIPE Labs le 29 juin 2026 examine l’autre moitié du problème : la difficulté pour un opérateur de voir ce qu’un ASPA ferait dans sa propre table de routage. Ses auteurs présentent RAVEN, un outil qui rapproche les flux BMP des données RPKI transportées par RTR v2 et permet d’annoter les routes ou d’explorer un scénario d’application.

Ce texte n’engage pas RIPE NCC. Il s’agit explicitement d’une contribution communautaire hébergée par RIPE Labs. Il montre néanmoins que l’observabilité peut intervenir à deux moments distincts. Avant la signature, il faut tester la composition de l’ensemble des fournisseurs. Après la signature, il faut examiner les chemins que l’objet contribuerait à classer.

Une simulation ne remplace pas la qualification du lien. Si elle signale un chemin comme invalide, elle ne décide pas si l’erreur réside dans l’ASPA, dans la route ou dans une information manquante. De même, une forte présence dans BGP ne transforme pas un pair en fournisseur. La boucle fiable relie l’observation, l’intention déclarée et la conséquence simulée, sans fondre leurs autorités.

L’erreur silencieuse attend le basculement

Le risque d’une liste établie de mémoire est sa latence. Un fournisseur principal oublié se repère vite. Un transit de secours absent peut dormir pendant des mois. La publication de l’ASPA ne produit pas nécessairement d’incident. Puis une fibre tombe, une maintenance déplace le trafic ou un serveur de routes modifie son comportement. Le chemin rare devient le chemin nécessaire.

Rien dans les sources examinées ne démontre qu’un membre précis de RIPE NCC a subi ce scénario, ni qu’un routeur a rejeté une route à cause d’un objet existant. L’application dépend des logiciels, de la norme en évolution et de la politique de chaque opérateur. L’enjeu est un mécanisme de risque, pas un sinistre attribué.

Une fiche datée réduit ce risque avant qu’il ne devienne une tâche d’incident. Elle attire l’attention sur le voisin rarement vu, permet de comparer l’observation au contrat, et préserve le raisonnement de la personne qui a signé. Elle ne prétend jamais que BGP détient le dernier mot.

RIPE NCC a déjà formulé l’orientation juste : proposer les AS qu’il pense être en amont. Il lui reste à faire de ce « pense » un objet de produit visible. Montrer la source, le temps, le point de vue et l’incertitude ; exiger une qualification humaine ; conserver la différence signée.

Le registre voit des chemins. L’opérateur connaît la relation. Une autorisation crédible commence par la preuve que personne n’a confondu les deux.

Sources