Summary

  • bgpipe, conçu par Paweł Foremski, peut se placer entre deux interlocuteurs BGP et appliquer des contrôles d'origine et de chemin. Le portrait RIPE 92 présente ce travail comme un moyen d'ajouter ROA et ASPA aux routeurs existants.
  • La documentation ASPA du projet exige le rôle du voisin. En mode --role auto, l'absence de capacité BGP Role dans son message OPEN fait sauter la validation ASPA de la session. Pour la sécurité, le projet préconise un rôle explicite.

Attendre le fournisseur du routeur est une méthode commode pour attendre encore. Paweł Foremski a construit une autre porte d'entrée : bgpipe parle BGP, se place entre deux équipements et traite les annonces dans une chaîne de fonctions. Le vieux routeur reste en place. Le contrôle peut passer dans le flux avant que l'annonce ne lui parvienne.

Mais ajouter une boîte ne lui donne pas la connaissance de la relation commerciale et opérationnelle entre deux réseaux. Le contrôle d'origine ROV vérifie si un AS est autorisé par les données ROA validées à annoncer un préfixe. ASPA examine le chemin des AS et les relations fournisseur-client. Le guide ROV décrit des états par préfixe ; ASPA classe le chemin entier en VALID, UNKNOWN ou INVALID. UNKNOWN signifie que l'attestation manque à certains endroits. Le mot ne constate pas une fuite.

Pour juger ce chemin, bgpipe doit savoir qui est le voisin. L'exploitant peut inscrire explicitement client, fournisseur, pair ou serveur de routes. En choisissant --role auto, il accepte au contraire le rôle annoncé par le voisin dans OPEN. Le voisin qui ne transmet pas cette capacité échappe alors au contrôle ASPA de la session, avec un avertissement dans le journal. Celui qui se présente comme fournisseur ou serveur de routes obtient une procédure différente, parfois plus permissive. Le projet dit clairement de réserver auto aux pairs de confiance et aux usages d'étude.

La promesse utile de Foremski est donc précise : déplacer le point où la règle peut s'exécuter, sans attendre un nouveau firmware. Cette règle reste à écrire. Il faut tenir la liste des voisins, fixer leur rôle et choisir entre retirer, abandonner ou conserver une annonce jugée INVALID. Conserver permet de mesurer sans changer le routage ; retirer ou abandonner agit sur la session. Ce choix appartient à l'exploitant qui recevra les appels quand le trafic bougera.

L'ordre des étapes a lui aussi une conséquence. Un contrôle ROV placé avant ASPA et réglé pour abandonner un UPDATE retire ce message du flux avant qu'ASPA puisse le compter. Un tableau de bord basé sur les seuls compteurs ASPA donnerait alors une image incomplète. Le manuel ASPA conseille de placer ASPA d'abord si l'on veut mesurer tous les UPDATE.

Les documents du projet ne donnent pas le relevé d'un réseau où cette configuration a arrêté une fuite déterminée. Il faudrait le rôle configuré, le message OPEN, l'état du cache RPKI et les annonces effectivement transmises. Le point déjà visible est moins confortable qu'une case « sécurité activée » : Foremski a rendu le contrôle accessible aux vieux routeurs, et l'exploitant doit encore empêcher son voisin de définir les règles de l'examen.

Sources : RIPE 92 RACI · présentation du projet · guide ASPA · guide ROV.