RPKI ASPA : défense cryptographique contre les fuites de routes BGP

Le routage mondial sur Internet repose sur le protocole BGP (Border Gateway Protocol). Chaque seconde, plus de cent mille systèmes autonomes (AS) échangent des annonces de routage afin d'acheminer les paquets IP à travers les réseaux de transit intermédiaires jusqu'à leur destination. Pendant des décennies, cette architecture décentralisée a fonctionné sur un principe de confiance implicite : n'importe quel opérateur pouvait annoncer des préfixes IP ou des chemins de transit sans fournir de preuve mathématique d'autorisation.

Le déploiement de l'infrastructure à clé publique des ressources (RPKI) et de la validation de l'origine des routes (Route Origin Validation - ROV, définie dans le RFC 6811) a constitué un jalon fondamental pour sécuriser les échanges interdomaines. Le mécanisme ROV permet aux routeurs de vérifier si un système autonome annonçant un préfixe IP est légitimement autorisé à émettre ce bloc grâce à un objet d'autorisation d'origine (ROA - Route Origin Authorization).

Cependant, le mécanisme ROV présente une zone d'ombre architecturale majeure : il ne valide que le système autonome d'origine (l'AS situé tout à droite dans l'attribut AS_PATH). ROV est totalement incapable de vérifier si la séquence de systèmes autonomes intermédiaires transportant les paquets constitue un chemin de transit légitime et autorisé. Des acteurs malveillants ou des réseaux mal configurés peuvent fabriquer de faux sauts ou provoquer de graves fuites de routes BGP (route leaks), détournant silencieusement des flux internationaux à travers des transits imprévus.

Pour combler cette faille, l'IETF a normalisé le standard ASPA (Autonomous System Provider Authorization) au sein du RFC 9319 et des travaux du groupe SIDROPS. ASPA introduit une vérification cryptographique des sauts BGP intermédiaires, éliminant les fuites de routes et les falsifications de chemins au sein des réseaux de transit mondiaux.

+-------------------------------------------------------------------------+
|                  FAILLE D'INTÉGRITÉ DU CHEMIN BGP : ROV ET ASPA         |
+-------------------------------------------------------------------------+
|                                                                         |
|  Préfixe : 198.51.100.0/24   AS d'origine : AS65001                     |
|                                                                         |
|  Annonce BGP AS_PATH propagée :                                         |
|  [Opérateur Tier-1 AS100] -> [AS200 en fuite] -> [Client AS65001]       |
|                                                                         |
|  1. Validation d'origine RPKI ROV :                                     |
|     - Inspecte UNIQUEMENT AS65001 à l'extrémité droite.                 |
|     - Correspondance avec l'objet ROA confirmée -> Statut : VALID !     |
|     - Résultat : ROV ignore totalement si AS200 est autorisé !          |
|                                                                         |
|  2. Autorisation de fournisseur RPKI ASPA :                             |
|     - Vérifie les relations client-fournisseur saut par saut.           |
|     - Contrôle si AS65001 a autorisé AS200 comme fournisseur amont.     |
|     - Détecte le transit illégitime / violation de la règle valley-free |
|     - Statut : INVALID -> L'annonce anormale est immédiatement rejetée !|
+-------------------------------------------------------------------------+

Les limites de la validation de l'origine des routes (ROV)

Pour appréhender la nécessité d'ASPA, il convient de cerner le périmètre de protection offert par ROV. Lorsqu'une organisation publie une autorisation ROA dans le dépôt RPKI, cet objet cryptographique lie un bloc d'adresses IP (par exemple 203.0.113.0/24) et une longueur maximale de préfixe à un numéro d'AS d'origine autorisé (AS64496).

Lorsqu'un routeur de frontière reçoit une annonce BGP, ROV contrôle deux éléments :

Le préfixe et le masque annoncés s'inscrivent-ils dans les limites d'un objet ROA signé ?
Le numéro d'AS situé à l'extrémité droite de l'attribut AS_PATH correspond-il à celui du ROA ?

Si ces conditions sont réunies, la route reçoit le statut Valid. Si un système non autorisé émet ce bloc, la route est déclarée Invalid et rejetée.

Toutefois, ROV n'opère aucun contrôle sur les numéros d'AS qui précèdent l'origine. Un réseau multiconnecté (multihomed) victime d'une erreur de filtrage ou un attaquant peut générer une annonce où l'AS d'origine est parfaitement conforme, mais dont la chaîne de transit a été altérée. Un opérateur non autorisé peut s'immiscer au milieu du chemin ou relayer indûment des routes reçues d'un pair vers un autre pair, violant les règles d'interconnexion sans déclencher la moindre alerte au niveau de ROV.

Anatomie d'une fuite de route BGP (RFC 7908)

Le RFC 7908 caractérise une fuite de route BGP comme la propagation d'annonces de routage au-delà du cadre d'échange convenu. Dans le routage interdomaines, les accords commerciaux entre systèmes autonomes s'articulent selon le modèle de Gao-Rexford :

Client vers Fournisseur (Customer-to-Provider) : Le client rémunère le fournisseur pour bénéficier d'un transit Internet global.
Fournisseur vers Client (Provider-to-Customer) : Le fournisseur achemine le trafic à destination et en provenance de ses clients payants.
Échange de pair à pair (Peer-to-Peer) : Deux réseaux s'échangent mutuellement le trafic de leurs clients respectifs sans frais de transit.

En bonne gestion commerciale, le routage doit demeurer sans vallée (valley-free). Un réseau ne doit jamais assurer le transit gracieux entre deux de ses fournisseurs ou entre deux pairs non payants. Une fois qu'une annonce de route est descendue le long d'un lien (du fournisseur vers le client, ou entre pairs), elle ne doit en aucun cas remonter vers un autre fournisseur ou un autre pair.

+-----------------------------------------------------------------------+
|                    VIOLATION DU PRINCIPE DU ROUTAGE SANS VALLÉE       |
+-----------------------------------------------------------------------+
|        [Opérateur de transit A]            [Opérateur de transit B]   |
|                 │                                   ▲                 |
|                 │ (Du fournisseur vers le client)   │ (ROUTE EN FUITE)|
|                 ▼                                   │                 |
|      +---------------------------------------------------------+      |
|      |               Entreprise multiconnectée AS300           |      |
|      |    Réannonce par inadvertance les routes apprises du    |      |
|      |    fournisseur A directement vers le fournisseur B !    |      |
|      +---------------------------------------------------------+      |
+-----------------------------------------------------------------------+

Les fuites de routes surviennent fréquemment à la suite d'erreurs d'exploitation : mauvaise syntaxe dans une table de filtrage (route-map) ou dysfonctionnement d'un script d'automatisation lors d'une opération de maintenance. Lorsque l'AS300 diffuse accidentellement les routes apprises du Fournisseur A vers le Fournisseur B, les réseaux voisins supposent qu'AS300 offre un lien direct et avantageux.

Des flux massifs destinés aux liaisons transatlantiques ou transpacifiques convergent alors brutalement vers les équipements modestes de l'AS300. Il en résulte une congestion immédiate, une hausse vertigineuse des temps de latence et des pertes de paquets massives.

Lors d'incidents historiques — tels que le détournement du trafic mobile européen vers le réseau d'un groupe métallurgique en 2019 ou diverses anomalies touchant des géants du cloud —, des milliards de paquets chiffrés ont transité par des voies inattendues sans que les règles traditionnelles de validation d'origine ne détectent la moindre anomalie.

Fonctionnement d'ASPA : l'autorisation cryptographique des fournisseurs

ASPA remédie à cette faiblesse structurelle en instaurant une chaîne d'attestation formelle pour les relations inter-systèmes. Sous l'égide du RFC 9319, un système autonome émet et signe un enregistrement ASPA au sein du registre RPKI.

Un enregistrement ASPA formule une déclaration univoque protégée par signature numérique :

AS Client (Customer AS - CAS) : Le système autonome qui publie l'autorisation.
Ensemble des AS Fournisseurs (Provider AS Set - PAS) : La liste exhaustive des systèmes autonomes amont autorisés par le client à assurer son transit et à relayer ses annonces de routage.

Le contenu d'un enregistrement ASPA prend en charge conjointement ou séparément les familles d'adresses IPv4 et IPv6. Intégrés dans la hiérarchie de certificats X.509 de RPKI, les objets ASPA bénéficient des mêmes garanties de distribution et d'intégrité que les enregistrements ROA. Les démons de validation RPKI (tels que Routinator, StayRtr ou rpki-client) synchronisent et vérifient les tables ASPA aux côtés des annonces de préfixes.

L'algorithme de vérification ASPA : respect du principe Valley-Free

Lorsqu'un routeur de bordure prenant en charge ASPA traite une annonce de route BGP entrante, il confronte la séquence de sauts de l'attribut AS_PATH à sa mémoire cache ASPA locale.

L'algorithme analyse méthodiquement chaque couple d'AS contigus (AS(i), AS(i+1)) sur l'ensemble du chemin :

Séquence ascendante (du client vers le fournisseur) : Lors de la remontée depuis l'origine vers les dorsales de transit, chaque saut AS(i) -> AS(i+1) doit correspondre à une relation client-fournisseur attestée, où AS(i+1) figure expressément dans l'enregistrement ASPA de AS(i).
Le sommet (Apex) : Le chemin atteint son point culminant au niveau d'un opérateur de transit mondial (Tier-1) ou d'une liaison de pairage bilatérale.
Séquence descendante (du fournisseur vers le client) : Lorsque l'annonce redescend vers sa cible, chaque saut AS(i) -> AS(i+1) doit certifier qu'AS(i) figure en tant que fournisseur dans l'enregistrement ASPA de AS(i+1).

Si l'algorithme relève une transition d'une phase descendante vers une phase ascendante (traduisant une violation de la règle sans vallée suite à une fuite entre pairs ou entre transitaires), ou si un saut relie deux systèmes sans accord préalable validé, la route est déclarée Invalid.

Les moteurs BGP configurés avec ASPA éliminent automatiquement les annonces classées Invalid, protégeant les tables de routage des perturbations induites par les routes en fuite.

Différenciation de la vérification en amont et en aval

L'interface réseau par laquelle un routeur accueille une annonce BGP dicte le mode d'évaluation de la politique ASPA :

Type de liaison d'entrée	Profil attendu de l'AS_PATH	Sens de validation ASPA	Objectif de protection
En provenance d'un client	Séquence strictement ascendante (`Client -> Fournisseur...`)	Vérification ascendante (Client vers Fournisseur)	Empêche le client de relayer les routes de ses autres fournisseurs
En provenance d'un pair	Montée, saut de pairage unique, puis descente	Contrôle bilatéral de la règle sans vallée	Prévient les fuites transversales et les manipulations d'AS_PATH
En provenance d'un fournisseur	Montée vers le sommet, puis descente vers l'origine	Validation descendante vers l'AS source	Empêche le fournisseur de propager des routes clientes en fuite

En appliquant des contrôles mathématiques adaptés à chaque rôle d'interconnexion, le routeur de bordure s'affranchit de la nécessité d'établir des accords bilatéraux complexes avec des réseaux tiers distants. Les flux anormaux sont filtrés à la vitesse du matériel.

Impact réel : comment les fuites de routes menacent les tunnels VPN

Les réseaux privés virtuels construisent des tunnels chiffrés au-dessus d'infrastructures physiques publiques. Bien que des technologies comme WireGuard ou IPsec protègent rigoureusement les données utiles, ces flux demeurent des paquets IP conventionnels subordonnés aux choix de routage BGP sous-jacents.

Lorsqu'une fuite de route BGP ou un détournement de chemin perturbe la liaison entre le poste client et la passerelle VPN, le tunnel subit trois dégradations directes :

Déni de service par saturation intermédiaire : Les routes en fuite canalisent souvent un volume massif de trafic vers des infrastructures régionales sous-dimensionnées. L'engorgement des mémoires tampons (bufferbloat) et les pertes de paquets répétées rompent les battements de cœur UDP keepalive et provoquent des reconnexions en chaîne du tunnel.
Analyse de trafic et empreinte temporelle : Même sans casser le chiffrement, un observateur capable d'attirer le trafic VPN au sein de son périmètre d'écoute peut corréler les variations de latence, les tailles de paquets et les métadonnées de flux pour identifier les activités de l'utilisateur.
Perte de paquets en trou noir (Blackholing) : Des réseaux mal configurés annoncent fréquemment des routes sans disposer des interconnexions réelles pour acheminer les paquets vers la destination finale, provoquant la disparition des flux jusqu'à ce que la convergence BGP rétablisse l'ordre.

Préservation de la connectivité avec RiceGuard et l'architecture Anycast

L'infrastructure réseau de VPNRice s'appuie sur une démarche proactive d'immunité face aux instabilités du routage interdomaines. L'association du protocole RiceGuard et d'une conception distribuée en BGP Anycast isole les flux des utilisateurs des aléas du réseau public.

+-----------------------------------------------------------------------+
|                    BOUCLIER DE ROUTAGE PROACTIF RICEGUARD             |
+-----------------------------------------------------------------------+
|  [ Trafic applicatif du terminal utilisateur ]                        |
|         │                                                             |
|         ▼                                                             |
|  [ IP Anycast de bordure ]     -> Répartie sur des dorsales Tier-1    |
|         │                                                             |
|         ▼                                                             |
|  [ Filtrage RPKI ROV + ASPA ]  -> Validation de l'AS_PATH à l'entrée  |
|         │                                                             |
|         ▼                                                             |
|  [ Moteur de tunnel RiceGuard ]-> Chiffrement ChaCha20-Poly1305 direct|
|         │                                                             |
|         ▼                                                             |
|  [ Transit dorsal assaini ]    -> Aucun détour imprévu / Faible gigue |
+-----------------------------------------------------------------------+

RiceGuard applique des garanties techniques concrètes :

Filtrage intransigeant sur les liaisons Tier-1 : Les nœuds d'extrémité de VPNRice s'interconnectent uniquement avec des fournisseurs de transit amont imposant la validation RPKI ROV et le filtrage ASPA sur tous leurs ports de collecte.
Redondance géographique Anycast : En publiant des blocs d'adresses IP identiques depuis de multiples centres de données à travers le monde, une perturbation locale est automatiquement compensée par le basculement naturel du trafic vers le nœud disponible le plus proche.
Récupération instantanée : Grâce à un transport UDP sans surcharge de négociation, RiceGuard rétablit les échanges protégés en quelques millisecondes dès que les routes physiques sous-jacentes sont stabilisées.

Les utilisateurs peuvent obtenir les logiciels sécurisés pour ordinateurs et téléphones sur la page de téléchargement VPN.

Déploiement opérationnel : création et publication d'enregistrements ASPA

L'activation de la protection ASPA implique pour les administrateurs de systèmes autonomes de déclarer leurs accords de transit auprès de leur registre Internet régional (RIR), tel que le RIPE NCC, l'ARIN, l'APNIC, LACNIC ou l'AFRINIC.

La formalisation d'un objet ASPA s'effectue via le portail RPKI de l'autorité de gestion ou par le biais d'un serveur d'autorité de certification RPKI délégué conforme au RFC 8181.

Structure d'un enregistrement ASPA

Voici la représentation standard au format JSON d'un enregistrement ASPA pour une entreprise (AS65100) définissant ses transitaires agréés :

{
  "customer_asid": 65100,
  "providers": [
    {
      "provider_asid": 174,
      "afi": "both"
    },
    {
      "provider_asid": 2914,
      "afi": "both"
    },
    {
      "provider_asid": 3356,
      "afi": "both"
    }
  ]
}

Dans cette configuration :

customer_asid spécifie l'AS détenteur des préfixes.
providers énumère les opérateurs de transit reconnus (Cogent AS174, NTT AS2914 et Lumen AS3356).
afi confirme l'application de la règle pour les protocoles IPv4 et IPv6.

Dès lors, toute annonce BGP affirmant qu'AS65100 est relayé par un acteur non répertorié sera cataloguée comme Invalid par les routeurs effectuant la vérification ASPA.

Configuration des équipements : activation d'ASPA sur BIRD et FRR

Les suites de routage logicielles ouvertes reconnues, notamment BIRD (à compter de la version 2.15) et FRRouting (FRR), intègrent la vérification native des enregistrements ASPA.

Exemple de configuration pour BIRD 2

Au sein du fichier de configuration de BIRD, le protocole RPKI se connecte à un démon validateur local via le protocole RTR (port 8282) :

# Raccordement au validateur RPKI RTR local
protocol rpki rpki_validator {
    rtr 127.0.0.1 port 8282;
    retry 300;
    refresh 600;
    aspa 4; # Activer ASPA pour IPv4
    aspa 6; # Activer ASPA pour IPv6
}

# Définition du filtre d'entrée BGP avec contrôle ASPA
filter ebgp_in_filter {
    # Vérification initiale de l'origine ROV
    if roa_check(rpki_validator, net, bgp_path.last) = ROA_INVALID then {
        reject "Rejet : Origine ROV invalide";
    }

    # Contrôle de l'intégrité de la séquence ASPA
    if aspa_check(rpki_validator, bgp_path, 0) = ASPA_INVALID then {
        reject "Rejet : Échec de validation ASPA (Fuite de route détectée)";
    }

    accept;
}

L'application directe de la directive aspa_check dans les filtres d'entrée intercepte les routes compromises avant qu'elles ne s'inscrivent dans la table d'information de routage (RIB).

Comparaison entre ASPA et BGPSec : le pragmatisme opérationnel

Pendant longtemps, le standard BGPSec (RFC 8205) a été perçu comme la réponse définitive à l'insécurité du routage en imposant la signature cryptographique de chaque saut BGP.

Cependant, BGPSec a buté sur des obstacles pratiques insurmontables :

Consommation de ressources prohibitive : Signer et vérifier chaque mise à jour BGP à des débits de plusieurs centaines de gigabits excède les capacités des coprocesseurs matériels des routeurs actuels.
Explosion de la taille des paquets : L'accumulation des signatures entraîne la fragmentation des paquets TCP et des débordements de mémoire tampon.
Nécessité d'une adoption universelle : Si un seul opérateur intermédiaire sur le chemin n'a pas déployé BGPSec, l'ensemble de la chaîne de confiance s'effondre.

ASPA offre un compromis technique réaliste et applicable :

Aucune altération du protocole BGP : Le format des paquets BGP UPDATE sur le câble demeure strictement inchangé.
Impact nul sur le processeur : La vérification s'exécute par de simples recherches en mémoire cache locale.
Bénéfice unilatéral immédiat : Dès lors que votre fournisseur amont applique les filtres ASPA, vos flux bénéficient d'un bouclier opérationnel sans attendre la mise à niveau de l'ensemble d'Internet.

Recommandations pratiques pour les ingénieurs réseau

Les équipes chargées de l'exploitation des infrastructures de télécommunication peuvent renforcer leur posture de routage grâce aux mesures suivantes :

Enregistrer des objets ROA exhaustifs : Créez des autorisations formelles d'origine pour tous vos préfixes IPv4 et IPv6 auprès des registres régionaux.
Publier des déclarations ASPA précises : Renseignez dans RPKI la liste complète de vos opérateurs de transit autorisés, sans omettre vos liens de secours.
Appliquer le rejet strict ROV : Configurez vos routeurs de frontière pour supprimer systématiquement les annonces déclarées ROA_INVALID.
Mettre à jour les démons validateurs : Déployez des versions de validateurs RPKI compatibles avec ASPA (comme Routinator 0.13+ ou rpki-client).
Surveiller les anomalies de cheminement : Utilisez des plateformes d'observation BGP pour vérifier que vos préfixes ne transitent pas par des chaînes d'AS imprévues.

Assurer la robustesse de l'espace de routage mondial exige de dépasser la seule vérification de l'origine pour s'attacher à l'intégrité globale du chemin. En instaurant un contrôle cryptographique des transitaires grâce à ASPA, les acteurs d'Internet bâtissent un écosystème fiable et prévisible, offrant un socle solide pour le fonctionnement pérenne des réseaux chiffrés à l'échelle planétaire.