L'exploitation de passerelles de réseau privé virtuel (VPN) d'entreprise à haute densité impose le traitement de plusieurs millions de paquets chiffrés par seconde à travers des topologies réseau distribuées. Au sein du système d'exploitation Linux, les transformations cryptographiques associées au protocole IPsec (charge utile de sécurité encapsulée ESP) sont prises en charge par le sous-système de transformation du noyau, nommé XFRM.

Historiquement, le déploiement d'IPsec basé sur des politiques (Policy-Based IPsec) présentait des contraintes opérationnelles majeures :

  1. Interception implicite des flux : Les paquets étaient capturés de façon invisible après la décision de routage dès lors qu'ils correspondaient à une politique de sécurité (SP). Ce mécanisme implicite provoquait des conflits délicats avec les règles du pare-feu Netfilter, les tables de suivi de connexion (conntrack) et les règles de routage par la source.
  2. Absence de visibilité sur les interfaces : En l'absence d'interface réseau dédiée, les outils d'analyse conventionnels comme tcpdump ne pouvaient pas capturer le trafic en clair avant chiffrement ou après déchiffrement sans mettre en place des règles netfilter complexes.
  3. Surcoût protocolaire des tunnels : Les solutions alternatives telles que les interfaces de tunnel virtuel (VTI) ou l'encapsulation GRE-over-IPsec ajoutaient des en-têtes volumineux, réduisant la taille du MTU utile et compliquant l'intégration des démons de routage dynamique (BGP ou OSPF).

Afin d'éliminer ces obstacles, les versions récentes du noyau Linux ont standardisé les interfaces XFRM basées sur le routage (Route-Based XFRM, xfrmi), combinées au délestage matériel cryptographique (Hardware Crypto Offload). Cette architecture sépare la logique cryptographique des décisions de routage, offrant des interfaces réseau explicites et confiant l'exécution des algorithmes de chiffrement aux processeurs ASIC des cartes réseau.

+--------------------------------------------------------------------------+
|          ARCHITECTURE LINUX XFRM : POLITIQUES IMPLICITES VS XFRMI        |
+--------------------------------------------------------------------------+
|                                                                          |
| 1. IPsec classique basé sur des politiques (Policy-Based) :              |
|    Paquet -> Routage -> Netfilter -> Correspondance politique SP         |
|           -> Association SA -> Chiffrement logiciel CPU -> Sortie        |
|    (Aucune interface visible, capture difficile, conflits de routage)    |
|                                                                          |
| 2. Interface XFRM moderne basée sur le routage (Route-Based xfrmi) :     |
|    Paquet -> Routage standard vers xfrm0 (if_id 42) -> Qdisc dédiée      |
|           -> Capture tcpdump transparente -> SA liée via if_id           |
|           -> Délestage matériel ASIC de la carte -> Débit physique       |
|                                                                          |
+--------------------------------------------------------------------------+

Structure fondamentale du sous-système XFRM : SA, SP et if_id

Le fonctionnement du sous-système XFRM repose sur trois bases de données principales conservées en mémoire noyau :

1. Base des associations de sécurité (SAD / xfrm_state)

Une association de sécurité (Security Association, SA) définit un contrat cryptographique unidirectionnel entre deux passerelles distantes. Une entrée SA enregistre :

  • L'index des paramètres de sécurité (SPI) : Une valeur de 32 bits identifiant le flux chiffré.
  • Les algorithmes et les clés : Des suites de chiffrement comme AES-GCM-256 ou ChaCha20-Poly1305.
  • Les numéros de séquence étendus (ESN) : Des compteurs 64 bits prévenant les attaques par rejeu.
  • Le contexte de délestage matériel : Les pointeurs d'accélération vers le pilote de la carte réseau.

2. Base des politiques de sécurité (SPD / xfrm_policy)

Une politique de sécurité (Security Policy, SP) détermine quels flux doivent impérativement subir une transformation chiffrée. Une règle SP précise les préfixes IP source et destination, les protocoles et la direction du trafic (dir in, dir out, dir fwd).

3. Rôle du marqueur d'interface (if_id)

Le paramètre if_id agit comme un jeton de liaison numérique entre l'interface virtuelle xfrmi et les règles cryptographiques associées :

  • Lorsqu'un paquet est envoyé sur l'interface xfrm0 configurée avec l'identifiant if_id 42, le noyau sélectionne exclusivement les politiques et les SA pourvues du même if_id 42.
  • Plusieurs interfaces virtuelles peuvent coexister sur le même serveur sans risque de chevauchement d'adresses IP.
+--------------------------------------------------------------------------+
|          CHEMINEMENT DU PAQUET VIA UNE INTERFACE ROUTÉE XFRM             |
+--------------------------------------------------------------------------+
|                                                                          |
|       Application utilisateur / Flux de données socket                   |
|                           │                                              |
|                           v                                              |
|       Table de routage du noyau Linux (FIB)                              |
|       [ Route : 10.100.0.0/16 acheminée par le périphérique xfrm0 ]      |
|                           │                                              |
|                           v                                              |
|       Interface virtuelle 'xfrm0' (Associée au marqueur if_id 42)        |
|       [ Données claires observables directement via tcpdump -i xfrm0 ]   |
|                           │                                              |
|                           v                                              |
|       Chaîne de transformation XFRM (Filtre if_id 42)                    |
|       - Recherche de politique : règle SP portant if_id 42               |
|       - Recherche d'association : sélection SA selon le SPI              |
|                           │                                              |
|             ┌─────────────┴─────────────┐                                |
|             ▼ (Traitement logiciel CPU) ▼ (Délestage matériel ASIC)      |
|       Kernel Crypto API           Puce matérielle de la carte réseau     |
|       (Instructions AES-NI / AVX) (Aucune charge CPU sur le serveur)    |
|             │                           │                                |
|             └─────────────┬─────────────┘                                |
|                           │                                              |
|                           v                                              |
|       Interface physique de sortie (eth0 / Port optique 100GbE)          |
|       [ Paquet ESP chiffré : SPI 0x1001, Numéro de séquence N ]          |
|                           │                                              |
|                           v                                              |
|       Transmission optique à la vitesse de la ligne                      |
|                                                                          |
+--------------------------------------------------------------------------+

Accélération matérielle : Le délestage XFRM Crypto Offload

Chiffrer des flux à 100GbE à l'aide du processeur central mobilise une quantité substantielle de ressources calculatoires. Même avec des instructions vectorielles AES-NI, le chiffrement de trafics multi-gigabits entraîne des échauffements processeurs, des goulots d'étranglement sur les interruptions et des hausses de latence.

Les cartes réseau professionnelles récentes (telles que Mellanox ConnectX-6/7, Intel E810 et Broadcom NetXtreme) intègrent des unités matérielles dédiées au traitement d'IPsec.

Linux XFRM gère deux types d'accélération matérielle :

  • Délestage complet (Full Offload) : La construction des paquets ESP, la gestion des numéros de séquence, la fenêtre anti-rejeu et le chiffrement sont assurés par la carte réseau. Le CPU n'émet que des paquets IP classiques.
  • Délestage cryptographique (Crypto Offload) : Le noyau prépare l'en-tête ESP, tandis que les algorithmes de chiffrement symétrique et de hachage sont exécutés par la puce de la carte pendant le transfert DMA.
+--------------------------------------------------------------------------+
|          COMPARAISON : CHIFFREMENT CPU VS DÉLESTAGE MATÉRIEL XFRM        |
+--------------------------------------------------------------------------+
| Critère de performance  | Chiffrement logiciel    | Délestage matériel   |
+-------------------------+-------------------------+----------------------+
| Cœurs CPU requis 100G   | 8 à 16 Cœurs dédiés     | < 0.5 Cœur (Pilote)  |
| Latence moyenne paquet  | 15 à 35 Microsecondes   | 1.2 à 2.5 Microsecond|
| Pertes en charge lourde | Élevées dès 8-12 Mpps   | Aucune perte de trame|
| Pression sur le bus DMA | Échanges mémoire intenses Échanges optimisés   |
| Dégagement thermique    | Forte chauffe CPU       | Carte réseau tempérée|
+-------------------------+-------------------------+----------------------+

Guide de mise en œuvre sous Linux

La mise en place d'une interface XFRM routée avec délestage matériel s'effectue via les commandes usuelles de la suite iproute2 (ip link et ip xfrm).

Étape 1 : Création de l'interface virtuelle XFRM

Associez une nouvelle interface XFRM au port physique en spécifiant l'identifiant if_id :

# Création de xfrm0 sur eth0 avec le marqueur if_id 42
ip link add name xfrm0 type xfrm dev eth0 if_id 42

# Attribution de l'adresse IP de transit
ip addr add 10.254.1.1/30 dev xfrm0

# Activation de l'interface
ip link set dev xfrm0 up

Étape 2 : Configuration des associations SA avec délestage matériel

Déclarez les associations de sécurité en mémoire noyau en précisant la liaison avec if_id 42 et le matériel cible :

# SA sortante (Local -> Distant) avec délestage activé
ip xfrm state add \
    src 198.51.100.1 dst 198.51.100.2 \
    proto esp spi 0x1001 \
    reqid 1 \
    mode tunnel \
    if_id 42 \
    aead 'rfc4106(gcm(aes))' 0x0123456789abcdef0123456789abcdef01234567 128 \
    offload dev eth0 dir out \
    sel src 0.0.0.0/0 dst 0.0.0.0/0

# SA entrante (Distant -> Local) avec délestage activé
ip xfrm state add \
    src 198.51.100.2 dst 198.51.100.1 \
    proto esp spi 0x2001 \
    reqid 1 \
    mode tunnel \
    if_id 42 \
    aead 'rfc4106(gcm(aes))' 0x0123456789abcdef0123456789abcdef01234567 128 \
    offload dev eth0 dir in \
    sel src 0.0.0.0/0 dst 0.0.0.0/0

Étape 3 : Définition des politiques de sécurité associées

Créez les règles de politique de sécurité rattachées à l'identifiant if_id 42 :

# Règle pour le trafic sortant via xfrm0
ip xfrm policy add \
    src 0.0.0.0/0 dst 0.0.0.0/0 \
    dir out \
    if_id 42 \
    tmpl src 198.51.100.1 dst 198.51.100.2 proto esp reqid 1 mode tunnel

# Règle pour le trafic entrant provenant de la passerelle distante
ip xfrm policy add \
    src 0.0.0.0/0 dst 0.0.0.0/0 \
    dir in \
    if_id 42 \
    tmpl src 198.51.100.2 dst 198.51.100.1 proto esp reqid 1 mode tunnel

Étape 4 : Routage direct vers l'interface XFRM

Une fois l'interface opérationnelle, le routage des réseaux distants s'effectue avec la syntaxe standard :

# Routage du sous-réseau distant via xfrm0
ip route add 10.100.0.0/16 dev xfrm0

# Contrôle des compteurs et de l'état du délestage
ip -s link show dev xfrm0
ip -s xfrm state show

Intégration au sein de l'écosystème RiceGuard et VPNRice

Au sein du maillage de passerelles de VPNRice, l'architecture XFRM assure des fonctions essentielles :

  1. Liaisons de transit inter-datacenters : Les liaisons reliant les passerelles périphériques aux nœuds centraux exploitent des interfaces XFRM adossées au délestage matériel. L'exécution d'AES-GCM sur des SmartNIC 100GbE permet de maintenir des débits de pointe sans surchauffe processeur.
  2. Interopérabilité avec le routage dynamique : Les interfaces XFRM se comportent comme des liens réseau classiques. Les processus BGP s'y connectent directement, garantissant une convergence instantanée en cas de coupure de fibre optique.
  3. Cloisonnement multi-entités : L'attribution de marqueurs if_id distincts isole les flux de différents groupes d'utilisateurs sur des interfaces virtuelles dédiées, permettant l'application de règles de pare-feu précises sans interférence.

Bonnes pratiques pour l'exploitation en production

Lors de la mise en service d'interfaces XFRM, les critères suivants doivent être respectés :

  • Prise en charge matérielle par le pilote : Vérifiez que le pilote réseau gère le délestage IPsec (ethtool -k eth0 | grep esp). Les pilotes mlx5_core et ice offrent cette prise en charge.
  • Gestion du MTU et du MSS : Les en-têtes ESP ajoutent un surcoût de 50 à 70 octets. Définissez le MTU de l'interface xfrm0 à 1430 octets sur les réseaux standards à 1500 octets, ou appliquez l'ajustement automatique du MSS (TCPMSS --clamp-mss-to-pmtu).
  • Activation des séquences étendues ESN : Sur des liens à 40GbE ou 100GbE, un compteur 32 bits s'épuise en quelques minutes. Utilisez impérativement des compteurs 64 bits (ESN) associés à une fenêtre anti-rejeu d'au moins 1024 paquets (replay-window 1024 flag esn).

Grâce aux interfaces XFRM routées et à l'accélération matérielle, les serveurs Linux disposent d'une plateforme cryptographique robuste capable de répondre aux exigences des architectures VPN modernes.