Résumé

  • ASPA vérifie la forme d’un AS_PATH à partir de listes de fournisseurs signées, du rôle local du voisin et d’un algorithme montant ou descendant ; le résultat ne prouve ni la sélection de route ni la responsabilité d’un AS.
  • La révision 28 recommande de rendre Invalid inéligible tout en le conservant dans Adj-RIB-In, et d’accorder à Unknown la même préférence qu’à Valid afin que l’absence de données ne devienne pas une accusation.

Le saut qui échoue n’est pas un verdict

Imaginons un chemin où le couple (AS x, AS y) est le premier à répondre Not Provider+. L’AS client possède une attestation valide, mais sa liste ne contient pas y. Le routeur a une contradiction reproductible. Il peut l’enregistrer, rendre la route inéligible et conserver l’annonce pour une réévaluation ultérieure.

Il ne sait pourtant pas nécessairement qui a créé la fuite. La liste peut être obsolète, un fournisseur légitime peut manquer, une migration d’ASN peut être incomplète ou un AS en amont peut avoir modifié le chemin. La révision 28 le dit expressément : le routeur qui journalise les sauts fautifs ne peut pas toujours déterminer l’AS à l’origine de la fuite.

Le document, publié le 24 août 2026 et expirant le 25 février 2027, est un Internet-Draft actif du groupe SIDROPS. Datatracker indique WG Consensus: Waiting for Write-Up et I-D Exists côté IESG. Ce n’est ni un RFC, ni une approbation finale, ni la preuve d’un déploiement mondial.

Ce que signe le client

Le profil ASPA permet au détenteur d’un numéro d’AS client de signer la liste de ses AS fournisseurs. La liste inclut le numéro d’un serveur de routes non transparent lorsque celui-ci apparaît dans l’AS_PATH. L’attestation est asymétrique : le client autorise un fournisseur. Elle ne publie pas le contrat commercial, ne prouve pas qu’une session fonctionne et ne décrit pas forcément les exceptions par préfixe.

Un seul objet est recommandé. Si plusieurs objets valides existent, le vérificateur forme l’union des ensembles de fournisseurs. Cette union évite qu’un objet partiel efface un fournisseur pendant une transition, mais elle élargit aussi l’ensemble accepté. La validité cryptographique ne garantit donc pas la fraîcheur ni l’exhaustivité opérationnelle.

Pour chaque couple ordonné, la fonction d’autorisation renvoie trois valeurs. Provider+ signifie que le fournisseur figure dans l’ensemble valide. Not Provider+ signifie qu’un ensemble valide existe mais l’omet. No Attestation signifie qu’aucun objet n’a été obtenu ou qu’aucun n’est cryptographiquement valide.

La différence entre les deux dernières réponses est centrale. Une omission dans une liste qui se veut complète est une preuve négative. L’absence d’objet est une absence de preuve. Confondre les deux transformerait un déploiement partiel en motif de coupure.

Les rampes bornent une forme possible

Après reconstruction de l’AS_PATH pour les AS à quatre octets et suppression des répétitions consécutives, l’algorithme cherche des rampes client-vers-fournisseur. Provider+ allonge la borne minimale. No Attestation arrête la certitude sans fermer toutes les possibilités. Not Provider+ fixe une borne maximale.

Si même les rampes maximales ne couvrent pas le chemin, le résultat est Invalid. Si elles pourraient le couvrir mais que les attestations manquantes empêchent de le démontrer, il est Unknown. Si les bornes minimales suffisent, il est Valid.

Ce calcul vérifie une propriété de forme avec les objets disponibles. Il ne rejoue pas la propagation réelle de l’UPDATE. Un fournisseur peut encore manipuler certains chemins de ses clients sans être détecté. L’ajout ou le retrait de répétitions d’AS n’est pas détecté. Un résultat Valid n’est donc pas une signature complète de l’histoire du chemin.

Le sens vient de la relation locale

Une route reçue d’un client ou d’un pair suit l’algorithme amont, qui n’accepte qu’une rampe montante. Une route reçue d’un fournisseur suit l’algorithme aval, qui autorise une montée puis une descente. Le routeur doit connaître le rôle local de la session avant de choisir.

Les rôles BGP de la RFC 9234 peuvent être configurés et vérifiés pendant l’OPEN. Ils rendent la sélection de l’algorithme plus explicite, mais ils ne transforment pas une relation complexe en fait universel. Lorsque deux AS ont des rapports différents selon les préfixes, la révision 28 préfère des sessions séparées ou un choix par préfixe. À défaut, elle permet l’algorithme aval, plus permissif, pour éviter les faux positifs.

Cette décision protège la continuité. Elle réduit en même temps le pouvoir discriminant de la validation. Un audit doit conserver le rôle, le préfixe et l’algorithme effectivement utilisés ; l’étiquette finale seule ne suffit pas.

Unknown partage une politique, pas une preuve

La politique recommandée traite Unknown au même niveau de préférence que Valid. Cela ne rend pas le chemin Unknown positivement autorisé. Cela indique que l’opérateur refuse de pénaliser le silence du système de preuves.

La sélection BGP continue ensuite avec la préférence locale, la longueur du chemin, MED et les autres règles. La route choisie peut entrer dans Loc-RIB, puis un prochain saut peut être programmé dans le FIB. Aucune de ces étapes ne découle automatiquement de l’état ASPA, et aucune ne démontre la livraison des paquets.

À l’inverse, Invalid signifie que la forme maximale permise par les attestations ne suffit pas. Il ne signifie pas que le saut journalisé est coupable. Présenter un compteur Invalid comme une liste d’auteurs de fuites serait une erreur de catégorie.

Les objets et les routes n’avancent pas au même rythme

Un client peut activer un fournisseur de secours anti-DDoS avant que tous les relying parties aient reçu le nouvel ASPA. Un fournisseur manquant peut alors rendre une route légitime Invalid. Un fournisseur conservé par erreur produit le risque opposé : la validation devient trop permissive.

Les dépôts publient, les validateurs récupèrent, les caches transmettent et les routeurs importent. Chaque étape possède son temps et son identifiant de version. C’est pourquoi l’objet de secours doit être enregistré avant l’usage et pourquoi les objets doivent rester identiques pendant une migration d’autorité de certification.

Une route Invalid doit rester dans Adj-RIB-In : un nouvel objet peut changer le résultat sans nouvel UPDATE BGP. La conservation n’est pas de l’indécision. C’est la condition qui permet à la politique de réagir à une preuve corrigée.

Les contrôles restent complémentaires

Une ROA autorise l’origine d’un préfixe. ASPA atteste des relations client-fournisseur utilisées pour tester la forme d’un chemin. BGPsec peut prouver la succession signée d’une annonce sans détecter à lui seul une violation valley-free. L’attribut OTC peut empêcher une fuite initiée localement qu’ASPA ne voit pas dans les segments précédents.

Une route peut donc avoir une origine valide et un chemin ASPA Unknown. Elle peut passer ASPA sans signatures BGPsec. Elle peut passer les deux et être rejetée par une politique commerciale locale. Même installée, elle peut conduire à un échec de transfert.

La chaîne de preuves utile relie la révision normative, le hash de l’objet, l’instant de validation, le rôle du voisin, l’AS_PATH brut et reconstruit, chaque résultat de couple, l’algorithme, la politique appliquée, Loc-RIB, FIB et enfin les observations du trafic.

La doctrine de Lu Heng impose cette retenue : une attestation de coordination peut être autoritaire pour son assertion limitée sans devenir autorité sur le code exécuté, la décision locale ou le résultat. ASPA est plus précieux lorsque sa frontière reste visible.

Ce que les sources ne démontrent pas

Les sources figées établissent les algorithmes proposés, la politique recommandée et leurs limites déclarées. Elles ne démontrent ni la conformité d’une version logicielle, ni l’effet d’un déploiement, ni l’arrêt d’une fuite observée. Cet Article n’attribue aucun incident. Il explique pourquoi le diagnostic d’une contradiction et l’accusation d’un acteur doivent rester deux actes différents.

Sources