Résumé

  • Le SYN MP_JOIN présente le Token du récepteur pour retrouver une connexion MPTCP existante ; les HMAC réciproques et la politique locale déterminent ensuite si le sous-flux peut y entrer.
  • Une correspondance de jeton, une preuve HMAC, un sous-flux TCP établi et le résultat d'une application ne sont pas le même fait.

On décrit volontiers MPTCP comme une manière de conserver un seul flux d'octets quand les chemins changent. Cette description est vraie pour l'application, mais elle masque le mécanisme qui protège l'attachement d'un nouveau flux TCP. Le protocole ne déclare pas qu'une adresse nouvellement vue appartient à une session parce qu'elle l'affirme. Il ordonne quatre opérations : retrouver l'état visé, établir une continuité avec les pairs initiaux, laisser l'hôte destinataire accepter ou refuser, puis exploiter le nouveau cinq-uplet comme un TCP ordinaire.

RFC 6182 avait posé ce partage architectural en 2011. Le programme utilisateur devait conserver le service TCP—un flux d'octets fiable et ordonné—tandis que le réseau voyait plusieurs sous-flux ressemblant à du TCP classique. Des adresses multiples servaient de signal utilisable pour chercher plusieurs chemins ; elles ne garantissaient ni des routes physiquement séparées ni un gain de débit. Le document exigeait aussi la compatibilité avec TCP, les intermédiaires et les autres utilisateurs du goulot partagé.

Cette retenue donne son sens à la suite. MPTCP ajoute un état de connexion au-dessus de plusieurs états TCP sans faire disparaître ces derniers. Une nouvelle paire adresse-port ne peut donc rejoindre l'ensemble qu'après une décision nommée et vérifiable.

La première poignée de main produit le passé pertinent

La première liaison commence sur un chemin unique. Dans RFC 8684, les trois segments initiaux transportent MP_CAPABLE. L'option négocie la version MPTCP de cette connexion et échange les clés qui serviront à authentifier les sous-flux ultérieurs. Si l'échange indispensable manque—par incompatibilité du pair ou parce qu'un intermédiaire retire l'option—la spécification prévoit un repli vers TCP à chemin unique.

Ce repli évite d'inventer un état intermédiaire. La présence d'une option sur une tentative ne prouve pas que tout autre chemin la préservera. Elle ne prouve ni l'identité de l'utilisateur, ni l'autorisation de l'application, ni la propriété d'une adresse IP, ni la qualité future d'une route. Elle constate seulement une négociation de transport sur ce premier sous-flux.

Le parcours documentaire compte aussi. RFC 6824, publié en janvier 2013, était Expérimental : il demandait mise en œuvre et évaluation, sans constituer une norme Internet. RFC 8041 a réuni en 2017 des retours opérationnels datés, notamment sur les intermédiaires et la gestion des sous-flux. RFC 8684, norme IETF de 2020, a rendu RFC 6824 obsolète et précise que v1 a été clarifiée et modifiée principalement à partir de l'expérience de déploiement. Cette chaîne atteste une révision nourrie par l'expérience ; elle n'atteste ni la part de marché actuelle ni le comportement d'un équipement précis.

Le Token pointe vers un état ; il ne confère aucun droit

Après la première connexion, un hôte peut tenter un sous-flux supplémentaire. Le premier SYN MP_JOIN contient le Token de l'hôte qui le reçoit, un nombre aléatoire nouveau fourni par l'émetteur et un Address ID. Avec le choix SHA-256 de v1, le Token est constitué des 32 bits de poids fort du hachage SHA-256 de la clé initiale du récepteur. Sa tâche est limitée : permettre au récepteur de retrouver la connexion MPTCP locale que le SYN désigne.

C'est une opération de démultiplexage, pas un titre de propriété.

RFC 8684 distingue même deux moments. À l'arrivée du SYN, le Token sert à sélectionner l'ancienne connexion, car le nouveau sous-flux ne possède pas encore de cinq-uplet déjà connu par cette connexion. Une fois le sous-flux établi, les paquets sont démultiplexés, comme en TCP, par leur cinq-uplet. Le Token n'est pas une étiquette portable attachée à chaque paquet ; il est le moyen de relier un SYN nouveau à un état ancien.

L'Address ID résout une autre difficulté. L'émetteur l'associe à son adresse source afin de pouvoir l'identifier même si un NAT a modifié l'en-tête IP visible par le pair. Cela aide à corréler les tentatives et à retirer une adresse sans exiger une vision identique du fil. L'identifiant n'est ni une adresse routable, ni une preuve que l'émetteur possède l'adresse, ni une autorisation d'usage hors de ce contexte.

Un Token de 32 bits n'accomplit pas non plus l'authentification entière. La spécification lui donne un rôle de recherche, avec une protection bornée contre certaines tentatives aveugles d'épuisement d'état. Elle ne le présente pas comme un secret humain, un cookie applicatif ou un justificatif de mandat.

La seconde preuve rattache les pairs au premier échange

Le complément arrive avec les HMAC. Le récepteur répond au MP_JOIN par son nonce et un HMAC tronqué ; l'initiateur renvoie son propre HMAC. Les clés échangées dans MP_CAPABLE et les deux nonces forment les entrées de ces calculs. Les nonces empêchent qu'un ancien enregistrement suffise à rejouer cette admission particulière.

Lorsque les HMAC sont corrects, RFC 8684 formule une conclusion précise : les deux hôtes ont vérifié qu'ils sont les mêmes pairs MPTCP qu'au début de la connexion et qu'ils s'accordent sur la connexion rejointe par le sous-flux. C'est une continuité de pair au niveau du transport. Elle ne devient pas, par magie, une identification civile, une preuve de contrôle d'entreprise, une authentification de l'utilisateur ou une autorisation d'exécuter une opération applicative.

Les refus le montrent nettement. Un Token inconnu produit une réinitialisation TCP. Un Token connu peut produire la même réinitialisation lorsque la politique locale interdit un sous-flux de plus. Un HMAC erroné ou absent entraîne aussi la fermeture. La recherche vient donc avant l'admission, et la cryptographie vient avant l'usage durable, sans que l'une ou l'autre retire à l'hôte destinataire sa décision locale.

Un cinq-uplet nouveau reste parrainé localement

Un schéma montrant A2 vers B1 peut faire croire qu'une seconde adresse ouvre naturellement une seconde route. Le protocole est moins romantique. Il propose un sous-flux TCP ; le récepteur retrouve son propre état, vérifie la preuve requise et applique ses limites. Ce n'est qu'après cela que le cinq-uplet devient l'un des flux TCP gérés par la connexion MPTCP.

La séparation protège aussi les récits d'exploitation. Une trace peut établir MP_CAPABLE, un MP_JOIN porteur du Token, des HMAC valides et un sous-flux vivant. Elle ne démontre pas qu'une application a accepté la requête, qu'une base l'a validée, qu'un utilisateur était autorisé, ou qu'un effet durable a été obtenu. Le transport conserve la continuité des octets ; le sens et la décision restent ailleurs.

Sources et limites de preuve

Les RFC permettent d'établir l'architecture, les statuts documentaires et le comportement spécifié de v1. Elles ne prouvent pas un usage actuel, la séparation effective de routes réelles, la conformité d'un produit, un avantage de performance, l'identité d'un utilisateur ou le succès d'une application.