Résumé

  • RFC 7510 place dans le port source UDP une valeur d’entropie produite localement, afin que les routeurs IP existants répartissent le trafic MPLS sur des chemins ECMP ou des membres d’agrégation de liens.
  • Le port source et le port destination 6635 ne prouvent ni session, ni identité, ni droit d’accès. Les extrémités du tunnel, la configuration, les filtres, la maîtrise de la congestion, la pile MPLS et la protection cryptographique restent des surfaces distinctes.

Un détournement précis d’un champ familier

Le port source UDP a une apparence rassurante. Associé aux adresses source et destination, au port destination et au numéro de protocole, il complète le quintuplet que les équipements utilisent pour reconnaître un flux. Un pare-feu avec état s’attend souvent à voir la réponse parcourir le chemin inverse avec les ports permutés.

RFC 7510 rompt volontairement cette lecture. Dans un tunnel MPLS-in-UDP, le port source sert uniquement de source d’entropie. Le tunnel est unidirectionnel : les paquets vont vers un port destination attribué, mais aucun retour n’est envoyé au numéro utilisé comme port source.

Le champ reste au même endroit, mais sa fonction a changé. Sa stabilité peut maintenir les paquets d’un flux sur un même chemin et limiter le réordonnancement. Elle ne signifie pas qu’une application écoute. Sa visibilité permet aux routeurs intermédiaires de calculer un chemin. Elle ne dit pas qui contrôle l’encapsulateur.

Ce déplacement sémantique est l’intérêt du mécanisme. Le protocole réutilise une surface comprise par le matériel IP, tout en refusant de lui attribuer les propriétés d’une conversation de transport.

Mettre l’entropie à portée des routeurs IP

De nombreux routeurs savent déjà distribuer les microflux TCP et UDP sur des routes à coût égal ou des membres d’un groupe de liens. Ils calculent un hachage sur les adresses IP, les ports et le protocole. Le résultat évite qu’un seul flux change sans cesse de chemin, tout en répartissant des flux différents.

Un paquet MPLS directement encapsulé n’expose pas nécessairement assez de variation à un équipement qui ne lit pas profondément la pile d’étiquettes. Plusieurs flux internes peuvent alors se retrouver sur le même lien, malgré la capacité disponible ailleurs.

RFC 7510 ajoute une enveloppe IP et UDP. Les adresses externes désignent les extrémités du tunnel. Le port source fournit la variation que le matériel sait déjà intégrer à son hachage. Les équipements de transit peuvent ainsi répartir les paquets sans interpréter l’état MPLS interne.

Le schéma du format sépare clairement les plans. Il montre d’abord « port source = entropie » et « port destination = MPLS », puis la longueur et la somme de contrôle UDP. Viennent ensuite la pile d’étiquettes MPLS et le corps du message. L’enveloppe de répartition ne remplace pas le contexte de commutation qu’elle transporte.

Un flux défini par l’encapsulateur

Le texte décrit une valeur d’entropie de 16 bits, générée par l’encapsulateur pour identifier un flux. Mais il laisse deux décisions au domaine local : ce qui constitue un flux et l’algorithme qui produit la valeur.

Deux implémentations conformes peuvent donc choisir des entrées différentes. Une plate-forme peut hacher des champs internes détaillés ; une autre peut se limiter à ce qui est disponible à une étape donnée de sa chaîne de transfert. Le numéro extérieur n’a pas de dictionnaire universel permettant de retrouver un client ou une application.

Si le tunnel n’a pas besoin d’entropie, les paquets appartenant à un même flux devraient tout de même utiliser une constante choisie aléatoirement. La raison est d’éviter le désordre des paquets. La constance décrit une préférence de chemin, pas la persistance d’une identité.

Pour rester dans la plage dynamique ou privée, le RFC propose un hachage de 14 bits complété par deux bits de poids fort à 11. Le port se situe alors entre 49152 et 65535, en dehors des numéros plus bas réservés à des applications ou protocoles nommés.

Cette construction n’abolit ni la portée locale ni les collisions. Deux encapsulateurs peuvent produire la même valeur. Un même numéro peut désigner des regroupements différents au fil du temps. L’utiliser comme identifiant de locataire, de compte ou de principal de sécurité serait une extension non documentée.

Ce que 6635 dit — et ce qu’il tait

Le port destination 6635 est stable. Le registre IANA des noms de service et numéros de port l’associe à mpls-udp. Une extrémité correctement configurée sait ainsi que la charge utile doit être traitée comme un paquet MPLS.

Cette convention permet l’interopérabilité du décodage. Elle ne vérifie pas l’origine du datagramme, ne donne aucun droit d’utiliser le tunnel et ne valide aucune étiquette interne. Un numéro enregistré indique la nature annoncée de la charge utile, pas la légitimité de la relation.

Le RFC exige d’ailleurs que l’encapsulateur connaisse la capacité de l’autre extrémité à décapsuler MPLS-in-UDP. Une configuration manuelle ou une annonce dynamique peut transmettre ce savoir ; la méthode est hors périmètre. Le premier paquet reçu sur 6635 n’est donc pas l’établissement de la capacité.

Une règle de filtrage limitée à « autoriser UDP/6635 » confond indication de format et autorisation. Une politique plus exacte lie le trafic à des adresses attendues, une interface, un domaine d’exploitation, une configuration de pair et, selon le risque, à une clé ou à un état de signalisation.

La pile MPLS conserve sa propre autorité de transfert

Après décapsulation, la charge utile reste une pile d’étiquettes MPLS. RFC 3032 définit son encodage. RFC 3031, signé par Eric Rosen, Arun Viswanathan et Ross Callon, décrit une étiquette comme un identifiant court, de longueur fixe et de signification locale, utilisé pour le transfert.

La signification locale impose une autre limite. L’étiquette supérieure n’a de sens que dans le contexte où elle a été attribuée. Le caractère mondial du numéro 6635 ne mondialise pas la pile interne. Le décapsulateur doit entrer dans le bon espace d’étiquettes et appliquer les règles d’attribution appropriées.

L’entropie peut aussi se trouver à l’intérieur de MPLS. RFC 6790 définit un indicateur d’étiquette d’entropie et une étiquette d’entropie dans la pile. RFC 7510 place au contraire le signal dans le port source extérieur, pour qu’un équipement IP puisse le voir.

Ces mécanismes ne sont pas interchangeables et ne servent pas nécessairement les mêmes appareils. Ils partagent néanmoins une limite : ni une étiquette d’entropie ni un port d’entropie ne sont une authentification. La position d’un signal détermine sa visibilité, pas le droit de son émetteur.

La fausse symétrie vue par les équipements avec état

Le caractère unidirectionnel du tunnel met à l’épreuve les hypothèses des pare-feu et des dispositifs NAT. Ceux-ci associent souvent les deux sens d’une communication à une même paire de ports inversée. MPLS-in-UDP peut nécessiter une configuration indépendante dans chaque sens.

La conséquence touche également l’observabilité. Un collecteur peut afficher un quintuplet stable et l’appeler « session », alors qu’aucune application n’est liée au port source et qu’aucun retour n’est exprimé par le même couple. Le mot commode masque la fonction réelle du champ.

Il est préférable de conserver plusieurs enregistrements. Le quintuplet extérieur décrit un paquet de tunnel et un compartiment d’entropie. La gestion de configuration décrit les pairs autorisés. La pile d’étiquettes décrit le contexte de transfert. Les champs internes, lorsqu’ils sont observables, décrivent le trafic transporté.

Le rapprochement de ces preuves est utile. Leur fusion dans une identité unique ne l’est pas. Une collision de 16 bits ne doit pas devenir une collision de clients dans les outils administratifs.

Somme de contrôle et attribution du risque

Pour IPv4, RFC 7510 recommande une somme de contrôle UDP nulle pour des raisons de performance ou d’implémentation, tout en reconnaissant l’importance de protéger certaines piles d’étiquettes VPN. Pour IPv6, la somme de contrôle reste obligatoire par défaut.

RFC 6935 ouvre une exception limitée pour les tunnels IPv6. RFC 6936 en précise les conditions : domaine étroitement maîtrisé, risque de corruption mesuré ou compris, applications tolérantes et acceptation explicite du risque résiduel. Un équipement qui rejette les datagrammes IPv6 sans somme peut créer un trou noir.

RFC 8085 replace ensuite l’entropie du port source dans les recommandations générales d’usage d’UDP. Emprunter à UDP ses champs pratiques ne dispense pas de traiter les sommes de contrôle, les équipements intermédiaires et la congestion.

La décision de supprimer un calcul répartit les coûts. Elle peut accélérer le traitement, mais elle désigne aussi la partie qui supportera une corruption non détectée. Une valeur d’entropie ne compense pas une protection d’intégrité absente.

Un périmètre de coopération, pas l’Internet ouvert

RFC 7510 limite MPLS-in-UDP au réseau d’un seul opérateur ou à des réseaux adjacents d’opérateurs coopérants, capables de gérer le trafic pour éviter la congestion. Il ne destine pas cette encapsulation à l’Internet ouvert, où le contrôle de congestion est requis. Des filtres devraient empêcher les paquets de sortir du périmètre à la suite d’une erreur.

Le périmètre est institutionnel autant que technique. Des opérateurs qui coopèrent peuvent coordonner capacité, admission, supervision et réponse aux incidents. En dehors de cette relation, un tunnel UDP peut faire supporter ses coûts de congestion à des tiers qui n’ont pris part à aucune décision.

Le document indique aussi que MPLS-in-UDP ne garantit seul ni intégrité, ni confidentialité, ni authentification de l’encapsulateur. Il examine IPsec et DTLS lorsque ces propriétés sont nécessaires. IANA enregistre 6636 pour la variante avec DTLS, mais les clés, les pairs et la politique doivent toujours être établis.

La frontière de confiance comprend donc les adresses des extrémités, la configuration ou la signalisation de capacité, le périmètre autorisé, les filtres, la discipline de congestion, la somme de contrôle, l’espace d’étiquettes et la protection de sécurité. Le port 6635 est lisible à l’intérieur de cette frontière ; il ne la crée pas.

Ross Callon dans une œuvre collective

Le profil IETF Datatracker de Ross Callon répertorie huit RFC, parmi lesquels l’architecture MPLS de RFC 3031 et l’encapsulation de RFC 7510. Cette trace publique relie des travaux sur l’adressage OSI, la transition IPv6, MPLS et les VPN d’opérateur.

Elle documente une contribution, pas une propriété personnelle de la norme. RFC 7510 compte cinq auteurs et résulte du processus de consensus de l’IETF. Les implémenteurs choisissent leurs entrées de hachage, les opérateurs fixent le périmètre, IANA tient le registre. Le récit d’une personne doit conserver cette pluralité.

Une continuité intellectuelle demeure visible. RFC 3031 précise la portée locale d’une étiquette ; RFC 7510 enveloppe ensuite cette pile dans une structure que les équipements IP existants peuvent répartir. Dans les deux cas, la fiabilité dépend du refus de faire dire à un champ plus qu’il ne sait dire.

Un port peut être de l’entropie sans être une session. Un numéro mondial peut annoncer MPLS sans autoriser un pair. Une étiquette peut orienter le transfert sans nommer un propriétaire. Cette modestie sémantique est une condition de l’interopérabilité, pas une lacune.

Limites de la preuve

Les sources publiques établissent le format et les restrictions de RFC 7510, ses recommandations de somme de contrôle et de sécurité, les enregistrements IANA, les normes de pile MPLS et la qualité de coauteur de Ross Callon. Elles n’établissent ni le volume actuel de déploiement, ni le comportement d’un fournisseur, ni un incident réel causé par une collision, ni une fonction institutionnelle actuelle de Callon.

L’avertissement contre l’usage de l’entropie comme identité est une analyse éditoriale tirée des sémantiques explicites et des limites de sécurité du RFC. Ce n’est pas le compte rendu d’une attaque identifiée. L’article ne prétend pas non plus que les deux formes d’entropie MPLS sont interchangeables.

Sources