Résumé

  • RFC 3193 imposait ESP pour les paquets de contrôle et de données L2TP, mais la protection exigeait que L2TP transmette à IPsec l’adresse et les ports réellement retenus pendant l’établissement du tunnel.
  • Une identité de machine authentifiée par IKE restait différente de l’identité d’utilisateur présentée à PPP ; sans isolement local du trafic, un paquet IPsec valide ne prouvait pas l’auteur humain attendu.

Un filtre IPsec doit savoir ce qu’il protège. Une connexion L2TP, elle, pouvait encore changer de forme au moment même où elle naissait. C’est de ce décalage que part RFC 3193.

L2TP transportait des trames PPP et possédait déjà plusieurs mécanismes de sécurité. Il pouvait authentifier les extrémités du tunnel. PPP pouvait authentifier un client et négocier chiffrement ou compression. Mais ces actes initiaux ne donnaient ni intégrité ni protection contre le rejeu à chaque paquet de contrôle et de données. Ils ne fournissaient pas non plus le mécanisme de gestion de clés demandé pour un tunnel exposé à un réseau IP.

Le RFC a donc choisi IPsec ESP. Une implémentation conforme devait l’offrir pour le contrôle comme pour les données, accepter le mode transport et activer la protection contre le rejeu. Le mode tunnel restait possible. Les suites alors obligatoires, y compris le chiffrement nul, devaient être prises en charge, mais leur usage concret relevait de l’opérateur. La norme séparait ainsi la capacité d’une implémentation de la décision de déploiement.

Cette enveloppe ne suffisait pas à elle seule. Pendant IKE Phase 2, les pairs décrivaient le trafic autorisé par des adresses, un protocole et des ports. Or L2TP autorisait un port source dynamique. Le répondant pouvait adopter un nouveau port dans sa réponse. Le texte de base permettait même un changement d’adresse. Un filtre figé sur le rendez-vous initial risquait alors soit de bloquer le vrai tunnel, soit de rester trop large.

RFC 3193 a résolu le problème en faisant traverser une frontière interne aux faits de l’application. Avant le premier SCCRQ, un filtre initial devait déjà protéger la demande d’ouverture. Si aucune association de sécurité n’existait, l’envoi de cette demande devait provoquer sa création ; en cas d’échec, le paquet devait être abandonné. Lorsque L2TP connaissait son port dynamique, il injectait cette donnée dans la base de filtres IPsec. Une fois Quick Mode terminé, IKE associait un filtre précis à la nouvelle SA.

L’ordre avait une signification de sécurité. Protéger seulement les paquets qui suivent l’ouverture aurait laissé le message créateur de la relation hors de la relation protégée. Le contrôle n’était donc pas « IPsec activé » mais « la règle existe avant le premier SCCRQ ».

Le changement d’adresse imposait un redémarrage explicite. Le répondant ne devait pas simplement émettre une SCCRP depuis une autre adresse. Il envoyait, par le chemin déjà protégé, un StopCCN indiquant une erreur générale et « Try Another », avec la nouvelle adresse. L’initiateur vérifiait sa forme, adaptait les filtres, établissait de nouvelles Phase 1 et Phase 2, puis envoyait un nouveau SCCRQ. La continuité applicative ne dispensait pas de reconstruire la continuité cryptographique.

Un changement de port suivait une chorégraphie distincte. Le répondant décidait avant SCCRP, injectait de nouveaux filtres et lançait une nouvelle négociation Phase 2. Pendant la transition, des règles plus larges permettaient la réponse attendue. Après l’établissement, les SA et filtres résiduels pouvaient disparaître. Le port 1701 était un point de rendez-vous, pas une preuve permanente d’identité du tunnel.

Cette architecture comportait au moins quatre états : la connexion L2TP, l’association IKE Phase 1, les SA Phase 2 et les filtres installés. Leurs durées étaient liées mais non identiques. La suppression d’un tunnel devait entraîner celle des SA encore présentes pour ce tunnel. Une notification de suppression reçue par IKE devait remonter à L2TP. Après les accusés nécessaires, l’état du tunnel et les filtres pouvaient être retirés sans deviner que le pair les utilisait encore.

Un journal qui ne conserve qu’un événement « déconnecté » efface cette structure. Il ne dit pas si le contrôle L2TP a été fermé, si les clés IKE existent encore, si une SA de données subsiste ou si un filtre provisoire reste actif. RFC 3193 ne promettait pas une transaction atomique ; il demandait une coordination observable.

À la réception, L2TP devait encore effectuer deux tests. Il vérifiait d’abord qu’IPsec avait authentifié ou déchiffré le paquet : celui-ci venait donc de la bonne SA et non du réseau en clair. Il vérifiait ensuite que les adresses et ports UDP correspondaient au socket utilisé pour construire ce tunnel. Un pair de confiance pouvait envoyer un paquet protégé vers un autre contexte L2TP. L’authenticité cryptographique et l’appartenance au bon tunnel restaient deux affirmations.

La superposition avait aussi un coût matériel. Aux 1 500 octets souvent attendus par PPP s’ajoutaient les en-têtes L2TP et IPsec. Le RFC proposait de transmettre à PPP le MTU de l’interface diminué de cette surcharge avant la négociation LCP. Une découverte ultérieure d’un MTU plus petit devait être enregistrée par IPsec puis signalée à L2TP. Une observation de couche réseau ne corrigeait la couche PPP que si elle lui était communiquée.

Compression et ordre des paquets donnaient une autre leçon. L2TP était orienté connexion sans garantir l’ordre sur IP. Une méthode à état pouvait transformer une perte isolée en désynchronisation durable. Les méthodes sans état étaient donc préférables. Le mot tunnel ne transformait pas Internet en flux fiable.

Puis venait la frontière la plus délicate : qui avait été authentifié ?

PPP pouvait vérifier un utilisateur au début de la session. IKE pouvait vérifier une machine, puis utiliser les clés dérivées pour authentifier, contrôler l’intégrité et empêcher le rejeu de chaque paquet. Cette preuve répétée était forte, mais elle portait sur l’identité IKE. Elle ne répétait pas automatiquement l’authentification PPP.

Sur une machine multi-utilisateur, le problème devenait concret. Si IKE avait authentifié la machine et PPP une personne, IPsec pouvait accepter un paquet valide sans savoir quel compte local l’avait émis. Une fois le tunnel ouvert, un autre utilisateur de la machine pouvait souvent l’emprunter. L’intégrité du paquet ne réparait pas l’absence de séparation locale.

Une authentification utilisateur dans IKE permettait une meilleure liaison, mais ajoutait une exigence : le client devait empêcher le trafic des autres utilisateurs d’entrer dans ce tunnel. Même une identité cryptographique correcte ne produisait pas, à elle seule, la politique d’isolation sur l’hôte.

Les certificats déplaçaient encore l’autorité. Le LNS pouvait faire confiance à plusieurs autorités de certification ; les pratiques de révocation pouvaient varier. La valeur d’un certificat de machine dépendait du contrôle de l’enrôlement. Un certificat utilisateur sur carte à puce réduisait certains risques de copie, mais pouvait contredire une politique visant à autoriser seulement un matériel approuvé. Le support de clé ne décidait pas la finalité administrative du titre.

Les clés prépartagées de groupe révélaient une limite plus brutale. En accès distant, l’adresse du client était souvent dynamique. Avec Main Mode, le serveur pouvait avoir besoin de la clé avant de recevoir l’identité. Une seule clé partagée par un groupe devenait alors une preuve d’appartenance au groupe, non l’identité d’un pair particulier. Son détenteur pouvait se faire passer pour le LNS dans le modèle étudié et attaquer ensuite des méthodes PPP anciennes. Le RFC recommandait de ne pas utiliser cette clé de groupe pour authentifier le LNS.

Aggressive Mode rendait l’identité disponible plus tôt, au prix de son exposition. Les certificats amélioraient l’échelle, au prix d’une infrastructure d’enrôlement et de révocation. Le texte n’effaçait pas ces arbitrages sous un badge « sécurisé ».

Enfin, le point de départ du tunnel changeait ce que chacun savait. Dans un tunnel obligatoire, le client envoyait PPP au LAC sans nécessairement savoir que le tronçon LAC–LNS était protégé par IPsec. Le LNS pouvait examiner cette SA ; le client ne pouvait pas en déduire la protection de son propre lien jusqu’au LAC. Les deux côtés ne possédaient pas la même vue.

Dans un tunnel volontaire, le client créait L2TP et pouvait connaître les services négociés avec le LNS. Il pouvait alors éviter certaines duplications PPP. Mais le trajet après le LNS restait extérieur. RFC 3193 l’annonçait dès l'introduction : il normalisait la sécurité du tunnel, pas la sécurité de bout en bout.

Sa contribution historique tient à cette modestie. Il a obligé L2TP et IPsec à échanger des faits précis sans laisser l’un prétendre connaître l’identité, l’état ou le résultat de l’autre. Un tunnel sûr n’était pas une icône ; c’était un ensemble de preuves coordonnées dont les limites faisaient partie du protocole.