Comment QUIC vous aide à vous connecter en toute transparence à différents réseaux

Imaginez que vous utilisiez votre téléphone au travail pour vous connecter à une réunion virtuelle via le réseau WiFi de votre bureau.

La vidéoconférence joue les prolongations, mais vous devez vous rendre à une réunion avec un client à l'autre bout de la ville. L'animateur indique qu'il ne reste plus que 15 minutes, vous décidez donc de regarder le reste en marchant jusqu'à votre voiture pour gagner du temps.

Lorsque votre téléphone sort de la portée du réseau WiFi, il se connecte automatiquement à un réseau cellulaire (4G ou 5G) et commence à l'utiliser à la place. Au cours de ce processus, toutes les connexions que vous avez avec le serveur vidéo se ferment et se rechargent, ce qui entraîne des interruptions dans la vidéo ou le gel de la vidéo si les connexions ne peuvent pas être rétablies.

C'est ce qu'on appelle le "problème du parking" et c'est l'une des inefficacités du protocole de contrôle des transports (TCP) que son successeur, QUIC, surmonte grâce à la nouvelle fonction de "migration des connexions".

Comme je l'ai expliqué dans le premier article de cette série, le protocole QUIC a été mis au point pour pallier les insuffisances du TCP en ce qui concerne sa conception à l'épreuve du temps, notamment en matière de protection de la vie privée et de sécurité. Dans ce billet, j'entrerai dans les détails, en me concentrant sur le problème quotidien que j'ai illustré ci-dessus, et je discuterai de l'avenir de la migration transparente entre les réseaux.

Comme je l'ai mentionné dans mon article précédent, TCP n'est pas le meilleur protocole pour transférer vos données de manière fiable sur l'Internet d'aujourd'hui.

Cela s'explique par la simplicité des connexions TCP : elles circulent entre deux adresses IP et . Si l'une de ces adresses IP change, par exemple lors d'un changement de réseau, elles ne peuvent plus être utilisées, comme le montre la figure 1. (Remarque : dans la pratique, TCP utilise également ce que l'on appelle des "ports", et tous les changements de réseau n'entraînent pas de changement d'adresse IP, mais les concepts sont les mêmes).

Bien que ce processus ne soit pas la fin du monde (la nouvelle connexion fonctionnera parfaitement), il est quelque peu inefficace. Après tout, ce n'est que l'adresse IP qui change, tout le reste de la connexion TCP et son état (par exemple, les paramètres de cryptage du protocole Transport Layer Security (TLS)) pourraient théoriquement rester inchangés. Nous payons beaucoup de frais généraux supplémentaires inutiles, par exemple en attendant que les nouveaux échanges TCP et TLS aient lieu.

Pour résoudre ce problème, QUIC ne s'appuie plus (uniquement) sur les adresses IP pour définir les connexions. Au lieu de cela, il attribue un numéro à chaque connexion (un "Connection ID" ou CID). Ainsi, même si vous changez de réseau et d'adresse IP, tant que vous continuez à utiliser le même CID, l'"ancienne" connexion reste utilisable. Le serveur ne se soucie pas de savoir si l'adresse IP a changé : il peut se fier à l'IDC pour savoir qu'il s'agit bien de vous dans ce nouveau réseau. Cela signifie que le client et le serveur peuvent conserver l'état de la connexion existante et qu'il n'y a pas de frais généraux liés à l'établissement de la connexion, comme le montre la figure 2.

En tant que tel, QUIC Connection Migration résout une inefficacité de performance prévalant dans TCP. Cependant, s'il fonctionnait comme le montre la figure 2, il serait fondamentalement peu sûr et terrible pour la vie privée de l'utilisateur final !

Le CID ne décrit pas seulement des connexions individuelles, mais il est (implicitement) lié à des appareils individuels et, par conséquent, à des utilisateurs ! Si une partie malveillante avait une vue sur plusieurs réseaux (par exemple, à la fois le réseau câblé auquel le WiFi se connecte et le réseau cellulaire 4G), elle pourrait utiliser les CID pour suivre les utilisateurs individuels sur différents réseaux! Bien que cela ne soit probablement pas du ressort des pirates individuels, des organisations plus importantes, telles que les grandes entreprises et surtout les États-nations, pourraient utiliser cette capacité.

Heureusement, les concepteurs de QUIC étaient parfaitement conscients de ce problème, appelé "linkability". QUIC résout ce problème en modifiant le CID chaque fois que les utilisateurs changent de réseau. Cela signifie que les attaquants ne peuvent pas attribuer directement la connexion à un appareil individuel parce que l'adresse IP et le CID changent. Le problème est résolu !

Cependant, n'avions-nous pas besoin d'un CID qui ne change pas au départ pour gérer le fait que l'adresse IP change ! Comment cela peut-il fonctionner si le CID change également ?

L'astuce consiste à attribuer non pas un mais plusieurs CID à la même connexion sous-jacente. Dans la figure 3, la connexion bleue n'est pas seulement décrite par la boîte verte, mais aussi par le cercle violet et le triangle rouge. Il est important de noter que seuls le client et le serveur sont au courant de l'existence de ces CID supplémentaires ; tout attaquant qui se contenterait d'observer le trafic réseau ne le saurait pas, car les nouveaux CID sont échangés en toute sécurité une fois qu'une connexion QUIC cryptée a été établie. Ainsi, les clients peuvent utiliser en toute sécurité le CID suivant dans la liste : seul le serveur saura qu'il vise en fait la même connexion sous-jacente. 

(Remarque : dans la pratique, ce mécanisme est encore plus compliqué en raison de la nécessité de prendre en charge les équilibreurs de charge et d'autres cas d'utilisation. Veuillez vous référer à cet article de blog pour plus d'informations). 

Bien que ce mécanisme fonctionne assez bien, il présente quelques inconvénients. Le CID est l'une des rares parties qui doivent rester non chiffrées dans les métadonnées de l'en-tête du paquet QUIC. Cela s'explique en partie par le fait que le serveur doit être en mesure de rechercher la bonne connexion sur la base du CID avant de pouvoir utiliser les clés de décryptage TLS de cette connexion pour déverrouiller le paquet. Comme nous l'avons vu dans l'article précédent de cette série, toutes les métadonnées non chiffrées peuvent être (et seront probablement) lues (et probablement mal utilisées/utilisées) par des boîtes intermédiaires (et des attaquants), ce qui compromet à nouveau quelque peu la conception à l'épreuve du temps de QUIC. 

L'utilisation d'un schéma de cryptage distinct uniquement pour les CID (afin qu'ils puissent être cryptés séparément du paquet) peut résoudre ce problème. Toutefois, cela augmente la difficulté de mise en œuvre d'autres services, tels que les pare-feu et les équilibreurs de charge. Ce problème est assez difficile à résoudre dans la pratique, et des travaux sont toujours en cours à l'IETF pour définir ce à quoi cela devrait ressembler.

C'est une excellente question et une fonction appelée Mulipath est actuellement en cours d'élaboration pour résoudre ce problème. Ce concept a été développé pour le TCP pendant plus d'une décennie, mais il a été difficile de le déployer à l'échelle mondiale. 

Avec QUIC, qui s'appuie sur les fonctions de migration de connexion décrites ci-dessus, cette approche devient beaucoup plus réalisable. Des entreprises telles qu'Apple, Google et Alibaba l'expérimentent activement pour améliorer la robustesse globale du réseau et augmenter les performances en combinant la bande passante des deux réseaux pour une seule connexion conceptuelle.

Dans mon prochain article, je parlerai des performances des protocoles dans la nature et j'expliquerai pourquoi il est difficile de comparer QUIC et HTTP/3 à TCP et HTTP/2.

Robin Marx est expert en protocoles et performances web chez Akamai. Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l'Internet Society.