Résumé

  • L’annonce de LACNIC du 20 juillet affirme que FORT 1.7.0 valide les objets ASPA et transmet ces informations aux routeurs ; elle précise aussi que la fonction reste expérimentale, ASPA n’étant pas encore un standard officiellement publié.
  • Dans la livraison 1.7.0.experimental, --server.max-rtr-version vaut 0 par défaut, alors que le guide associé réserve les ASPA à RTRv2. La sortie distincte --output.aspa est elle aussi désactivée par défaut.
  • Une preuve d’activation doit séparer le code disponible, la configuration, la version négociée, les objets acceptés, l’état calculé du chemin et la politique de routage appliquée.

La nouveauté tient dans une phrase ; son activation tient dans plusieurs états.

Le billet de LACNIC présente FORT 1.7.0 comme une version qui valide les objets ASPA déjà présents dans certains dépôts RPKI et partage ces informations avec les routeurs. La publication du projet, datée de quatre jours plus tôt, porte le nom plus précis 1.7.0.experimental. Elle annonce ASPA et RTRv2, puis indique que la version RTR maximale du serveur reste fixée à zéro par défaut.

Le billet décrit ce que le logiciel sait faire. La note de version décrit son comportement avant décision de l’exploitant. Ces deux propositions ne permettent pas de déduire la configuration d’un réseau réel.

LACNIC ne dissimule pas l’incertitude normative : le billet dit qu’ASPA n’est pas encore un standard publié et peut évoluer. Le projet explique aussi son choix prudent. FORT ne produit actuellement pas de clés de routeur, ce qui retire à RTRv1 sa fonction supplémentaire dans ce cas, et RTRv2 continue de changer. La question n’est donc pas de condamner le zéro, mais de rendre observable le passage entre la fonction livrée et la décision de routage.

Trois commandes, trois périmètres

Le guide figé à la version publiée distingue nettement les commandes.

Réglage Valeur par défaut Périmètre
--aspa.max-providers 4 000 Nombre maximal de fournisseurs qu’un ASN client peut déclarer par cycle de validation
--output.aspa NULL (désactivé) Écriture des ASPA valides dans un fichier JSON
--server.max-rtr-version 0 Version RPKI-to-Router la plus élevée négociable avec les clients

Le premier est une limite de validation. Le deuxième ouvre un export. Le troisième expose un protocole aux routeurs. L’un n’active pas automatiquement les deux autres.

Le guide rappelle que RTRv0 transporte les enregistrements de validation de préfixe, RTRv1 ajoute les clés de routeur et RTRv2 ajoute les ASPA. Avec les valeurs initiales, FORT peut donc valider un objet en interne ; il peut l’exporter si un chemin est configuré ; mais une session établie en version 0 ne peut pas transporter le PDU ASPA de version 2.

Cette lecture ne prouve pas qu’aucun exploitant n’a choisi 2. Elle établit uniquement la portée du réglage distribué par défaut.

La négociation est un fait à enregistrer

La révision 27 du projet RTRv2 demande au routeur de commencer avec la version la plus élevée qu’il implémente. Le cache peut ouvrir la session à cette version ou, selon les capacités, à une version compatible inférieure. Dans ce dernier cas, les fonctions des versions supérieures deviennent indisponibles pour la session.

Relever le plafond à 2 n’est donc qu’une intention. Le client doit connaître v2, la demander et achever la négociation à ce niveau. Il faut ensuite recevoir des objets utiles, calculer l’état du chemin et appliquer une politique. Un fichier de configuration ne prouve pas le dialogue ; le dialogue ne prouve pas la décision de route.

La chaîne peut s’interrompre au niveau du binaire, de la validation, de l’export, du plafond, du client, de la couverture ASPA, du calcul ou de la politique. Chacune de ces situations produit le même raccourci verbal — « ASPA ne fonctionne pas » — mais exige une réparation différente.

Valide ne désigne pas toujours la même chose

Le profil d’objet ASPA définit l’attestation signée par le détenteur de l’ASN client pour autoriser des ASN fournisseurs. La relying party valide cet objet. Elle n’a pas encore évalué le chemin BGP reçu par un routeur.

Le projet de vérification ASPA intervient ensuite et produit Valid, Unknown ou Invalid. Il recommande de rendre Invalid inéligible et de traiter Unknown au même niveau de préférence que Valid, tout en laissant la politique de mitigation précise à l’exploitant.

Un nombre d’objets validés mesure le cache. Une session v2 mesure le transport. Les trois compteurs mesurent le calcul. Seules la politique, la RIB et l’exécution indiquent l’effet. Transporter une autorisation ne signifie pas qu’une route a été refusée.

Il serait tout aussi abusif de conclure que v0 signifie absence de sécurité. Les VRP restent transportés, et l’export peut alimenter une expérimentation. La conclusion défendable est plus étroite : la version contient la capacité ASPA, mais l’acheminement et la mitigation restent des choix explicites.

La révision fait partie de la provenance

La documentation identifie draft-ietf-sidrops-8210bis-25 comme base du code RTRv2. À la date de recherche, la révision 27 était courante ; le profil ASPA était en révision 29 et l’algorithme de vérification en révision 28.

Cet écart ne prouve aucune incompatibilité. Il peut s’agir de corrections rédactionnelles ou de changements plus profonds ; seule une comparaison testée tranche. Il prouve toutefois qu’une mention générique de RTRv2 ne suffit pas pour reproduire une expérience. Il faut la révision, le commit, le paquet et les clients testés.

RFC 8210 demeure la norme publiée pour la version 1. Le PDU ASPA appartient encore au travail de version 2. Voilà pourquoi le réglage conservateur se comprend, et pourquoi le futur changement de réglage doit conserver sa trace.

Un compteur de téléchargements ne remplace rien de cela : télécharger n’est pas installer ; installer n’est pas exécuter ; exécuter n’est pas négocier v2 ; négocier n’est pas mitiger.

Une fiche de version, un reçu d’exploitation

La fiche publique doit préciser tag, commit, paquets et empreintes ; révisions du profil, de RTRv2 et de la vérification ; valeurs initiales, limites, écarts connus, clients testés, remplacement et retour arrière. Elle ne requiert aucune télémétrie de réseau.

Le reçu local relie l’empreinte du paquet, le démarrage et l’empreinte de configuration au plafond RTR. Il consigne les clients par version négociée, le dernier cycle, les ASPA acceptés et rejetés par motif, l’état et l’empreinte de l’export, le mode de vérification, les comptes de chemins, la politique de mitigation et le rollback.

Les identités de routeurs et la topologie peuvent rester secrètes. Des agrégats par version et classe de motif suffisent pour une communication publique. Le détail peut être conservé pour l’audit et l’incident.

La jonction repose sur l’empreinte du paquet, la révision implémentée et l’empreinte de configuration. Sans elles, la fiche décrit un possible et le reçu un processus sans identité. Avec elles, le passage en production devient vérifiable.

Ce que les sources ne montrent pas

Le dossier ne révèle ni le nombre d’installations, ni les plafonds choisis, ni les sessions v2, ni les objets utiles, ni les routes écartées. Il ne démontre pas que l’annonce est fausse, que v2 devrait être activée pour tous, ou que les révisions 25 et 27 sont incompatibles.

ASPA n’est pas davantage une défense universelle. Il fournit une autorisation de fournisseur et un moyen de détecter certaines fuites ; il ne valide pas le plan de transfert, ne supprime pas Unknown et ne retire pas à l’opérateur son autorité locale.

Le constat exact suffit : FORT 1.7.0.experimental implémente ASPA et RTRv2 ; son plafond routeur vaut 0 ; son export ASPA est désactivé ; la politique finale appartient au réseau. La bonne question n’est plus « ASPA est-il pris en charge ? », mais « quelle compilation, quel projet, quelle session, quel état et quelle action ? ».

Sources