Résumé

  • Breizh-IX dit reconstruire chaque nuit des filtres stricts à partir des objets de route, vérifier les ROA et respecter l'indication « Never via route servers » de PeeringDB. Le résumé de son intervention à RIPE 93 ajoute une question : le client veut-il que le serveur republie sa route ?
  • PeeringDB décrit cette indication comme un signal que le point d'échange doit consulter et appliquer. L'entrée dans une base et la décision effective du serveur appartiennent à deux moments différents.

Le troisième verrou n'est pas un nombre

Un membre remet son AS-SET à un point d'échange. Le logiciel développe la liste, retrouve les objets de route et fabrique un filtre. Une route passe. La mécanique a l'air de répondre à tout, jusqu'à cette question très peu mécanique : le membre voulait-il que cette route soit redistribuée aux autres participants ?

Evann Dreumont et Alarig Le Lay, de Breizh-IX, ont inscrit cette question dans le résumé officiel de leur présentation RS-API programmée le 28 octobre à RIPE 93. Ils énumèrent trois vérifications. La route doit figurer dans l'AS-SET du client selon l'IRR. Le volume annoncé doit rester cohérent, car un ensemble imbriqué peut importer une énorme portion de la table mondiale. Enfin, le client doit vouloir la republication par le serveur. La troisième vérification ne se déduit d'aucune des deux premières.

L'enjeu vient de la fonction même du serveur. RFC 7947 décrit un intermédiaire qui échange les annonces BGP de plusieurs réseaux à un point d'échange. Chaque participant évite ainsi une forêt de sessions bilatérales. L'économie d'administration est réelle; l'erreur de périmètre aussi. Une route offerte à plusieurs pairs traverse une décision commune, prise dans la configuration du serveur. Un objet IRR renseigne une politique de routage déclarée. Il ne choisit pas les destinataires de l'annonce à la place du membre.

Le choix publié doit devenir une règle en service

Le site de Breizh-IX détaille les contrôles déjà revendiqués par l'association rennaise de bénévoles. La génération nocturne des listes utilise bgpq4 en mode strict : pas d'objet route, pas d'acceptation du préfixe. Les serveurs vérifient les ROA des RIR, l'attribut OTC et la préférence « Never via route servers »; le second contrôle aussi les ASPA. Voilà un inventaire de pratiques annoncé par l'exploitant. Le résumé de RS-API expose le travail supplémentaire qu'il veut automatiser.

La FAQ de PeeringDB appelle info_never_via_route_servers un indice adressé aux points d'échange. Elle leur demande de consulter régulièrement la donnée et de l'honorer. Ce mot « indice » est capital. La personne qui modifie son profil peut exprimer un refus. Le service de base de données peut le conserver. L'exploitant du point d'échange doit encore le lire, en faire une règle et vérifier que la règle tourne effectivement sur le serveur.

Deux horloges peuvent alors se désaccorder. Breizh-IX dit refaire la liste IRR chaque nuit; son site ne donne pas, dans les sources examinées, un relevé public des instants où chaque préférence PeeringDB est récupérée et appliquée. Si le membre change son choix entre deux rafraîchissements, le serveur peut encore opérer sur l'ancienne valeur. Ce scénario décrit un contrôle à auditer, aucun incident constaté chez Breizh-IX. L'information décisive serait une trace liant l'heure du changement à l'heure du filtre en service.

La vérification du volume a son propre piège. Développer correctement un AS-SET ne rend pas son contenu raisonnable. Un ensemble inclus peut agrandir brutalement la liste; un plafond de préfixes trop généreux laisse passer l'anomalie. RS-API est présenté comme un moyen de rapprocher des entrées dispersées et d'éviter le contrôle manuel permanent. Le résumé ne publie ni code, ni taux d'erreur, ni preuve de déploiement. Il donne en revanche un bon cahier de questions pour juger le futur outil.

Une décision exportée mérite son reçu

Pour chaque génération de politique, un membre devrait pouvoir retrouver l'AS-SET et les objets retenus, la taille obtenue, le plafond appliqué, la valeur et la date du choix PeeringDB, puis les pairs auxquels la route a été offerte. Si une route est rejetée, le même reçu explique le refus. La gouvernance n'a pas besoin d'une grande cérémonie; elle a besoin d'une chaîne qu'un client peut contester avant qu'une erreur ne se répète.

La règle de secours est le point à rendre public. Que fait le serveur quand le profil n'est pas disponible, quand le choix est ancien, ou quand les différentes entrées se contredisent ? Les documents étudiés ne donnent pas cette règle pour RS-API. Une politique datée, suivie d'une trace de son exécution, ferait avancer le jugement. Compter les préfixes est un métier de machine. Décider qui parle au nom du membre reste un mandat à documenter.

Sources