Résumé
- La RFC 3948 a fait cohabiter IKE et ESP encapsulé dans UDP sur la même association NAT ; quatre octets nuls désignaient IKE parce qu’un SPI ESP valide ne pouvait pas valoir zéro.
- Ce marqueur n’était qu’un aiguillage. La recherche de l’association de sécurité, l’anti-rejeu, les contrôles cryptographiques, la politique des adresses internes et le résultat applicatif restaient des preuves distinctes.
La règle de pare-feu cachait trois usages
Vu depuis un pare-feu, UDP 4500 pouvait sembler être un service unique. Vu depuis l’extrémité IPsec, il transportait pourtant au moins trois choses différentes : les échanges IKE qui créaient ou renouvelaient l’état de sécurité, les paquets ESP qui portaient les données protégées, et un minuscule datagramme destiné uniquement à empêcher un traducteur d’oublier son association.
La RFC 3948 choisit expressément ce partage. Une seule association NAT améliorait le passage à l’échelle, évitait d’entretenir séparément le chemin d’IKE, simplifiait la configuration des pare-feu et réduisait le nombre de mécanismes à mettre en œuvre. La RFC 3947 décrivait la négociation de la traversée NAT et le déplacement des échanges IKE vers le port 4500.
Le gain n’abolissait pas la différence entre plan de contrôle et trafic protégé. Puisque le port ne suffisait plus à sélectionner le bon traitement, le premier mot de la charge UDP devait fournir une séparation minimale.
Une valeur impossible devint une frontière
Le premier champ d’un en-tête ESP est le SPI, un index de 32 bits qui aide le destinataire à retrouver l’association de sécurité pertinente. Dans la RFC 2406, zéro est réservé et n’est pas une valeur ESP ordinaire sur le réseau. La RFC 3948 renforce cette contrainte : un paquet ESP encapsulé ne doit pas employer un SPI nul.
Pour IKE sur UDP 4500, quatre octets nuls sont insérés avant l’en-tête IKE. Le document les appelle « marqueur non-ESP ». Ils tombent exactement à l’endroit où le récepteur lirait le SPI d’un paquet ESP. Zéro conduit donc vers l’analyseur IKE ; une valeur non nulle peut conduire vers ESP.
Cette convention est efficace parce qu’elle réutilise une valeur exclue au lieu d’ajouter un nouveau port ou une négociation supplémentaire. Mais les quatre octets ne prouvent rien sur l’émetteur. Ils ne sont ni un secret, ni une signature, ni un code d’intégrité, ni l’identifiant d’une association IKE. Un paquet peut franchir correctement cette première porte puis être rejeté comme message IKE mal formé, inattendu ou non authentifié.
La branche ESP possède la même limite. Un mot non nul peut être interprété comme SPI, mais il faut encore retrouver une association installée dans le bon contexte, vérifier le numéro de séquence, l’état anti-rejeu, la protection cryptographique et la politique de trafic. Un SPI inconnu ou un contrôle d’intégrité en échec n’est pas réparé par le fait que le classement initial était juste.
0xFF entretenait le passage, pas le pair
Le troisième format est encore plus court : une charge d’un seul octet, 0xFF, envoyée avec les mêmes ports. Son unique fonction est de maintenir l’association NAT. Le destinataire devrait l’ignorer, et la RFC énonce que sa réception ne doit pas servir à décider si la connexion est vivante.
Cette phrase sépare deux horloges souvent confondues. Le traducteur peut renouveler son délai parce qu’un datagramme est passé. L’extrémité peut néanmoins avoir perdu son état IKE, supprimé l’association ESP, refusé le trafic interne ou arrêté l’application. Inversement, une association de sécurité peut encore être valide alors qu’un état NAT a expiré.
Les valeurs par défaut historiques—vingt secondes d’inactivité avant l’entretien lorsqu’il est nécessaire, et une fenêtre configurable de cinq minutes après l’existence d’une association—ne sont pas des promesses universelles. Elles montrent plutôt qui décide : le NAT expire son propre état, l’émetteur programme les keepalive, IKE et ESP ont leurs propres durées. Aucun compteur ne devient le certificat des autres.
Après l’aiguillage commençaient les décisions coûteuses
L’encapsulation UDP n’a pas remplacé ESP. La RFC demande l’encapsulation ou la décapsulation ESP ordinaire après ajout ou retrait de l’en-tête UDP. Puis il reste à traiter les conséquences de la traduction d’adresses.
En mode tunnel, une politique locale peut vérifier que l’adresse source interne appartient à un espace autorisé, qu’elle correspond à une adresse attribuée au pair, ou la traduire avant livraison. En mode transport, la modification des adresses peut invalider les sommes de contrôle TCP ou UDP ; le récepteur doit suivre l’une des méthodes de correction précisément encadrées. Les quatre zéros ne choisissent aucune de ces politiques.
La RFC montre aussi deux conflits. Des ordinateurs derrière des NAT différents peuvent présenter la même adresse privée à une passerelle. Plusieurs clients derrière une même adresse publique peuvent proposer des sélecteurs qui se chevauchent. Dans les deux cas, l’adresse extérieure achemine jusqu’à un bord, mais ne nomme pas de façon unique le pair ou l’association à choisir ensuite. Les implémentations doivent assigner des adresses locales distinctes, traduire, refuser le conflit ou employer une autre résolution explicite.
Ces limites prolongent les cas recensés par la RFC 3715. Celle-ci formulait les exigences de compatibilité ; la RFC 3948 apportait un mécanisme concret sans prétendre qu’un nouvel en-tête avait supprimé les ambiguïtés de politique.
La convention a survécu parce qu’elle n’a pas prétendu davantage
La notice officielle de la RFC 3948 la classe comme document Standards Track de janvier 2005. Son erratum accepté corrige seulement la référence à un cas de la RFC 3715 ; il ne change ni les formats ni le marqueur.
La RFC 7296 conserve la règle pour IKEv2 : sur UDP 4500, IKE porte quatre octets nuls en préfixe, alors qu’ESP commence directement par un SPI qui ne peut valablement être nul. Elle autorise aussi l’emploi initial de 4500 sans preuve préalable d’un NAT. Observer ce port ne suffit donc pas à conclure qu’une traduction a eu lieu.
L’histoire tient dans une distinction disciplinée. Le port coordonne l’arrivée. Le premier mot choisit un analyseur candidat. IKE ou ESP produit ensuite son propre verdict. La politique décide quel trafic interne peut continuer. L’application fournit enfin l’observation utile. Les quatre octets ont rendu un partage possible ; ils n’ont reçu aucune autorité sur les étapes suivantes.
Sources
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
