Résumé

  • Les RFC 6472 et 9774 suivent une même évolution normative : une recommandation adressée aux émetteurs devient une interdiction par défaut d’annoncer AS_SET ou AS_CONFED_SET, assortie d’un traitement à la réception et de précautions explicites pour l’agrégation, l’origine RPKI et les boucles de transfert.
  • La RFC 8205 place BGPsec sur une autre surface opérationnelle : négociation par sens et famille d’adresses, prise en charge des numéros d’AS sur quatre octets, signatures liées aux ressources RPKI, revalidation lorsque cet état change et limites nettes entre preuve du plan de contrôle, choix local et comportement réel du transfert.

Un dossier de standards, pas une biographie extrapolée

Les trois documents retenus permettent une attribution précise et volontairement étroite. Kotikalapudi Sriram est coauteur, avec Warren Kumari, de la RFC 6472, publiée comme meilleure pratique courante. Il est coéditeur, avec Matthew Lepinski, de la RFC 8205, spécification de BGPsec. Il est enfin coauteur de la RFC 9774 avec Warren Kumari, Lilia Hannachi et Jeffrey Haas.

Cette chronologie documentaire montre une participation collaborative à la définition de comportements BGP, mais elle ne permet pas d’inférer un poste actuel, une responsabilité opérationnelle dans un réseau, la rédaction exclusive d’un mécanisme ou une autorité personnelle sur le consensus de l’IETF.

Cette distinction n’est pas une précaution périphérique. Dans un protocole interdomaines, la règle écrite, le logiciel qui l’implémente, la configuration choisie par l’opérateur et le résultat observé dans le plan de transfert appartiennent à des couches différentes. Un coauteur contribue au texte soumis au processus collectif ; une implémentation décide comment rendre ce texte exécutable ; un opérateur accepte ou refuse les capacités, sélectionne une politique et organise une transition ; les routes et les paquets fournissent ensuite les faits observables.

Réunir ces rôles sous une seule notion de « contrôle » produirait précisément le type d’ambiguïté que les documents cherchent à réduire dans AS_PATH.

Ce qu’un ensemble non ordonné efface dans AS_PATH

AS_PATH est à la fois un historique de propagation et une donnée utilisée par les décisions BGP. Lorsqu’un routeur agrège plusieurs routes plus spécifiques en une route moins spécifique, il combine des chemins qui peuvent différer. AS_SET permettait de conserver, sous forme d’ensemble non ordonné, les systèmes autonomes traversés par les routes contributrices. AS_CONFED_SET jouait un rôle analogue pour les numéros d’AS membres d’une confédération locale. L’ensemble signale que certains AS ont participé aux chemins d’origine, mais il ne préserve pas leur ordre.

Cette perte d’ordre n’est pas seulement esthétique. Une origine doit être suffisamment déterminée pour qu’un mécanisme de sécurité puisse la comparer à une autorisation de ressource. Un ensemble de plusieurs AS ne désigne pas un AS d’origine unique. Il complique également l’interprétation de la longueur et du parcours du chemin, tout en conservant dans les implémentations du code destiné à un cas rarement rencontré.

La RFC 6472 relève que l’agrégation avec AS_SET était très peu utilisée sur l’Internet public dans les données historiques qu’elle examinait et qu’elle apparaissait souvent sous des formes incorrectes, par exemple avec un seul AS ou avec des numéros réservés. Le texte ne transforme pas cette observation ancienne en mesure actuelle : il l’utilise pour comparer le faible bénéfice de réduction de table à la complexité ajoutée.

La RFC 6472 : une recommandation centrée sur l’émetteur

La RFC 6472 formule d’abord une règle opérationnelle pour les annonces nouvelles : les opérateurs sont invités à ne plus générer d’annonces contenant AS_SET ou AS_CONFED_SET. Pour les routes déjà annoncées avec ces segments, le document recommande de les retirer, puis de réannoncer les préfixes constitutifs plus spécifiques sans AS_SET. Cette opération revient à défaire l’agrégation concernée. Elle peut augmenter le nombre de routes annoncées et modifier le comportement de trafic ; le texte rappelle donc qu’un opérateur doit en comprendre toutes les conséquences avant d’agir.

La portée de cette recommandation est importante. La RFC 6472 se concentre sur le côté émetteur. Elle observe que de nouvelles technologies de sécurité peuvent ne pas prendre en charge les routes contenant ces ensembles et que des opérateurs peuvent les filtrer, mais elle ne prescrit pas alors une politique générale au récepteur. Ce partage empêche de lire rétrospectivement le document comme s’il imposait déjà le comportement complet de la RFC 9774. Une recommandation de ne plus produire un état et une exigence de le traiter d’une manière déterminée à la réception sont deux niveaux normatifs distincts.

Le texte conserve aussi la mémoire d’un avantage que pouvait fournir AS_SET. Dans certains cas rares d’agrégation, la présence des AS contributeurs permettait à la détection de boucle d’AS_PATH d’empêcher la réacceptation d’un agrégat par l’un de ces AS. Retirer l’ensemble sans adapter le filtrage peut donc retirer en même temps cette protection. La RFC 6472 ne promet pas une migration sans risque ; elle indique au contraire que les agrégats doivent être formés avec soin et que certaines pratiques fondées sur des correspondances exactes ne peuvent pas être simplement reproduites sans AS_SET.

La RFC 9774 : du conseil à la règle par défaut

La RFC 9774 reprend cette ligne et l’élève au rang d’exigence de standard. Sauf configuration explicite contraire par l’opérateur, notamment pendant une phase de transition, un locuteur BGP ne doit pas annoncer de message UPDATE contenant AS_SET ou AS_CONFED_SET. Lorsqu’il reçoit un tel segment dans AS_PATH ou AS4_PATH, il doit appliquer le traitement « treat-as-withdraw ». La route fautive est ainsi traitée comme retirée sans que l’erreur doive nécessairement faire tomber toute la session.

Deux bornes sont à retenir. Premièrement, la règle est le comportement par défaut d’un locuteur conforme, et non la preuve que tous les réseaux l’ont déjà déployée. Deuxièmement, l’exception de configuration explicite reconnaît qu’une transition peut nécessiter une période contrôlée. Cette exception n’annule pas la dépréciation ; elle place la décision et sa durée sous la responsabilité visible de l’opérateur. Une politique de transition devient alors un état à inventorier, à limiter dans le temps et à tester, plutôt qu’une tolérance implicite impossible à distinguer d’un oubli.

Le comportement de réception a une conséquence possible sur la joignabilité. Si un voisin continue d’envoyer un chemin contenant un ensemble et si le récepteur applique « treat-as-withdraw », la route peut cesser d’être utilisable à ce point d’échange. Les RFC ne mesurent pas l’ampleur de ce cas ni sa fréquence. Elles indiquent en revanche exactement où rechercher la cause : dans la présence du segment interdit, la configuration de transition, le traitement appliqué et les routes alternatives disponibles. Cette précision est plus utile qu’une promesse générale de sécurité, car elle rend l’échec attribuable à un état de protocole concret.

L’agrégation brève ne suffit pas si l’origine varie

Supprimer AS_SET ne résout pas automatiquement le problème de sens. Une agrégation dite « brève » peut conserver la plus longue séquence initiale commune aux AS_PATH des routes contributrices et abandonner l’ensemble qui aurait contenu les autres AS. Lorsque les routes contributrices apparaissent ou disparaissent, cette séquence commune peut changer. L’AS situé à droite du chemin agrégé, interprété comme origine, peut alors varier sans que le préfixe agrégé lui-même change.

Cette variabilité entre directement en tension avec la validation d’origine RPKI. Pour qu’un préfixe agrégé soit validable de façon stable, le détenteur de la ressource doit pouvoir publier une autorisation d’origine correspondant à l’AS présenté. Si plusieurs origines peuvent émerger au gré de la disponibilité des routes contributrices, il faudrait prévoir les différentes origines possibles, avec un risque d’écart entre l’état anticipé et l’état réellement annoncé. L’enjeu n’est donc pas seulement de retirer un type de segment ; il est de produire une origine déterministe.

La « consistent brief aggregation » proposée par la RFC 9774 répond à cette contrainte. L’implémentation doit être configurée pour tronquer AS_PATH après l’occurrence la plus à droite d’un AS d’origine choisi et stable pour l’agrégat. Cet AS peut être celui qui effectue l’agrégation. Une ROA doit correspondre au préfixe agrégé et à cette origine voulue. Si la troncature retire des informations qu’une agrégation ordinaire aurait conservées, l’attribut ATOMIC_AGGREGATE devrait accompagner la route. Cet attribut ne reconstitue pas le chemin perdu ; il signale qu’une agrégation a retiré de l’information.

Le prix caché : filtrage des contributeurs et route de rejet

AS_SET participait parfois à la prévention de boucle parce qu’un AS contributeur pouvait reconnaître son propre numéro dans le chemin de l’agrégat et refuser la route. Une agrégation brève qui retire cet AS peut faire disparaître ce signal. La RFC 9774 remplace cette protection implicite par des obligations opérationnelles plus lisibles. L’agrégat ne devrait pas être annoncé aux AS qui ont fourni les routes contributrices. Ceux-ci devraient recevoir les routes plus spécifiques appropriées, à l’exclusion de celles apprises précisément du contributeur auquel l’annonce est destinée.

Une seconde protection concerne le transfert. Le routeur qui génère un agrégat doit rejeter les paquets correspondant au préfixe agrégé lorsqu’aucune route plus spécifique installée ne correspond à leur destination. Sans cette route de rejet, deux réseaux peuvent se renvoyer un trafic couvert seulement par le moins-spécifique, créant une boucle de transfert. La suppression d’un ensemble dans le plan de contrôle ne garantit donc pas la sûreté du plan de transfert. Elle oblige à vérifier le filtrage, les routes contributrices présentes et le comportement de rejet.

BGPsec commence par une négociation, pas par une signature

La RFC 8205 aborde une autre surface : la protection cryptographique du chemin de propagation. Avant qu’une annonce signée puisse être envoyée, les deux pairs doivent annoncer des capacités compatibles. La capacité BGPsec distingue le sens d’envoi du sens de réception. Elle est également propre à une version du protocole et à une famille d’adresses. Un pair disposé à envoyer et à recevoir pour IPv4 et IPv6 doit donc exprimer séparément ces dimensions dans le message OPEN.

Cette granularité empêche un simple indicateur « BGPsec activé » de décrire correctement la session. Une négociation réussie exige que l’émetteur ait annoncé la capacité d’envoyer pour la version et l’AFI concernés, tandis que le récepteur a annoncé la capacité correspondante de recevoir. Le support de l’extension multiprotocole doit être annoncé pour la même famille d’adresses. Tout locuteur qui annonce BGPsec doit aussi annoncer la prise en charge des numéros d’AS sur quatre octets. Sans cette dernière capacité, BGPsec n’est pas considéré comme négocié et un UPDATE contenant BGPsec_PATH ne doit pas être envoyé.

Une session peut néanmoins continuer à échanger des UPDATE BGP traditionnels non signés lorsque BGPsec n’a pas été négocié. La RFC recommande que l’implémentation journalise l’échec de négociation. Elle exige également qu’une implémentation puisse empêcher l’établissement de la session lorsqu’elle est configurée pour n’accepter que BGPsec. La différence entre « la session est établie » et « la protection attendue est active » devient ainsi observable. Sans journal ni politique stricte, une capacité manquante pourrait se transformer silencieusement en fonctionnement non signé.

Secure_Path : un chemin ordonné lié à ses signatures

Dans un UPDATE BGPsec, l’attribut optionnel et non transitif BGPsec_PATH remplace AS_PATH ; les deux ne doivent pas apparaître ensemble. BGPsec_PATH comprend un Secure_Path et un ou deux blocs de signatures. Secure_Path contient un segment pour chaque AS du chemin, avec un numéro d’AS sur quatre octets, un compteur pCount et un indicateur de confédération. Chaque bloc de signatures doit avoir un segment de signature correspondant à chaque segment du chemin sécurisé.

pCount permet de représenter plusieurs répétitions d’un même AS sans demander autant de signatures, ce qui conserve la sémantique de l’AS prepending pour le calcul de longueur du chemin. Une valeur nulle est réservée à des situations définies, notamment certains serveurs de routes transparents, des confédérations ou des migrations de numéro d’AS. Le pair doit être configuré pour savoir de quels voisins cette valeur est acceptable. Si un voisin non attendu envoie pCount égal à zéro, le message est erroné. Cette règle transforme une exception utile en relation de confiance explicite plutôt qu’en raccourci disponible indistinctement.

Chaque segment de signature contient notamment un identifiant de clé, la longueur de la signature et la signature elle-même. La signature protège le préfixe et les éléments pertinents du chemin, dont l’AS cible auquel l’annonce est destinée. Il ne s’agit donc pas d’un sceau abstrait posé sur une route. Chaque AS atteste qu’il a reçu l’annonce avec les données indiquées et qu’il a choisi de la propager à l’AS suivant. La chaîne conserve l’ordre des décisions de propagation.

Les certificats RPKI lient les clés à des ressources précises

BGPsec repose sur des certificats RPKI qui attestent l’allocation de numéros d’AS et de ressources d’adresses IP. Un locuteur qui veut envoyer des UPDATE BGPsec à des pairs externes doit disposer d’une clé privée associée à un certificat de routeur RPKI correspondant à son numéro d’AS. En revanche, un locuteur peut valider des annonces reçues sans posséder lui-même un tel certificat d’émission. Les conditions pour produire une preuve et celles pour la vérifier ne sont donc pas identiques.

Pour vérifier les signatures, le récepteur doit avoir accès, pour les certificats de routeur valides, au triplet numéro d’AS, clé publique et identifiant de clé. Il peut valider lui-même les certificats ou recevoir ces données d’un cache de confiance. La signature est recherchée par la combinaison de l’AS du segment et de l’identifiant de clé ; le calcul couvre le chemin, la famille d’adresses, le SAFI et le NLRI selon l’ordre défini. Une signature correcte relie ainsi l’annonce à une clé autorisée pour l’AS concerné et au contexte exact de propagation.

Cette liaison illustre le rôle d’un registre de ressources. La RPKI enregistre des autorisations et rend disponibles des données cryptographiques ; elle ne choisit pas la meilleure route et ne garantit pas le transfert des paquets. Elle doit toutefois être exacte, unique dans les associations qu’elle affirme, accessible et actualisée. Une clé valide associée au mauvais AS, un certificat révoqué encore présent dans un cache ou des données indisponibles changent la base sur laquelle le routeur évalue le message.

Valider signifie aussi réagir aux changements d’état

La procédure de réception commence par des contrôles de forme et de protocole avant les opérations cryptographiques plus coûteuses. Elle vérifie notamment la présence et la structure de BGPsec_PATH, la correspondance entre le dernier AS ajouté et le pair externe, l’alignement entre segments de chemin et segments de signature, l’absence simultanée d’AS_PATH, les indicateurs de confédération, l’usage attendu de pCount et l’absence de boucle contenant l’AS local. Une erreur entraîne le traitement « treat-as-withdraw ».

Pour les blocs utilisant un algorithme pris en charge, le routeur recherche ensuite la clé publique appropriée dans les données RPKI valides et vérifie les signatures de la plus récente à la plus ancienne. Un échec suffit à rendre le bloc non valide ; un bloc entièrement vérifié devient valide. Si aucun bloc n’utilise un algorithme pris en charge, le locuteur doit retirer les blocs, reconstruire AS_PATH depuis Secure_Path et traiter l’annonce comme non signée s’il veut la considérer dans la sélection de route. Là encore, « non pris en charge », « non valide » et « non signé » sont des états distincts.

La validité n’est pas figée au moment de la réception. Lorsqu’un routeur apprend que l’état RPKI a changé, il doit réévaluer les UPDATE affectés conservés dans sa table d’entrée. L’expiration ou la révocation d’un certificat peut modifier le résultat de vérification des signatures qui utilisent son identifiant de clé. Si l’état de l’annonce change, la politique locale peut imposer une nouvelle sélection du meilleur chemin. La continuité opérationnelle dépend donc de la circulation des mises à jour RPKI autant que de la correction initiale de la signature.

Du dépôt RPKI au routeur : la disponibilité fait partie du mécanisme

La RFC 8205 consacre une considération opérationnelle au chemin suivi par les données RPKI, des dépôts aux caches locaux puis aux routeurs. Des mises à jour incrémentales fondées sur des numéros de série permettent de ne transférer que les enregistrements modifiés. Des fichiers de notification indiquent aux parties utilisatrices où trouver un instantané et les deltas nécessaires à la synchronisation. Le but est de rendre le flux de données plus robuste et plus efficace.

Ce détail empêche de réduire BGPsec à la cryptographie embarquée dans UPDATE. Une signature peut être mathématiquement correcte tout en étant évaluée avec une vue RPKI périmée. À l’inverse, un changement légitime dans le dépôt n’influence les routes que lorsqu’il a atteint le cache, puis le routeur, puis déclenché la réévaluation appropriée. Chaque étape possède son propre état, sa propre fraîcheur et ses propres modes de panne.

Pour l’exploitation, les indicateurs utiles sont donc plus concrets qu’un taux global « BGPsec actif ». Il faut connaître le dernier état du dépôt obtenu par le cache, les deltas manquants, la dernière synchronisation réussie, les clés et certificats rendus au routeur, les annonces dont la validation a été reportée et celles qui ont été réévaluées après changement. Ces observations ne figurent pas comme résultats de terrain dans les sources ; elles découlent des dépendances que la spécification rend explicites et constituent des points à vérifier dans une mise en œuvre réelle.

Politique locale, déploiement partiel et perte de garantie

La sortie de la procédure BGPsec est Valide ou Non valide, mais son influence sur la sélection de route relève de la politique locale. La RFC prévoit que les opérateurs puissent différencier cette politique par session. Un pair conforme peut même propager une annonce qui échoue à la vérification si sa politique locale le décide ; le récepteur externe doit donc effectuer sa propre validation complète. La conformité au format ne délègue pas le jugement au voisin.

Le déploiement partiel ajoute une frontière nette. Au début, seuls des groupes contigus d’AS capables de BGPsec peuvent conserver la protection cryptographique du chemin entre eux. Lorsqu’une annonce atteint un AS qui ne prend pas BGPsec en charge, elle retourne au mode BGP traditionnel et devient non signée pour la suite. L’assurance subsiste sur le segment contigu allant de l’origine au dernier AS capable, mais elle ne s’étend pas au-delà. La présence d’une signature en amont ne sécurise pas magiquement une portion non participante.

Les redémarrages gracieux constituent une autre limite. Les locuteurs BGPsec suivent les procédures BGP prévues pour conserver temporairement l’état de transfert et marquer les routes comme périmées. Cette continuité ne transforme pas une route périmée en état neuf ; elle maintient un comportement pendant une reprise. L’opérateur doit distinguer le statut de validation, la fraîcheur RPKI, l’état de session et l’état conservé lors du redémarrage, car ces dimensions peuvent évoluer séparément.

Ce que BGPsec prouve, et ce qu’il ne prouve pas

Combiné à la validation d’origine, un UPDATE BGPsec valide apporte deux assurances définies. L’AS d’origine correspond à une autorisation RPKI du détenteur de l’espace d’adresses pour le préfixe. Chaque AS inscrit dans Secure_Path a, par un locuteur autorisé pour ce numéro, choisi de propager l’annonce vers l’AS suivant conformément à sa politique locale. La preuve porte sur la circulation du message de contrôle et sur la chaîne de décisions de propagation.

Elle ne garantit pas que les paquets de données suivent le chemin indiqué. Le plan de transfert peut diverger en raison de tunnels, de politiques internes, de pannes ou d’autres mécanismes que la signature BGPsec ne décrit pas. Elle ne protège pas non plus la session contre toutes les attaques de transport. Un adversaire sur le chemin peut provoquer des échecs, injecter des messages non valides ou interrompre la session, même s’il ne peut pas transformer par ce seul moyen une route non valide en route cryptographiquement valide.

La spécification reconnaît aussi des comportements hors de sa portée, comme une collusion utilisant un tunnel pour contourner le chemin BGP attendu, ou certaines attaques par rejeu liées à la suppression d’un retrait. Elle encadre l’usage de pCount égal à zéro, mais un récepteur situé plusieurs sauts plus loin ne peut pas toujours vérifier lui-même si cette valeur a été utilisée légitimement en amont. La sécurité obtenue est donc forte sur des assertions précises, et volontairement limitée sur le reste.

Une contribution visible dans la précision des frontières

Le lien entre les trois RFC ne réside pas dans une prétention à un système unique. RFC 6472 et RFC 9774 forment une évolution : abandonner un état de chemin ambigu, puis préciser le comportement par défaut de l’émetteur et du récepteur ainsi que les remplacements opérationnels nécessaires. RFC 8205 définit une autre construction : conserver un chemin ordonné, négocier la possibilité de le sécuriser et lier chaque décision de propagation à une clé de ressource vérifiable.

Elles ne confèrent pas une maîtrise personnelle du routage mondial. Le consensus produit les textes ; les développeurs choisissent les structures et les diagnostics ; les opérateurs organisent la compatibilité et la migration ; les réseaux exécutent ces choix. La valeur durable du dossier est précisément de ne pas confondre ces niveaux. Une sécurité exploitable commence lorsque chaque niveau expose assez d’état pour que le suivant n’ait pas à deviner.