Résumé

  • RFC 2784 distingue l'en-tête de livraison, l'en-tête GRE et la charge utile. Son socle de quatre octets identifie le protocole intérieur, mais n'accorde aucun droit d'usage et ne garantit ni confidentialité, ni authentification, ni accessibilité après décapsulation.
  • Tony Li a cosigné le texte GRE de 1994 et la spécification Standards Track de 2000. Les RFC ultérieures rendent la dette d'exploitation visible : le champ Key est un identifiant de contexte, le séquençage crée un état attaquable, et le transport d'IPv6 impose de mesurer continuellement le MTU et les limites d'intégrité.

L'adresse extérieure n'efface pas l'adresse intérieure

À l'entrée du tunnel, le paquet d'origine devient une charge utile. Un en-tête GRE le précède, puis un protocole de livraison enveloppe l'ensemble. Le réseau sous-jacent lit la destination extérieure. À la sortie, ces couches sont retirées et la destination intérieure redevient la base du transfert.

Trois registres coexistent donc. L'en-tête de livraison nomme les extrémités. GRE indique la nature du contenu et les options actives. Le paquet intérieur garde sa source, sa destination, sa durée de vie et ses protocoles supérieurs. Une route extérieure valide prouve seulement que l'enveloppe peut atteindre l'egress. Elle ne prouve pas que la destination intérieure est autorisée, joignable ou inspectée au bon endroit.

RFC 2784, publié sur le Standards Track en mars 2000, est signé par Dino Farinacci, Tony Li, Stan Hanks, David Meyer et Paul Traina. Il succède à l'Informational RFC 1701, de Hanks, Li, Farinacci et Traina. Le profil IETF Datatracker de Tony Li fournit son identité publique, son index de RFC et ses fonctions au moment de la capture. Ces éléments prouvent une contribution collective, pas une invention solitaire, un employeur actuel ou un pouvoir personnel sur les déploiements.

L'intérêt du parcours est précis : Li se trouve dans le premier énoncé d'une enveloppe générale, puis dans le texte qui en réduit le noyau commun. La retenue devient ici une décision d'architecture. Le standard partage un format sans absorber les choix des réseaux qui l'utilisent.

Sortir d'une matrice de protocoles

Si chaque protocole intérieur exige une méthode différente pour chaque protocole de transport, les combinaisons forment une matrice qui croît avec les deux ensembles. RFC 2784 décrit ce problème comme O(n²) et propose une séparation plus maniable : charge utile, enveloppe GRE commune, livraison.

Le texte ne confond pas généralité et supériorité. Des nuances propres aux protocoles sont volontairement ignorées ; une encapsulation spécialisée X over Y peut être préférable. Surtout, la RFC refuse de dire quand un paquet doit être encapsulé. Elle normalise une grammaire, pas la justification d'un tunnel.

Une entreprise peut réunir deux espaces privés, un opérateur transporter un service, un laboratoire tester un protocole que l'underlay ne connaît pas. La conformité du format ne légitime aucun de ces usages. Il faut encore nommer le propriétaire, les extrémités, les charges admises, le niveau de sécurité, la capacité et la condition de retrait.

Le gain économique est réel mais borné. Une enveloppe commune réduit les coûts d'implémentation et de coordination. Elle ne prend pas en charge le black hole, la fuite, l'angle mort du pare-feu ni la dépendance oubliée. L'organisation qui économise grâce à GRE garde l'exposition créée par son choix.

Quatre octets, aucune autorité cachée

Sans checksum optionnel, le socle RFC 2784 contient deux mots de 16 bits. Le premier porte le bit de présence du checksum, des bits réservés et la version. Le second est le Protocol Type, un EtherType qui annonce la charge utile. La version de base vaut zéro.

Il n'existe dans ce champ ni identifiant mondial du tunnel, ni propriétaire, ni politique, ni route, ni promesse de chiffrement. L'en-tête indique seulement comment lire les octets suivants. Un type inconnu devrait être rejeté. Les bits réservés sont émis à zéro ; certaines positions non nulles doivent entraîner le rejet si le récepteur n'implémente pas les anciennes extensions.

Le checksum ajoute quatre octets et couvre l'en-tête GRE et la charge utile. Il peut détecter une altération accidentelle. Il ne prouve pas l'identité de l'émetteur et ne rend pas le contenu secret. Transformer « checksum valide » en « tunnel fiable » serait une erreur de catégorie.

Une spécification minimale n'est donc pas vague. Elle fixe strictement les faits dont deux implémentations ont besoin et laisse visibles les décisions qu'elle ne prend pas.

Après l'ouverture, la charge utile récupère la route

Lorsque la charge est IPv4, RFC 2784 demande à l'egress d'utiliser sa destination intérieure et de décrémenter son TTL. La destination extérieure a terminé sa fonction et ne remplace pas la sémantique de routage du paquet transporté.

La RFC définit également une condition de boucle : si la destination intérieure est l'encapsulateur à l'autre bout, le paquet peut repartir dans la relation et doit être abandonné. Masquer une partie de la topologie ne supprime pas la causalité d'une boucle.

Cette distinction structure le diagnostic. Un traceroute extérieur peut atteindre l'egress alors que la route intérieure manque. Une interface de tunnel peut être up tandis que le paquet est refusé après décapsulation. À l'inverse, une panne applicative attribuée à GRE peut résider dans l'underlay, le retour, le filtrage ou le MTU. Les trois registres doivent être observés séparément puis rattachés au même paquet.

La standardisation a retiré des sens du noyau

RFC 1701 proposait Routing, Key, Sequence, Strict Source Route et contrôle de récursion. RFC 2784 a retenu l'intersection déjà déployée par plusieurs fournisseurs et a déprécié ces fonctions dans son profil de base. Un récepteur qui ne déclare pas l'ancien comportement refuse les bits correspondants lorsqu'ils sont non nuls.

Cette évolution ne suit pas le récit habituel où chaque version ajoute des options. Le noyau commun a rétréci afin que des implémentations indépendantes s'accordent sur moins de sens, mais avec davantage de certitude. Des besoins optionnels peuvent revenir dans une extension explicite au lieu d'être devinés à partir d'un espace réservé.

La compatibilité devient une frontière de refus explicable. Lorsqu'une extrémité attend une extension que l'autre ne possède pas, accepter un layout supposé ne répare rien. Il faut prouver la paire de capacités, activer seulement le profil partagé et conserver un retour vers le contrat de parsing précédent.

Le champ Key n'est pas une clé de sécurité

RFC 2890, rédigé par Govindan Dommety et non par Li, définit ultérieurement les extensions Key et Sequence Number. Le Key de quatre octets identifie un flux ou un contexte entre les extrémités ; la méthode d'attribution est hors périmètre.

Le nom invite à une conclusion fausse, que le texte corrige expressément : ce Key n'apporte aucune sécurité. Une convention locale peut lui faire distinguer des clients ou des services. Sans protection extérieure, un acteur capable de construire GRE peut néanmoins recopier ou inventer sa valeur. Ce label de contexte ne doit jamais être traité comme un mot de passe.

Sequence Number ajoute un autre engagement. Il vise une livraison non fiable mais ordonnée. Le récepteur conserve la dernière valeur décapsulée, rejette les valeurs anciennes et peut absorber un désordre limité dans un buffer. L'utilité pour certaines charges se paie par un état par flux. Une injection de numéro élevé peut faire paraître l'activité légitime trop ancienne.

RFC 2890 exige AH ou ESP d'IPsec pour ce modèle de menace. Il déconseille aussi de reproduire l'ordre lorsque la couche supérieure le fournit déjà ou tolère le désordre. Activer un bit optionnel signifie accepter mémoire, buffering, journaux, compteurs et surface d'attaque aux deux extrémités.

Filtrer là où le contenu redevient visible

RFC 2784 observe que le filtrage des routes reste proche d'IPv4 natif, tandis que le filtrage des paquets doit regarder dans GRE ou être placé aux extrémités. L'underlay peut autoriser correctement le protocole 47 entre deux adresses sans connaître le protocole, l'adresse ou le port intérieurs.

La responsabilité se perd facilement à cet endroit. L'équipe transport affirme que la route externe est bornée. L'équipe sécurité autorise GRE entre les deux nœuds. L'équipe service suppose que son trafic intérieur hérite des deux contrôles. Pourtant aucun fait extérieur ne définit ce qui est admis après décapsulation.

Une exploitation vérifiable consigne les préfixes et protocoles intérieurs autorisés, le lieu de décapsulation, le point d'inspection et la présence réelle d'IPsec. GRE up n'est pas un état de sécurité. La preuve est la politique effectivement appliquée aux deux couches, observée sur le paquet qui les traverse.

IPv6 transforme les omissions en conditions d'activation

RFC 7676, de Carlos Pignataro, Ron Bonica et Suresh Krishnan, définit plus tard IPv6 comme charge ou protocole de livraison. Ce n'est pas une œuvre de Li. Elle montre ce que devient le contrat mince lorsqu'une nouvelle couche réseau lui impose des obligations précises.

Un tunnel portant une charge IPv6 doit transporter un paquet de 1 280 octets de l'ingress à l'egress sans fragmenter la charge. L'ingress vérifie cette capacité avant activation puis périodiquement, et active ou désactive le tunnel selon le résultat. Le GMTU est le MTU du chemin entre les extrémités moins les en-têtes de livraison et GRE. Un paquet intérieur trop grand doit, selon le cas, être abandonné avec un ICMPv6 Packet Too Big indiquant la valeur utilisable.

La petite taille de GRE ne supprime donc pas le problème de taille. Elle rend l'overhead calculable et place la mesure ainsi que le feedback sous la responsabilité de l'ingress. Si le message PTB disparaît, les petits probes fonctionnent, les flux plus grands se figent et le contrôle reste vert.

La limite d'intégrité est tout aussi concrète. Désactiver le checksum GRE réduit parfois un calcul redondant. Mais un en-tête de livraison IPv6 n'a pas son propre checksum, et celui de GRE ne le couvrirait pas. RFC 7676 analyse un cas rare où la corruption de la destination extérieure livre le paquet au mauvais routeur PE ; des adresses privées qui se recouvrent peuvent alors conduire la charge dans le mauvais VPN. Le déploiement ne doit pas avoir lieu si l'opérateur n'accepte pas ce risque ; l'authentification de bout en bout de la charge peut le réduire.

Le texte ne prétend pas qu'un réseau donné subit cette défaillance. Il rend obligatoire une décision locale documentée. Savoir transporter tout protocole ne signifie pas savoir le transporter en sécurité partout.

Plus la coordination est mince, plus la preuve en bordure doit être épaisse

Le texte ultérieur de Lu Heng, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption, fournit à Sofia Ren un cadre pour lire GRE. Le commun peut se limiter au layout, à la version, au type, aux extensions et au rejet. Chaque réseau garde la liberté et la charge de décider du but, des extrémités, de l'admission, de la sécurité et du retrait.

Running-Code Primacy relève le niveau de preuve. Un objet de configuration reste une intention. La chaîne réelle relie route extérieure, flags émis, Protocol Type, overhead effectif, contexte Key, association de sécurité, route intérieure, décision du filtre, feedback MTU, compteurs et résultat applicatif.

Ces textes de Heng sont un cadre éditorial postérieur, non une preuve de l'intention privée de Li ni d'un consensus IETF au-delà des RFC citées. Ils clarifient l'allocation : le standard possède l'enveloppe commune, l'implémentation le parsing et l'état, l'opérateur toutes les raisons qui autorisent l'enveloppe à exister.

GRE a duré parce qu'il ne gouverne pas sa charge. Cette retenue le rend transportable. Elle signifie aussi qu'aucune institution ne réside dans les quatre octets pour sauver un déploiement négligent. L'enveloppe peut porter presque tout ; seules ses extrémités peuvent prouver ce qu'elle devrait porter.

Sources