QUIC, la fin de TCP pour 2019, enfin… plutôt 2021 ! Partie 3/3 : Et après ?

Cet article est le troisième dans une série de 3 : QUIC, la fin de TCP pour ~~2019~~ 2021 !

Comme il vient de vous être exposé longuement, l’arrivée de QUIC à la place de TCP est inéluctable (Partie 1/3). Ça va venir très vite (Partie 2/3). Soit. Mais finalement, le logiciel gérant tout cela très bien et étant déjà quasi à jour, pourquoi s’en préoccuper ?

Et ensuite, quelles implications ?

Si vous avez lu jusqu’ici, c’est que le sujet a du vous interpeller. Et vous avez bien fait car le meilleur est pour maintenant !

Il y a quelques implications évidentes de QUIC sur les métiers et les infrastructures du réseau. En voici quelques-unes tout à fait sérieuses :

Sécurité (1/2): Que devient la sécurité périmétrique (Firewall) ?

HTTPS (TLS) était déjà pratiquement devenu le nouveau TCP… mais maintenant c’est UDP/QUIC qui va remplacer réellement TCP. Toutes les applications, média comprises (un des clients impatients de QUIC est WebRTC), vont basculer. Ainsi, une fois UDP/443 ouvert, c’est l’Internet entier qui va s’engouffrer. Exit le filtrage de niveau 4.
En QUIC/TLS 1.3, l’un des objectifs est d’atteindre le 0-RTT pour l’établissement de la communication utile à l’utilisateur. Les certificats et clés de sessions de chiffrement sont donc déjà entre les mains des clients et serveurs. Comment reconnaitre le service concerné ? Les adresses IP encore lisibles seront d’une utilité bien limitée.

Sécurité (2/2): Comment assurer une interception pour protection (anti-virus, anti-malware, anti-injection…) ?

Le HSTS verrouille déjà considérablement toute velléité de relai SSL (type Man-in-the-Middle). Le Certificat original d’un site est mémorisé dans le navigateur. Ainsi HSTS empêche toute introduction d’un « Certificat Proxy » forgé par une PKI de confiance mais pas « originelle ». Avec QUIC et TLS 1.3, c’est sa généralisation et même la capacité de mettre en cache des clés de sessions déjà négociées avec un serveur. C’est comme cela que QUIC atteint une connexion chiffrée en 0-RTT ! Doit-on jeter ses PaloAlto ? (On peut le penser quand on voit que la seule réponse de PaloAlto à QUIC est de tout simplement le bloquer ! Pour combien de temps ?)

Monitoring réseau: Comment assurer la visibilité des flux ?

Historiquement, la visibilité réseau se basait sur la définition IANA ou propriétaire des numéros de ports TCP/UDP. Nous avions déjà eu quelques difficultés avec HTTP/HTTPS qui emportait tout en TCP/80 et TCP/443. Il restait quelques protocoles reconnaissables, notamment en entreprise. Mais à terme, il s’agit désormais de UDP/443 pour tous les flux !
NetFlow connait un regain d’intérêt avec l’arrivée du SD-WAN. Or, il ne fonctionnera plus correctement avec QUIC. En effet, les entrées dans les tables de NAT pour UDP vont expirer ou migrer d’une interface à une autre et donc changer les ports sources au cours d’une même session QUIC. NetFlow remontera plusieurs Flow pour une même connexion.
Pour lire les applications Web dans HTTPS, on a recourt à du Deep Packet Inspection (DPI). Cette fonction inspecte le contenu au delà de l’entête TCP et permet ainsi d’identifier les applications aisément avec une solution à l’état de l’art. Le DPI exploite notamment les noms de hosts et SNI dans les Certificats SSL. Mais on se dirige vers des sessions sans échanges de Certificats !
Les solutions de monitoring réseau du marché ne sont pas encore au niveau… elles voient aujourd’hui UDP/443 et au mieux QUIC/GQUIC.
Apparemment, il reste quelques informations de SNI dans gQUIC, mais jusqu’où pourrons-nous identifier les services…

Exemple d’une capture Wireshark d’une ouverture de Chrome sur Mac OS X qui essaye d’emblée de communiquer en GQUIC avec le SNI id.google.com. On peut ensuite suivre cette connexion avec le CID. A noter qu’on est en IPv6 mais c’est tout à fait indépendant de QUIC.

Et la réponse ICMPv6 Type 1 Code 4 « Port Unreachable » qui reprend l’entête GQUIC rejeté.

Qualité de Service (QoS) et optimisation WAN: Comment proposer une performance active des flux ?

Sans reconnaissance des flux, comment les prioriser ? Nous utilisons aujourd’hui classiquement dans les réseaux d’entreprise, des équipements pour marquer et prioriser les flux. Ce sont des solutions et des configurations dites « de QoS ». Comment faire désormais ?
La QoS cherche classiquement à « coloriser » les flux à des fins de priorisation. Pour cela, on utilise le marquage DSCP. Par exemple, en priorité haute, AF31 pour le flux Citrix en TCP/2598, SAP en TCP/3264 et MS-SQL en TCP/1433. En priorité moindre, AF21 pour le Web en TCP/80 et 443, etc. Mais si on ne sait plus reconnaitre ses applications, comment les marquer ?
La QoS active peut aussi exploiter des solutions de queuing sophistiqué (Riverbed, IPanema, StreamCore…). Elles exploitaient parfois certains paramètres de TCP (TCP receive window). C’est à réinventer.
L’Optimisation WAN est une technologie née sur les limitations de TCP et des protocoles d’applications supérieurs. En additionnant les capacités de « ré-ingénierie » protocolaire et de caching de données, le bénéfice est indéniable. QUIC associe un changement radical de protocole et un chiffrage généralisé de bout en bout. Par conséquent, l’optimisation WAN est réduite à néant.

Conclusion intermédiaire :

La révolution QUIC a de quoi occuper notre industrie pour les 5 à 10 prochaines années !

Mais j’insiste sur un point important non négligeable : QUIC a pour objectif principal de remonter toute l’intelligence du transport (couche 4 de l’OSI) dans des couches supérieures, logicielles et chiffrées. Ceci pour que l’infrastructure réseau ne puisse plus fossiliser les protocoles. Le corollaire est donc : le réseau ne doit plus s’occuper des protocoles et de la gestion des applications.

Le réseau est donc destiné à rester un tuyau idiot et efficace. C’est le coup de grâce du logiciel dans la guerre de l’informatique contre les télécoms (c’est un Ingénieur Télécom qui vous le dit).

Enfin, j’ouvre 2 autres sujets particulièrement sérieux. L’un concerne notre métier au service des entreprises et grandes organisations. Mais le second touche à l’ensemble de la société numérique.

Quid de la cohabitation en entreprise entre QUIC et TCP ?

Les entreprises mettent plusieurs années à faire évoluer leurs systèmes d’information, parfois avec quelques vestiges qui survivent aux évolutions (qui a dit AS400 ?). Le Cloud est une des évolutions en cours et pas des moindres. Pour résumer cette transformation du point de vue réseau, elle consiste à minima à faire rentrer l’Internet dans le réseau d’entreprise. On peut même considérer qu’avec le Cloud, l’Internet est une partie du réseau d’entreprise.

Ainsi, qui dit que l’entreprise va vers le Cloud, dit que QUIC va venir dans l’entreprise !

Vous avez sans doute déjà du flux Office 365 chez vous. Vous avez forcément du flux Youtube chez vous… Si vous vous posez la question, laissez nous faire un petit audit chez vous et nous vous dirons combien ! Vous avez sans doute un projet d’évasion Internet locale aux sites.

Alors tôt ou tard, peut-être déjà aujourd’hui, vous aurez du QUIC chez vous.

QUIC ne passe pas les proxy HTTP pour l’instant. Mais combien de temps faudra-t-il avant que Microsoft, qui vous demande déjà de laisser passer TCP/443 et UDP/3478-3481 hors Proxy pour Skype for Business online pour des questions de « bonne pratique de performance », ne vous demande de faire la même chose avec UDP/443 pour tous ses services Online ?

Inévitablement, vous aurez un jour prochain des flux QUIC venant de vos services Cloud qui se mêleront à vos flux TCP internes et historiques. Par conséquent, il existera des goulots d’étranglement réseau comme aujourd’hui, où ces 2 protocoles de transports devront se partager la bande passante. Comment cela se passera-t-il ?

Aujourd’hui, TCP partage naturellement la bande passante par ses mécanismes internes cités plus haut et ceux-ci variant peu d’un OS à l’autre, tout se passe relativement bien. Et pour ce qui se passe moins bien (Citrix vs CIFS ? RDP vs HTTP ? SAP vs Youtube ?) alors on utilise des solutions de QoS au moins basées sur du DSCP selon les numéros de ports, avec des ACL dans les routeurs opérateurs par exemple.

Mais avec QUIC (qui portera autant du Youtube que du Sharepoint Online) contre TCP, nous allons assister à un partage de la ressource entre les 2 protocoles. TCP, égalitaire et équilibré, fait face à un nouvel arrivant dont les mécanismes pourront varier selon les versions ! Chaque échange client-serveur fonctionnera selon la volonté de l’éditeur. En outre, cela sera géré de manière secrète car tout se situe dans la couche chiffrée.

Cela pose 2 questions :

Si QUIC est tourné vers la rapidité, n’est-il pas déjà capable de préempter la ressource au détriment de TCP « par design » ?
Est-il raisonnable de penser que cette aubaine pour les éditeurs ne soit pas mise à profit pour tirer la couverture à eux ?

Pour le premier point, la réponse est déjà pratiquement trouvée. Un chercheur s’est penché sur le sujet (pour sa thèse) avec les versions très préliminaires de QUIC et dans un cadre très limitant de maquette. Malheureusement, comme on pouvait s’y attendre QUIC partage déjà la ressource plutôt à son avantage. Dans le cas simple illustré ci-dessous, c’est 2/3 pour QUIC, 1/3 pour TCP ! Par design…

Exemple de mesure de débit de QUIC en concurrence avec une à 4 sessions TCP : QUIC consomme systématiquement plus que sa part équitable de bande passante, même lorsqu’il y a plusieurs sessions TCP.
Source : http://www.ccs.neu.edu/home/arash/home/files/thesis.pdf

Ce comportement apparait malgré l’utilisation du même mécanisme de gestion de la congestion dans TCP et QUIC (nommé Cubic). Simplement, QUIC est plus rapide et incisif que TCP. Et il n’y a pas encore eu de « trifouillage » dans le mécanisme de la part de celui qui détient le code client et serveur du transport QUIC…

Le second point est donc encore plus prévisible !

Qu’adviendra-t-il de TCP lorsque Microsoft voudra s’assurer que OneDrive ou Sharepoint Online sont bien meilleurs pour l’utilisateur que leurs versions historiques : CIFS et Sharepoint on-prem ? Il suffira à l’éditeur d’ajuster QUIC dans IE, Edge, Outlook, Teams et ses serveurs. A cela s’ajoute l’escalade prévisible entre éditeurs : Google Drive, Box, OODrive, Dropbox, etc ne voudront pas se laisser distancer. Pour ne parler que de partage de fichiers.

Si QUIC est déjà né plus fort que TCP… nul doute que les éditeurs lui feront donner le coup de grâce à son vieil aïeul.

Ainsi, dans ce champ de bataille que seront les réseaux d’entreprise… il faudra faire face. L’ERP et toutes les applications On-Prem, maison ou historique, devront tenir le coup. Reste à savoir comment !

Parlant de champ de bataille, il en est un plus grand et plus sauvage encore : l’Internet.

Je vous propose ainsi de conclure sur une dimension plus sociétale de l’arrivée de QUIC dés ~~2019~~ 2021.

QUIC, la véritable fin de la neutralité du Net ?

Il existe un principe très simple sur l’Internet mondial, “qui veut que tous les contenus circulant sur Internet le fassent de manière égalitaire, sans aucune discrimination. Par exemple, il interdit à un fournisseur d’accès de permettre un accès plus rapide à certains services qu’à d’autres, ou encore de filtrer certains contenus ou services.”

C’est un principe essentiel. Malgré des débats et des attaques de la part des opérateurs télécom, il restait un consensus pour l’essentiel des bords politiques notamment aux états-unis. Depuis l’élection de Trump, cette neutralité est sérieusement en balance (rétablie pour combien de temps ?).

Néanmoins, cette guerre juridique est celle d’opérateurs télécom souhaitant valoriser leurs investissements et différencier la performance en fonction des contenus (et pour celui qui en paiera le prix). Les fournisseurs de contenus (GAFAM) ont toujours voulu avoir la relation directe avec les consommateurs. Les opérateurs, forts de leurs abonnements d’accès Internet, tiennent en fait réellement le client via la rente de l’abonnement et voudraient le monnayer aux premiers. Les bras de fer commerciaux entre FAI et GAFA émaillent toute l’histoire du Web depuis les années 2000. Free contre Google avec un débit Youtube catastrophique pendant des années est un des épisodes les plus connus. Une vieille guerre encore active aujourd’hui.

Or, comme vous l’avez maintenant compris, le débat vient de « changer de couche » : du réseau au logiciel. Les opérateurs peuvent toujours gérer la ressource au niveau du réseau de manière « globale et basique » (les « tuyaux »). Cependant, les fournisseurs de contenus, via QUIC et leur maitrise des logiciels clients/serveurs, ont désormais mis la main sur le protocole et la neutralité de comportement et de traitement du contenu. Le comportement de leurs applications vis-à-vis des autres flux sur l’Internet est désormais en bonne partie entre leurs mains.

La guerre entre Youtube et Netflix peut maintenant avoir lieu indépendamment de celui qui les transporte, a fortiori si celui-ci voudrait rester neutre ! Malheureusement, un FAI qui souhaiterait encore être équitable ouvre la porte à cette guerre commerciale entre applications.

QUIC apporte l’efficacité du réseau au niveau de l’intelligence et de l’agilité du logiciel. Il permet de pallier la lourdeur et la rigidité de l’infrastructure intermédiaire. Mais cette infrastructure mondiale forme un média commun, encore assez neutre et au service de tous. Or, d’un point de vue gouvernance, on peut se demander si QUIC ne livre pas cette révolution d’efficacité et d’agilité essentiellement à des intérêts beaucoup plus particuliers que collectifs.

L’avenir nous le dira, par la voix des experts d’ISIS-Performance assurément !