Multipath TCP (MPTCP) a récemment attiré l’attention après la divulgation d’une vulnérabilité dans son implémentation Linux, identifiée sous le numéro CVE-2026-98432. Plutôt que d’examiner la vulnérabilité elle-même, cette analyse s’intéresse au fonctionnement de MPTCP et à la manière dont son utilisation peut être détectée dans le trafic réseau.

Le protocole TCP traditionnel associe une connexion à une paire spécifique d’adresses IP d’hôtes. Ce modèle peut être problématique pour les appareils mobiles, qui peuvent passer du Wi-Fi à la connectivité cellulaire et doivent sinon rétablir leurs connexions. MPTCP remédie à cette limitation en permettant à une connexion d’être répartie entre différentes adresses IP ou transférée de l’une à l’autre. Il peut également aider les serveurs à exploiter plus efficacement les liaisons à haut débit qu’une seule connexion TCP.

L’implémentation la plus largement observée se trouve sur iOS et iPadOS. Les connexions IPv4 vers l’espace d’adresses 17.0.0.0/8 d’Apple utilisent souvent MPTCP. Cette technologie a d’abord été utilisée pour Siri, puis étendue à des services comme Apple Music.

Deux versions de MPTCP sont actuellement définies et utilisées : la version 0 et la version 1. MPTCP est identifié par l’option TCP 30. Cette option comprend un sous-type et un champ de version, plusieurs sous-types prenant en charge la négociation et la gestion des connexions.

MP_CAPABLE, le sous-type 0, indique que les deux points d’extrémité prennent en charge MPTCP et doit apparaître pendant la négociation TCP pour que la fonctionnalité soit activée. Chaque option MP_CAPABLE contient également une clé de huit octets utilisée ultérieurement pour identifier et authentifier des sous-flux supplémentaires.

MP_JOIN, le sous-type 1, permet à une autre connexion TCP de rejoindre la connexion MPTCP existante. Ce sous-flux est généralement initié par le client et peut utiliser une adresse IP différente, bien que la spécification permette également au serveur de l’initier. Les ports sont normalement identiques, mais ce n’est pas obligatoire. DSS, ou Data Sequence Signal, fait correspondre les numéros de séquence de chaque connexion TCP individuelle aux numéros de séquence de la connexion MPTCP combinée.

Les sous-types ADD_ADDR et REMOVE_ADDR annoncent ou retirent des adresses ou des ports supplémentaires pouvant être utilisés pour les sous-flux MPTCP sans établir directement une nouvelle connexion.

La manière la plus directe de détecter MPTCP consiste à rechercher l’option TCP 30. Wireshark prend cette fonction en charge grâce à son filtre d’affichage « mptcp ». Tcpdump ne dispose d’aucun mécanisme dédié pour faire correspondre les options TCP, mais les paquets MPTCP, en particulier les paquets SYN, possèdent souvent de longs en-têtes TCP ; vérifier la longueur de l’en-tête TCP peut donc fournir un indice, par exemple avec le filtre « tcp[12]>0xd0 ».

Suricata peut inspecter les options TCP avec le mot-clé « tcp.hdr ». Les longueurs des options varient, mais un message MP_CAPABLE contenant les clés de l’émetteur et du récepteur devrait mesurer 20 octets. Ses trois premiers octets sont « 1e 14 00 » pour la version 0 ou « 1e 14 01 » pour la version 1.

Snort ne fournit pas de mot-clé permettant d’inspecter les options TCP et, selon l’analyse, n’offre pas de méthode spécifique pour filtrer MPTCP. Dans Zeek, les options TCP ne sont pas journalisées par défaut, mais les événements tcp_option et tcp_options peuvent être utilisés pour enregistrer l’option 30 et identifier les communications qui utilisent MPTCP.

Sources: SANS Internet Storm Center.