Résumé

  • Le plafond ASPA par défaut de FORT est de 4 000 fournisseurs. Le code étudié compare d’abord les longueurs des deux listes en cours, avant d’en retirer les doublons.
  • En cas de dépassement lors de la fusion, il renvoie un pointeur nul et un compte de zéro, associés au retrait dans le contrat du type. Aucun client touché, retrait livré à un routeur ou annulation de ressource n’a été observé.

Un plafond de fournisseurs semble appeler une question simple : combien d’AS différents reste-t-il dans la liste ? Dans le lancement fixé de FORT, une autre quantité arrive au contrôle avant cette réponse. Le programme additionne les longueurs de deux listes, puis seulement, si le budget le permet, construit leur union.

Prenons deux listes triées pour le même AS client, de 2 500 entrées chacune, dont les membres sont identiques. L’union mathématique comporte 2 500 AS. La somme préalable atteint 5 000 et peut dépasser le plafond par défaut de 4 000. C’est une déduction conditionnelle à partir de la fonction, pas une paire de publications ASPA repérée en service. Les autres contrôles sont supposés satisfaits.

L’introduction à ASPA publiée par LACNIC le 9 septembre 2026 cite FORT parmi les implémentations existantes. ASPA fournit les relations de fournisseurs autorisées par un AS client, plutôt qu’un simple contrôle de l’origine d’une route. Le sujet ici n’est ni le taux d’adoption ni la négociation d’un protocole avec le routeur. Il est la mesure utilisée lorsque des informations qui se recouvrent sont réunies.

Le code est celui de 1.7.0.experimental, publié le 16 juillet et fixé au commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e. L’examen de septembre n’annonce pas un lancement de septembre et ne recense pas les installations actuelles. FORT n’a pas été exécuté pour cet article ; aucun service de production n’a été interrogé et aucun ASPA synthétique n’a été publié.

D’abord l’objet, ensuite la réunion

Le guide donne à aspa.max-providers une valeur par défaut de 4 000 et une plage entière de zéro à 16 380, configurable par argument ou JSON. Il décrit les déclarations d’un client sur l’ensemble des arbres RPKI d’un cycle et indique que les clients dépassant le compte sont invalidés. Le code de configuration confirme les valeurs. Elles ne deviennent pas, par cette analyse, un plafond protocolaire. Zéro n’est pas présenté comme une absence de limite.

Un objet rencontre un premier contrôle. parse_providers refuse sa liste si elle dépasse le budget, avant l’allocation du tableau et le passage au traitement suivant. Les AS doivent être classés en ordre croissant, sans répétition interne, et ne peuvent être l’AS client lui-même. Le recouvrement entre deux listes admises est donc distinct d’un doublon dans un seul objet. La forme des listes ne prouve pas, à elle seule, la validité des signatures et certificats.

La réunion arrive dans la base, où les entrées sont indexées par client. Lorsqu’une entrée du même client existe, add_aspa appelle merge_providers. Celle-ci affecte d’abord à m la somme de old->count et new->count. Si le pointeur de l’ancienne liste est nul, ou si la somme dépasse le plafond, le résultat contient un pointeur nul et un compte de zéro.

Sinon seulement, la fonction alloue la capacité de cette somme et fusionne les listes triées en retirant les répétitions entre elles. Le résultat dédupliqué n’est donc pas la mesure ayant passé le premier contrôle. add_aspa affecte le résultat à la nouvelle entrée et libère le stockage remplacé. L’en-tête du type associe le pointeur nul et zéro au retrait.

Les deux listes identiques de 2 500 illustrent cette chronologie : le contrôle voit 5 000 avant de pouvoir obtenir 2 500 membres différents. Rien dans cet exemple n’établit un client réellement rejeté ou un événement réseau.

Une somme locale, pas le total brut du cycle

Le compte de l’ancienne liste peut déjà résulter d’une fusion dédupliquée. Il ne conserve pas nécessairement toutes les longueurs des objets originaux.

Dans une séquence conditionnelle vers une même cible saine, trois listes identiques de 1 500 entrées donnent d’abord une somme de 3 000, puis une union de 1 500. Avec la troisième, la somme est encore de 3 000. Les listes originales totalisent 4 500 entrées, sans que cette séquence particulière doive dépasser 4 000.

Ce n’est pas une garantie sur le groupement réel des arbres. C’est une distinction entre total original, capacité des deux entrées du moment et nombre de membres différents. Un libellé unique de « nombre de fournisseurs » peut masquer ces trois unités.

La comparaison est strictement supérieure : une somme égale au plafond ne déclenche pas ce test numérique. Les autres contrôles demeurent. Un résultat nul ne prouve pas non plus un dépassement, puisque le pointeur ancien nul constitue une autre condition. L’examen ne couvre pas tous les ordres de fusion et ne promet pas une persistance universelle des marqueurs invalides.

Expliquer ce qui est protégé

Le contrôle préalable est cohérent avec un budget d’allocation défensif : l’espace demandé juste après dépend précisément de la somme. Limiter cette capacité intermédiaire peut avoir un sens même lorsque l’union est petite. C’est une interprétation du code, pas une intention confirmée par le mainteneur ni un résultat de performance. Elle ne suffit pas à qualifier le mécanisme de bogue.

L’opérateur, lui, peut surtout connaître le nombre d’AS distincts dans le résultat. Une clarification utile nommerait le budget protégé : capacité intermédiaire des deux listes ou membres uniques finaux. Modifier les mots et modifier l’ordre du traitement sont deux décisions différentes. Aucune n’est décrite comme adoptée, et relever directement la limite n’est pas la recommandation de cet article.

Enfin, un résultat nul et une convention de retrait ne prouvent ni livraison à un routeur, ni politique appliquée, ni effet sur le trafic. La décision d’un cache sur des données de fournisseurs n’annule pas l’ASN ou l’enregistrement de ressources du client. Le constat porte sur l’admission dans un résultat logiciel, non sur un incident constaté.

Sources

  1. Introduction à ASPA de LACNIC
  2. Lancement FORT 1.7.0.experimental
  3. Guide des paramètres au commit fixé
  4. Analyse des fournisseurs d’un objet ASPA
  5. Fusion des entrées clients et ordre de comptage
  6. Valeurs de configuration et bornes
  7. Type des fournisseurs et convention de retrait