Résumé

  • À APNIC 62, APNIC a expliqué que son interface ASPA hébergée suggère des fournisseurs à partir de RIPE RIS. Ces propositions sont probabilistes, doivent être examinées et risquent davantage d’être trop larges que trop étroites.
  • L’interface teste aussi l’effet d’un changement sur les chemins BGP observés. C’est un contrôle utile du présent, pas la répétition générale de toutes les routes futures.
  • Le projet IETF actuel recommande d’inscrire à l’avance les fournisseurs de secours ou d’urgence afin que la diffusion RPKI ne soit pas prise de vitesse par la propagation BGP. Un fournisseur dormant ne devrait pourtant offrir aucun chemin vivant à l’observateur.
  • APNIC devrait conserver un reçu de provenance et de scénario séparant suggestion observée, déclaration de l’opérateur, candidat rejeté, contrôle des chemins actuels et bascule non exercée.

L’éditeur sait lire le réseau d’aujourd’hui

Un ASPA est une liste courte aux conséquences longues. Le détenteur d’un ASN y désigne les systèmes autonomes autorisés à lui fournir du transit. L’objet est signé dans la RPKI, publié, puis récupéré par des validateurs qui peuvent examiner la cohérence d’un AS_PATH. La difficulté ne réside pas dans l’écriture d’une suite de numéros. Elle tient à la composition exacte de la liste.

La présentation « APNIC RPKI Updates » montre comment APNIC aide ses Membres. L’interface hébergée interroge le service asn-neighbours de RIPEstat, alimenté par le Routing Information Service de RIPE. Elle en tire des fournisseurs possibles, de la même façon que les outils de gestion de routes proposent déjà des objets. APNIC ne survend pas le procédé : les suggestions sont probabilistes, doivent être relues et sont, selon l’exposé, plus souvent sur-inclusives que sous-inclusives.

Une seconde fonction contrôle les modifications soumises. Elle regarde comment les chemins visibles dans BGP seraient affectés par le nouvel ensemble de fournisseurs. Si l’on supprime un ASN qui apparaît dans les routes actuelles, l’opérateur peut être averti avant de publier une attestation incohérente avec le réseau qu’il exploite. Cette barrière est utile précisément parce qu’elle intervient avant la signature.

Mais elle ne voit que ce qui a déjà laissé une trace. Le fournisseur de mitigation DDoS qui n’annonce rien en temps normal, le transit prévu pour reconnecter un segment isolé ou la liaison d’urgence conservée hors service ne produisent pas nécessairement de chemin courant. Leur silence n’est pas une anomalie : c’est la propriété achetée.

RIPE RIS fournit un indice, pas un contrat

La documentation de RIPEstat borne correctement son résultat. L’API recense les ASN voisins observés depuis les collecteurs RIS. Elle peut indiquer la position à gauche ou à droite dans le chemin, le nombre de chemins et de pairs qui ont vu cette adjacence, ainsi qu’un instant ou une fenêtre de validité. Lorsqu’un voisin de gauche n’apparaît qu’en raison d’un lien direct avec un collecteur, il peut être signalé comme uncertain.

Ces métadonnées aident à juger une suggestion. Elles ne tranchent pas la nature économique ou opérationnelle du lien. Une adjacence peut représenter un fournisseur, un client, un pair latéral, un serveur de routes non transparent ou une relation qui change selon la famille d’adresses et les préfixes concernés. Les collecteurs voient une partie documentée du routage mondial ; ils ne voient pas une convention qui n’a pas encore été activée.

Le caractère sur-inclusif devient alors une qualité prudente. Il vaut mieux demander à l’humain d’écarter un pair que de masquer un fournisseur actif dont la disparition rendrait des chemins Invalides. Ce choix ne promet toutefois pas l’exhaustivité. Même une observation parfaite du présent ne peut faire apparaître une relation conçue pour le futur.

L’éditeur doit donc conserver deux colonnes intellectuelles. Dans la première : « cet ASN a été observé près du mien, à cet instant, depuis ces collecteurs ». Dans la seconde : « cet ASN est autorisé comme fournisseur, qu’il transporte ou non aujourd’hui ». La mesure éclaire la déclaration ; elle ne peut pas la remplacer.

Le projet IETF place l’urgence avant la route

Les versions gelées des travaux IETF donnent au problème une forme temporelle. La révision 29 du profil ASPA décrit un objet unique par Customer AS contenant tous les fournisseurs, y compris les serveurs de routes non transparents concernés. L’unicité réduit le risque de course pendant les mises à jour.

La révision 28 du texte sur la vérification va plus loin. Elle envisage explicitement des fournisseurs de secours : service temporaire de mitigation DDoS ou fournisseur d’urgence chargé de relier des segments isolés. Elle recommande de les ajouter à l’ASPA à l’avance, afin d’éviter une course entre la diffusion mondiale de l’objet et la propagation de la route.

Voici le paradoxe. Tant que la bascule n’a pas eu lieu, le contrôle BGP n’a pas de chemin à exercer. Dès que la route apparaît, il est peut-être trop tard pour commencer à publier l’autorisation. L’information décisive existe pendant un intervalle où elle relève du plan de l’opérateur et non de l’observation du réseau.

Cette analyse ne contredit pas l’ancienne mise en garde selon laquelle un ASPA prouve une autorisation, pas un transit effectif. Elle en donne le miroir : l’absence de transit observé ne prouve pas l’absence d’autorisation nécessaire. Les deux directions protègent contre la même erreur, celle qui consiste à faire d’un graphe visible le double exact du graphe voulu.

Les documents IETF restent des Internet-Drafts. Ils peuvent changer et ne sont pas des RFC définitives. APNIC ne prétend pas non plus que son contrôle couvre les chemins futurs. Sa présentation demande au contraire des retours sur les suggestions et la validation. Le constat se limite donc à une différence de preuve, pas à un incident.

Un voyant vert peut porter trois sens incompatibles

Imaginons un ASN client qui utilise A et B, et garde C pour la mitigation d’urgence. RIS observe A et B, ainsi qu’un pair D dans certains chemins. L’éditeur propose A, B et D. L’opérateur retire D et ajoute C manuellement.

Le contrôle courant peut montrer qu’A reste nécessaire, que B n’est visible qu’en IPv6 ou que D provient d’une observation incertaine. Il peut constater qu’aucun des chemins examinés n’entre en conflit avec la liste finale. Il ne peut pas démontrer que C annoncera les bons préfixes, conservera le chemin prévu, disposera de la capacité promise ou ne sera activé qu’après diffusion de l’ASPA.

L’expression « aucun conflit courant détecté » est complète. « Bascule validée » ne l’est pas. Entre les deux se trouvent un contrat, un plan d’activation, une répétition et la preuve que l’objet publié a atteint les parties qui s’y fient.

Sans cette distinction, une coche verte voyage mal. Dans un ticket, « ASPA validé » peut signifier que l’objet est bien formé, que les routes présentes sont compatibles ou que le secours a été testé. Ces trois affirmations appellent trois jeux de preuves.

Un reçu sobre pour une route absente

APNIC n’a pas besoin de publier les contrats de transit ni le plan de défense d’un Membre. Un reçu interne peut protéger la décision avec peu de données.

Pour chaque ASN candidat, il indiquerait l’origine : suggestion RIS, fournisseur actif ajouté manuellement, fournisseur de secours, fournisseur d’urgence ou serveur de routes non transparent. Pour une suggestion, il conserverait l’heure de requête, la version ou l’empreinte de la réponse, la position observée, le marqueur d’incertitude, le nombre de chemins et le nombre de pairs. Un rejet recevrait une raison bornée — pair, client, artefact d’observation, serveur transparent ou cas à examiner — sans exposer les conditions commerciales.

Pour un fournisseur dormant, le reçu enregistrerait la classe d’activation, les familles d’adresses concernées, le rôle responsable, la date du dernier exercice ou examen sur table et la prochaine révision. Il dirait explicitement que ce fournisseur n’a pas été exercé dans l’ensemble BGP observé.

Le contrôle de chemins conserverait sa fenêtre d’observation, une empreinte des chemins examinés, la liste proposée et son résultat. Enfin, la publication serait jointe à la décision : confirmation humaine, identité de l’objet, heure de publication et première visibilité vérifiée depuis une partie qui s’y fie. Si l’urgence commence avant cette visibilité, la chronologie resterait honnête.

Le tableau de bord DASH, désormais enrichi d’un état ASPA, offre un emplacement naturel pour séparer publié, observé, revu en scénario et à réexaminer. Le chiffre de 293 ASPA présenté à APNIC 62 — 257 hébergés et 36 délégués — mesure la création d’objets à cet instant. Il ne compte ni les réseaux validants, ni la complétude des listes, ni les plans de secours exercés.

L’interface conseille ; l’opérateur décide

La vérification ASPA applique une fonction à des paires ordonnées d’ASN. Un fournisseur inscrit peut produire une attestation positive ; un fournisseur absent d’un ASPA valide peut produire une réponse négative ; l’absence d’objet valide reste une absence d’attestation. Le projet distingue notamment les états Invalid et Unknown, tout en laissant la politique de mitigation au réseau récepteur.

La chaîne d’autorité doit conserver cette pluralité. RIPE RIS observe. APNIC suggère, avertit et publie pour ses Membres. Le détenteur de l’ASN autorise. Le validateur calcule. Le réseau récepteur décide de la route. Aucun voyant dans MyAPNIC ne doit absorber tous ces verbes.

Le fournisseur de secours rend cette séparation visible parce que son utilité précède son trafic. APNIC a déjà construit le contrôle du cas ordinaire. Pour couvrir l’exception sans fausse assurance, l’interface doit pouvoir dire : autorisé, non observé, scénario examiné, publication vérifiée.

Sources