Résumé

  • Le RFC 1701 suggérait que le champ Key de quatre octets puisse authentifier la source, tout en laissant hors spécification sa création, son échange, sa protection et sa vérification.
  • Le RFC 2890 lui a donné une portée exécutable : identifier un flux logique dans un tunnel. Il précise que Key n’intervient dans aucune forme de sécurité, malgré son nom.
  • Sequence Number peut maintenir un ordre propre au flux, mais une valeur arbitraire injectée peut avancer l’état du récepteur et faire rejeter des paquets légitimes. L’intégrité doit donc protéger séparément l’en-tête GRE et la charge utile.

Le nom portait déjà une promesse

Dans un système technique, clé évoque rarement un simple numéro. Le mot suggère un secret, une capacité ou un moyen d’ouvrir un contrôle. Lorsqu’il apparaît dans une configuration de tunnel, la tentation est immédiate : si la Key correspond, le paquet viendrait du bon pair.

Le RFC 1701 montre pourquoi cette déduction était prématurée. Publié en 1994 dans la catégorie Informational, il proposait une encapsulation générale d’un protocole réseau dans un autre. Un en-tête de livraison transporte l’en-tête GRE, puis la charge utile. Le format prévoyait des champs facultatifs de checksum, de routage, de Key et de Sequence Number.

Le texte disait que le récepteur pouvait utiliser Key pour authentifier la source du paquet. Il repoussait toutefois à l’extérieur toutes les techniques permettant d’établir cette authenticité. Il ne fixait ni génération, ni distribution, ni liaison à un pair, ni durée de vie, ni protection contre la copie ou la modification. Deux extrémités pouvaient donc partager un nombre sans partager la même preuve.

Sequence Number souffrait du même inachèvement. Le champ pouvait servir à établir l’ordre d’émission, mais les algorithmes de numérotation et les conséquences à la réception restaient hors champ. Le paquet avait une place pour l’information ; il manquait encore la règle commune qui lui donnerait effet.

Le socle commun a commencé par retrancher

En mars 2000, le RFC 2784 a choisi le plus petit dénominateur effectivement déployé chez plusieurs constructeurs. Le socle GRE normalisé conservait le bit de présence du checksum, la version et Protocol Type, qui identifie le protocole contenu. Il ne transformait pas les anciens bits en signaux dont le sens serait deviné au cas par cas.

Les bits 1 à 5 devinrent une frontière de compatibilité. Un émetteur limité au RFC 2784 les plaçait à zéro. Un récepteur qui ne comprenait pas le RFC 1701 devait rejeter le paquet s’ils étaient non nuls. Des règles distinctes décrivaient la rencontre avec les anciens équipements.

Cette réduction avait une vertu : l’interopérabilité reposait sur ce que le code annonçait savoir lire, non sur la réputation du fournisseur ou sur l’intention supposée de l’opérateur. GRE précisait l’encapsulation ; il ne décidait toujours pas pourquoi un paquet devait être admis dans le tunnel.

Le champ est devenu utile en perdant de l’autorité

Le RFC 2890, publié six mois plus tard, a réutilisé les positions K et S du RFC 1701. K annonce une Key de quatre octets ; S, un Sequence Number de quatre octets. La compatibilité binaire a été conservée, mais les devoirs centraux ont enfin été définis.

L’encapsulateur insère la Key. La manière de l’obtenir reste une décision extérieure au document. À l’autre extrémité, le nombre identifie un flux de trafic individuel lorsque les données encapsulées ne fournissent pas le contexte dont le tunnel a besoin. Les paquets du même flux reprennent la même valeur ; le décapsulateur la relie à son propre traitement local.

Il s’agit d’un espace de noms situé. Le même entier, placé entre d’autres extrémités ou sous une autre configuration, peut désigner autre chose. Il ne déclare ni propriétaire, ni permission, ni secret. Une machine capable de fabriquer un paquet peut copier quatre octets visibles.

La section consacrée à la sécurité tranche alors le malentendu historique : Key n’est impliquée dans aucune sécurité, malgré son nom. Le RFC n’a pas changé l’étiquette ; il a empêché l’étiquette de devenir une preuve.

L’ordre restait une prestation non fiable

Le champ S apporte, lui, une mémoire partagée plus précise. L’encapsulateur emploie un compteur libre de 32 bits, initialisé à zéro et calculé modulo 2^32. Le décapsulateur mémorise le dernier paquet qu’il a correctement ouvert. Si K est présent, cet état est propre au flux choisi par cette Key.

La valeur suivante est dans l’ordre. Une valeur ancienne ou dupliquée doit être silencieusement abandonnée. Une avance qui laisse un trou révèle une perte ou un réordonnancement possible. Le récepteur peut attendre brièvement dans un petit tampon par flux, puis libérer ce qu’il possède et passer le manque lorsqu’un délai ou une limite de capacité est atteint.

Le RFC parle de livraison non fiable mais ordonnée. Sequence ne retransmet rien et ne garantit pas l’arrivée. Il borne seulement la manière dont un récepteur arbitre entre une attente courte et l’acceptation d’un trou.

L’ordre n’est pas global. Des paquets sans S peuvent s’intercaler. Lorsque K est utilisé, chaque flux possède son propre historique. Une lacune prouve donc une discontinuité dans l’état observé de ce flux, pas la cause : perte, filtrage, retard excessif, redémarrage ou paquet jamais émis restent à distinguer.

Le faux futur pouvait condamner les vrais paquets

Imaginons que le récepteur ait validé la séquence 40. Un tiers injecte ensuite un paquet portant la bonne Key mais une valeur très éloignée dans le futur. Sans protection d’intégrité externe, ce paquet peut faire avancer la mémoire. Les paquets légitimes arrivant ensuite paraissent anciens et sont rejetés par la règle d’ordre elle-même.

Le RFC 2890 décrit cette injection arbitraire comme une voie de déni de service. Il exige une protection IP distincte couvrant l’en-tête GRE et la charge utile. La portée de la protection est décisive : les champs qui dirigent la classification et modifient l’état de réception doivent eux aussi être authentifiés.

Sequence Number n’est donc pas, à lui seul, une défense contre le rejeu. Une fenêtre anti-rejeu n’acquiert de valeur qu’après la preuve que le paquet appartient bien à l’association protégée. Faute de cette étape, l’attaquant peut écrire le passé auquel les prochains paquets seront comparés.

La confidentialité reste encore une question différente. Ni K ni S ne cachent la charge utile. L’opérateur peut retenir une protection d’intégrité seule ou y ajouter le chiffrement ; GRE ne prend pas cette décision à sa place.

Une mise à jour récente, une responsabilité différente

Le RFC 9601 de 2024 est l’autre mise à jour formelle du RFC 2784. Il traite la propagation d’ECN lorsque GRE sert de couche intermédiaire entre des en-têtes IP, et impose une configuration sûre à l’entrée lorsque le protocole de livraison est IPv4 ou IPv6.

Cette obligation ne grandit pas la Key. ECN transporte une indication de congestion entre couches. Key choisit un contexte de flux. Sequence organise les paquets reçus dans ce contexte. Une protection externe établit leur provenance et leur intégrité. Ces fonctions peuvent cohabiter dans un même tunnel sans devenir interchangeables.

Le RFC 9601 rappelle aussi que GRE ne possède pas de mécanisme dynamique propre pour créer ou configurer le tunnel. Une capture montre les bits K et S ; elle ne montre pas le contrat de contrôle qui a attribué le nombre ni l’autorité qui a admis le pair.

Observer la décision, puis rechercher sa cause

Un compteur de paquets hors séquence ne constitue pas un diagnostic complet. Il peut augmenter à cause d’un réordonnancement normal, de doublons, d’un tampon trop petit, d’un redémarrage, d’une divergence de configuration ou d’une injection. Il prouve que le récepteur a pris une décision selon son état, pas pourquoi cet état s’est présenté.

L’audit doit donc relier la paire d’extrémités, l’espace de Key, le mappage local du flux, l’usage attendu de S, la dernière valeur admise et le résultat de la vérification d’intégrité. Dire seulement « la Key correspond » efface précisément la séparation que la norme avait restaurée.

L’apport durable du RFC 2890 tient dans cette modestie. Le tunnel a obtenu un identifiant de contexte et une mémoire d’ordre. Il n’a obtenu ni identité, ni permission, ni secret. La sécurité commence là où un mécanisme distinct peut réellement vérifier ces affirmations.

Sources