GuiGui's Show

• QUIC = nouveau protocole de transport. Remplacer TCP (mêmes fonctionnalités) + apporter la confidentialité et l'intégrité à la couche transport (QUIC est forcément chiffré) + vrai parallélisme (ruisseaux indépendants au sein d'une même session pour ne pas bloquer la récupération de toutes les ressources en cas de perte de paquet, ce qui est le cas en HTTP/2, tout en assurant l'équité sur le réseau ‒ la répartition du débit se fait habituellement par connexion niveau 4 ‒) + indépendance de l'adresse IP (jeu de plusieurs Connection ID pour démultiplexer) + 0-RTT (comme TLS 1.3, avec les mêmes limites cryptos, j'imagine) ;
  
  
• QUIC repose sur UDP à cause de l'ossification de l'Internet. (Donc la promesse de sessions indépendantes de l'adresse IP est illusoire, au moins dans un premier temps.) Mais QUIC honore bien le cahier des charges de TCP. Les algos de contrôle de flux, utilisés pour encadrer les ruisseaux (streams) au sein d'une session QUIC, sont ceux de TCP (adaptés aux particularités de QUIC), car le sujet est très complexe. (Pour rappel, chaque pair d'une communication peut choisir un algo différent) ;
  
  
• QUIC utilise TLS pour la négociation, puis ses méthodes internes pour le chiffrement symétrique (comme OpenVPN). Les bibliothèques de fonctions cryptographiques (OpenSSL, par ex.) ont dû être adaptées (elles ne proposaient pas de leur déléguer uniquement la négociation) ;
  
  

• QUIC est implémenté dans l'espace utilisateur. TCP l'est dans le noyau. C'est volontaire afin de ne pas dépendre d'un éditeur de systèmes pour corriger un problème de performance dû à la pile TCP du noyau (Google soupçonne Microsoft, par ex.). Cela me conforte : le NAPT s'appuie sur les ports UDP, pas sur les Connection IDs. Cela signifie aussi qu'il n'y a pas d'API standard (l'équivalent de socket()) ;

• Usages :

  • HTTP/3 : même sémantique que les anciennes versions de HTTP + encodage binaire de HTTP/2, sur QUIC. Un ruisseau par requête + réponse ;
    
    
  • DNS over QUIC (DOQ) : sémantique + encodage DNS directement sur QUIC (là encore : un ruisseau par requête + réponse). À différencier de DOH over QUIC (QUIC + HTTP/3 + DNS) ;
    
    
  • VPN sur QUIC (projet MASQUE) ;
    
    
  • Y'a des projets de RFC pour IRC over QUIC, SSH over QUIC, etc.
• QUIC n'est plus un acronyme ;
  
  
• Pourquoi sécuriser la couche de transport ? Un tiers peut clôturer une session TCP par l'envoi d'un drapeau RST (les FAI l'ont fait pour contrer BitTorrent). Des infos peuvent en dire long (le RTT, qui se déduit des numéros de séquence, donne un indice sur la géolocalisation du terminal / serveur. Chiffrer au maximum est l'une des méthodes pour contrer l'ossification d'Internet (cependant, je ne comprends pas comment QUIC contre actuellement les pare-feux et le NAPT comme l'indique l'orateur) ;
  
  
• Le premier paquet d'une réponse QUIC a la même taille que le premier paquet de requête car le client pratique le bourrage afin de rendre vaine une attaque par réflexion+amplification. J'en doutais, mais la section 14.1 du RFC définit une taille minimale de 1200 octets (le client peut aller au-dela), et prévoit qu'un serveur ignore un paquet plus petit voire clôture la connexion ;
  
  
• Le spin bit, qui révèle le RTT pour permettre les observations tierces légitimes, a fait couler beaucoup d'encre (à quoi ça sert de chiffrer l'entête pour ensuite restituer une partie des informations ?!). Il est optionnel ;
  
  
• 2012 : projet de Google ; 2016 : début de la normalisation à l'IETF ; 2021 : publication des RFC ;
  
  
• La généralisation du chiffrement (QUIC ou non) pousse à l'abandon des diagnostics côté réseau au profit de ceux côté terminaux. Ceux-ci nécessitent la coopération de l'application, donc du logiciel libre et des options de debug : SSLKEYLOGFILE, qlog (format d'un journal de session QUIC en cours de normalisation), etc.

Voir aussi : Le protocole QUIC désormais normalisé.