Aller au contenu principal

RFC 9308 - Applicabilité du protocole de transport QUIC (Applicability of the QUIC Transport Protocol)

  • Statut : Informational
  • Date de publication : September 2022
  • Stream : IETF
  • Errata : Aucune errata

Résumé (Abstract)​

Le présent document discute de l'applicabilité du protocole de transport QUIC, en se concentrant sur les mises en garde qui impactent le développement et le déploiement de protocoles d'application sur QUIC. Le public visé comprend les concepteurs de mappages de protocoles d'application vers QUIC et les implémenteurs de ces protocoles d'application.

Statut de ce mémorandum (Status of This Memo)​

Le présent document n'est pas une spécification de l'Internet Standards Track ; il est publié à des fins d'information.

Le présent document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). Tous les documents approuvés par l'IESG ne sont pas candidats à un quelconque niveau d'Internet Standard ; voir la Section 2 de RFC 7841.

Des informations sur l'état actuel du présent document, toute errata et la manière de fournir des commentaires peuvent être obtenues à https://www.rfc-editor.org/info/rfc9308.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

Le présent document est soumis à BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication du présent document. Veuillez examiner attentivement ces documents, car ils décrivent vos droits et restrictions concernant le présent document. Les composants de code extraits du présent document doivent inclure le texte de la Revised BSD License tel que décrit dans la Section 4.e des Trust Legal Provisions et sont fournis sans garantie telle que décrite dans la Revised BSD License.

Table des matières (Table of Contents)​

  1. Introduction
  2. La nécessité d'un repli (fallback)
  3. 0-RTT
  4. Utilisation des flux
  5. Packetisation et latence
  6. Gestion des erreurs
  7. Efficacité des accusés de réception
  8. Sélection de port et découverte d'extrémité d'application
  9. Migration de connexion
  10. Terminaison de connexion
  11. Exposition d'informations et identifiant de connexion
  12. QoS et DSCP
  13. Utilisation des versions et de la négociation cryptographique
  14. Permettre le déploiement de nouvelles versions
  15. Service de datagrammes non fiables sur QUIC
  16. Considérations IANA
  17. Considérations de sécurité
  18. Références

1. Introduction​

QUIC [QUIC] est un nouveau protocole de transport offrant un certain nombre de fonctionnalités avancées. Bien qu'initialement conçu pour le cas d'utilisation HTTP, il fournit des capacités qui peuvent être utilisées avec une bien plus grande variété d'applications. QUIC est encapsulé dans UDP. QUIC version 1 intègre TLS 1.3 [TLS13] pour chiffrer toutes les données de charge utile et la plupart des informations de contrôle. La version de HTTP qui utilise QUIC est connue sous le nom d'HTTP/3 [QUIC-HTTP].

Le présent document fournit des conseils aux développeurs d'applications qui souhaitent utiliser le protocole QUIC sans l'implémenter eux-mêmes. Cela inclut des conseils généraux pour les applications fonctionnant sur HTTP/3 ou directement sur QUIC.

Dans les sections suivantes, nous discutons des mises en garde spécifiques à l'applicabilité de QUIC et des problèmes que les développeurs d'applications doivent prendre en compte lorsqu'ils utilisent QUIC comme transport pour leurs applications.

2. La nécessité d'un repli (The Necessity of Fallback)​

QUIC utilise UDP comme substrat. Cela permet une implémentation en espace utilisateur et permet de traverser les boîtes intermédiaires du réseau (y compris le NAT) sans nécessiter de mises à jour de l'infrastructure réseau existante.

Des études de mesure ont montré qu'entre 3 % [Trammell16] et 5 % [Swett16] des réseaux bloquent tout le trafic UDP, bien qu'il y ait peu de preuves d'autres formes de désavantage systématique pour le trafic UDP par rapport à TCP [Edeline16]. Ce blocage implique que toutes les applications fonctionnant sur QUIC doivent soit être préparées à accepter un échec de connectivité sur de tels réseaux, soit être conçues pour se replier sur un autre protocole de transport. Dans le cas de HTTP, ce repli est TLS over TCP.

Les spécifications IETF Transport Services (TAPS) [TAPS-ARCH] décrivent un système avec une API commune pour plusieurs protocoles. Cela est particulièrement pertinent pour QUIC car cela traite des implications du repli entre plusieurs protocoles.

Plus précisément, le repli vers des protocoles non sécurisés ou vers des versions plus faibles de protocoles sécurisés doit être évité. En général, une application qui implémente un repli doit prendre en compte les conséquences en matière de sécurité. Un repli vers TCP et TLS expose les informations de contrôle à la modification et à la manipulation dans le réseau. De plus, les rétrogradations vers des versions de TLS antérieures à 1.3, utilisée dans QUIC version 1, peuvent entraîner une protection cryptographique significativement plus faible. Par exemple, les résultats de la négociation de protocole [RFC7301] n'ont une protection de confidentialité que si TLS 1.3 est utilisé.

Ces applications doivent fonctionner, éventuellement avec une fonctionnalité réduite, en l'absence de fonctionnalités fournies par QUIC qui ne sont pas présentes dans le protocole de repli. Pour un repli vers TLS over TCP, la différence la plus évidente est que TCP ne fournit pas le multiplexage de flux, et donc le multiplexage de flux devrait être implémenté dans la couche application si nécessaire. En outre, les implémentations TCP et les chemins réseau ne supportent souvent pas l'option TCP Fast Open (TFO) [RFC7413], qui permet l'envoi de données de charge utile avec le premier paquet de contrôle d'une nouvelle connexion, comme le fournit également la reprise de session 0-RTT dans QUIC. Notez qu'il existe des preuves de boîtes intermédiaires bloquant les données SYN même si TFO a été négocié avec succès (voir [PaaschNanog]). Et même si Fast Open fonctionne de bout en bout avec succès, il est limité à un seul paquet de négociation TLS et de données d'application, contrairement au 0-RTT de QUIC.

De plus, alors que le chiffrement (dans ce cas TLS) est inséparablement intégré à QUIC, la négociation TLS sur TCP peut être bloquée. Si TLS over TCP ne peut pas être supporté, la connexion devrait être abandonnée, et l'application devrait alors présenter une invite appropriée à l'utilisateur indiquant que la communication sécurisée est indisponible.

En résumé, tout mécanisme de repli est susceptible d'imposer une dégradation des performances et peut dégrader la sécurité ; cependant, le repli ne doit pas violer silencieusement l'attente de l'application en matière de confidentialité ou d'intégrité de ses données de charge utile.

3. 0-RTT​

QUIC fournit l'établissement de connexion 0-RTT. Bien que la même facilité existe dans TLS 1.3 avec TCP, le 0-RTT présente des opportunités et des défis pour les applications utilisant QUIC.

Un protocole de transport qui fournit l'établissement de connexion 0-RTT est qualitativement différent d'un protocole qui ne fournit pas le 0-RTT du point de vue de l'application qui l'utilise. Les compromis relatifs entre le coût de fermer et rouvrir une connexion et essayer de la maintenir ouverte sont différents ; voir la Section 3.2.

Une application doit choisir délibérément d'utiliser le 0-RTT, car le 0-RTT comporte un risque d'attaque par rejeu. Les protocoles d'application qui utilisent le 0-RTT nécessitent un profil qui décrit les types d'informations qui peuvent être envoyées en toute sécurité. Pour HTTP, ce profil est décrit dans [HTTP-REPLAY].

3.1. Attaques par rejeu (Replay Attacks)​

La retransmission ou le rejeu malveillant de données contenues dans des paquets 0-RTT pourrait amener le côté serveur à recevoir plusieurs copies des mêmes données.

Les données d'application envoyées par le client dans des paquets 0-RTT pourraient être traitées plus d'une fois si elles sont rejouées. Les applications doivent être conscientes de ce qu'il est sûr d'envoyer en 0-RTT. Les protocoles d'application qui cherchent à permettre l'utilisation du 0-RTT nécessitent une analyse soigneuse et une description de ce qui peut être envoyé en 0-RTT ; voir la Section 5.6 de [QUIC-TLS].

Dans certains cas, il peut suffire de limiter les données d'application envoyées en 0-RTT aux données qui ne provoquent pas d'actions ayant des effets durables sur un serveur. Initier une récupération de données ou établir une configuration sont des exemples d'actions qui pourraient être sûres. Les opérations idempotentes — celles pour lesquelles la répétition a le même effet net qu'une seule opération — pourraient être sûres. Cependant, il est aussi possible de combiner des opérations individuellement idempotentes en une séquence d'opérations non idempotente.

Une fois qu'un serveur accepte des données 0-RTT, il n'existe aucun moyen d'éliminer sélectivement les données reçues. Cependant, les protocoles peuvent définir des façons de rejeter des actions individuelles qui pourraient être dangereuses si elles sont rejouées.

Certaines implémentations et déploiements TLS pourraient être en mesure de fournir une protection partielle ou même complète contre le rejeu, qui pourrait être utilisée pour gérer le risque de rejeu.

3.2. Reprise de session versus maintien en vie (Session Resumption versus Keep-Alive)​

Parce que QUIC est encapsulé dans UDP, les applications utilisant QUIC doivent gérer des délais d'inactivité réseau courts. Les boîtes intermédiaires à état déployées établissent généralement un état pour les flux UDP au premier paquet envoyé et maintiennent l'état pendant des périodes d'inactivité beaucoup plus courtes que pour TCP. [RFC5382] suggère une période d'inactivité TCP d'au moins 124 minutes, bien qu'il n'y ait aucune preuve d'une mise en œuvre généralisée de cette directive dans la littérature. Cependant, le délai d'attente réseau court pour UDP est bien documenté. Selon une étude de 2010 ([Hatonen10]), les applications UDP peuvent supposer que toute liaison NAT ou autre entrée d'état peut expirer après seulement trente secondes d'inactivité. La Section 3.5 de [RFC8085] discute en outre les intervalles de maintien en vie pour UDP : elle exige une valeur minimale de 15 secondes, mais recommande des valeurs plus grandes, ou que le maintien en vie soit entièrement omis.

En utilisant un identifiant de connexion, QUIC est conçu pour être robuste au rebinding NAT après un délai d'attente. Cependant, cela n'aide que si une extrémité maintient sa disponibilité à l'adresse que son pair utilise et que le pair est celui qui envoie après l'occurrence du délai d'attente.

Certaines connexions QUIC pourraient ne pas être robustes au rebinding NAT parce que l'infrastructure de routage (en particulier les équilibreurs de charge) utilise le 4-tuple adresse/port pour diriger le trafic. De plus, des boîtes intermédiaires avec des fonctions autres que la traduction d'adresses pourraient encore affecter le chemin. En particulier, certains pare-feu n'admettent pas le trafic serveur pour lequel le pare-feu n'a pas d'état récent pour un paquet correspondant envoyé depuis le client.

Les applications QUIC peuvent ajuster les périodes d'inactivité pour gérer le risque de délai d'attente. Les périodes d'inactivité et le délai d'inactivité réseau sont distincts du délai d'inactivité de connexion, qui est défini comme le minimum du paramètre idle timeout de l'une ou l'autre extrémité ; voir la Section 10.1 de [QUIC]. Il y a trois options :

  • Ignorer le problème si le protocole de couche application ne consiste qu'en interactions sans ou avec de très courtes périodes d'inactivité, ou si la résistance du protocole au rebinding NAT est suffisante.
  • S'assurer qu'il n'y a pas de longues périodes d'inactivité.
  • Reprendre la session après une longue période d'inactivité, en utilisant la reprise 0-RTT lorsque c'est approprié.

La première stratégie est la plus facile, mais elle ne s'applique qu'à certaines applications.

Le serveur ou le client dans une application QUIC peut envoyer des trames PING comme maintiens en vie pour empêcher la connexion et tout état sur le chemin d'expirer. Les recommandations pour l'utilisation des maintiens en vie sont spécifiques à l'application, dépendant principalement des exigences de latence et de la fréquence des messages de l'application. Dans ce cas, le mappage d'application doit spécifier si le client ou le serveur est responsable de maintenir l'application en vie. Bien que [Hatonen10] suggère que 30 secondes pourraient être une valeur appropriée pour l'Internet public lorsqu'un NAT est sur le chemin, des valeurs plus grandes sont préférables si le déploiement peut survivre de manière cohérente au rebinding NAT ou s'il est connu pour être dans un environnement contrôlé (par exemple, des centres de données) afin de réduire la charge réseau et de calcul.

Envoyer des trames PING plus fréquemment que toutes les 30 secondes sur de longues périodes d'inactivité peut entraîner un trafic improductif excessif dans certaines situations et une utilisation d'énergie inacceptable pour les appareils à contrainte d'énergie (mobiles). De plus, des délais d'attente plus courts que 30 secondes peuvent rendre plus difficile la gestion des interruptions réseau transitoires, telles que la migration de machine virtuelle (VM) ou la perte de couverture pendant la mobilité. Voir [RFC8085], en particulier la Section 3.5.

Alternativement, le client (mais pas le serveur) peut utiliser la reprise de session au lieu d'envoyer du trafic de maintien en vie. Dans ce cas, un client qui veut envoyer des données à un serveur sur une connexion qui a été inactive plus longtemps que le délai d'inactivité du serveur (disponible depuis le paramètre de transport idle_timeout) peut simplement se reconnecter. Lorsque c'est possible, cette reconnexion peut utiliser la reprise de session 0-RTT, réduisant la latence impliquée dans le redémarrage de la connexion. Bien sûr, cette approche n'est valable que dans les cas où il est sûr d'utiliser le 0-RTT et lorsque le client est le pair qui redémarre.

Les compromis entre reprise et maintiens en vie doivent être évalués par application. En général, les applications devraient utiliser des maintiens en vie uniquement dans des circonstances où une communication continue est hautement probable ; [QUIC-HTTP], par exemple, recommande d'utiliser des maintiens en vie uniquement lorsqu'une requête est en cours.

4. Utilisation des flux (Use of Streams)​

La fonctionnalité de multiplexage de flux de QUIC permet aux applications d'exécuter plusieurs flux sur une seule connexion sans blocage de tête de ligne entre les flux. Les données de flux sont transportées dans des trames où un paquet QUIC sur le fil peut transporter une ou plusieurs trames de flux.

Les flux peuvent être unidirectionnels ou bidirectionnels, et un flux peut être initié soit par le client soit par le serveur. Seul l'initiateur d'un flux unidirectionnel peut envoyer des données dessus.

Les flux et les connexions peuvent chacun transporter un maximum de 2^62-1 octets dans chaque direction en raison des limitations d'encodage sur les décalages de flux et les limites de contrôle de flux de connexion. Dans l'événement actuellement improbable où cette limite est atteinte par une application, une nouvelle connexion devrait être établie.

Les flux peuvent être ouverts et fermés indépendamment, de manière gracieuse ou abrupte. Une application peut fermer gracieusement la direction de sortie d'un flux en demandant à QUIC d'envoyer un bit FIN dans une trame STREAM. Elle ne peut pas fermer gracieusement la direction d'entrée sans un FIN généré par le pair, un peu comme dans TCP. Cependant, une extrémité peut fermer abruptement la direction de sortie ou demander à son pair de fermer abruptement la direction d'entrée ; ces actions sont entièrement indépendantes l'une de l'autre.

QUIC ne fournit pas d'interface pour la gestion exceptionnelle d'un flux quelconque. Si un flux critique pour une application est fermé, l'application peut générer des messages d'erreur au niveau de la couche application pour informer l'autre extrémité et/ou la couche supérieure, qui peut éventuellement terminer la connexion QUIC.

Le mappage des données d'application aux flux est spécifique à l'application et décrit pour HTTP/3 dans [QUIC-HTTP]. Il y a quelques principes généraux à appliquer lors de la conception de l'utilisation des flux par une application :

  • Un seul flux fournit l'ordre. Si l'application exige que certaines données soient reçues dans l'ordre, ces données devraient être envoyées sur le même flux. Il n'y a aucune garantie d'ordre de transmission, de réception ou de livraison entre les flux.
  • Plusieurs flux fournissent la concurrence. Les données qui peuvent être traitées indépendamment, et qui souffriraient donc du blocage de tête de ligne si elles étaient forcées d'être reçues dans l'ordre, devraient être transmises sur des flux séparés.
  • Les flux peuvent fournir une orientation message et permettre l'annulation de messages. Si un message est mappé à un seul flux, la réinitialisation du flux pour expirer un message non acquitté peut être utilisée pour émuler une fiabilité partielle pour ce message.

Si un récepteur QUIC a ouvert le maximum de flux concurrents autorisés, et que l'expéditeur indique que plus de flux sont nécessaires, cela ne conduit pas automatiquement à une augmentation du nombre maximal de flux par le récepteur. Par conséquent, une application devrait considérer le nombre maximal de flux autorisés, actuellement ouverts et actuellement utilisés lors de la détermination de la façon de mapper les données aux flux.

QUIC assigne un identifiant numérique, appelé stream ID, à chaque flux. Bien que la relation entre ces identifiants et les types de flux soit clairement définie dans la version 1 de QUIC, les versions futures pourraient changer cette relation pour diverses raisons. Les implémentations QUIC devraient exposer les propriétés de chaque flux (quelle extrémité a initié le flux, si le flux est unidirectionnel ou bidirectionnel, le stream ID utilisé pour le flux) ; les applications devraient interroger ces propriétés plutôt que d'essayer de les inférer à partir du stream ID.

La méthode d'allocation des identifiants de flux aux flux ouverts par l'application peut varier entre les implémentations de transport. Par conséquent, une application ne devrait pas supposer qu'un stream ID particulier sera assigné à un flux qui n'a pas encore été alloué. Par exemple, HTTP/3 utilise des stream IDs pour se référer à des flux qui ont déjà été ouverts mais ne fait aucune supposition sur les futurs stream IDs ou la manière dont ils sont assignés (voir la Section 6 de [QUIC-HTTP]).

4.1. Multiplexage de flux versus multiplexage de flux réseau (Stream versus Flow Multiplexing)​

Les flux n'ont de sens que pour l'application ; puisque l'information de flux est transportée à l'intérieur de la frontière de chiffrement de QUIC, un paquet donné n'expose aucune information sur le(s) flux transporté(s) dans le paquet. Par conséquent, le multiplexage de flux n'est pas destiné à être utilisé pour différencier les flux en termes de traitement réseau. Le trafic d'application nécessitant un traitement réseau différent devrait donc être transporté sur différents 5-tuples (c'est-à-dire plusieurs connexions QUIC). Étant donné la capacité de QUIC à envoyer des données d'application dans le premier RTT d'une connexion (si une connexion précédente vers le même hôte a été établie avec succès pour fournir les informations d'identification nécessaires), le coût d'établir une autre connexion est extrêmement bas.

4.2. Priorisation (Prioritization)​

La priorisation de flux n'est exposée ni au réseau ni au récepteur. La priorisation est gérée par l'expéditeur, et le transport QUIC devrait fournir une interface pour que les applications priorisent les flux [QUIC]. Les applications peuvent implémenter leur propre schéma de priorisation au-dessus de QUIC : un protocole d'application qui s'exécute au-dessus de QUIC peut définir des messages explicites pour signaler la priorité, tels que ceux définis dans [RFC9218] pour HTTP. Un protocole d'application peut définir des règles qui permettent à une extrémité de déterminer la priorité en fonction du contexte, ou peut fournir une interface de niveau supérieur et laisser la détermination à l'application au-dessus.

La gestion de priorité des retransmissions peut être implémentée par l'expéditeur dans la couche transport. [QUIC] recommande de retransmettre les données perdues avant les nouvelles données, sauf indication contraire de l'application. Lorsqu'une extrémité QUIC utilise des flux entièrement fiables pour la transmission, la priorisation des retransmissions sera bénéfique dans la plupart des cas, comblant les lacunes et libérant la fenêtre de contrôle de flux. Pour des flux partiellement fiables ou non fiables, l'ordonnancement prioritaire des retransmissions par rapport aux données de flux de priorité plus élevée pourrait ne pas être souhaitable. Pour de tels flux, QUIC pourrait soit fournir une interface explicite pour contrôler la priorisation, soit dériver la décision de priorisation du niveau de fiabilité du flux.

4.3. Livraison ordonnée et fiable (Ordered and Reliable Delivery)​

Les flux QUIC permettent une livraison ordonnée et fiable. Bien qu'il soit possible pour une implémentation de fournir des options qui utilisent les flux pour une fiabilité partielle ou une livraison hors ordre, la plupart des implémentations supposeront que les données sont livrées de manière fiable et dans l'ordre.

Sous cette hypothèse, une extrémité qui reçoit des données de flux pourrait ne pas progresser tant que des données contiguës avec le début d'un flux ne sont pas disponibles. En particulier, un récepteur pourrait retenir le crédit de contrôle de flux jusqu'à ce que des données contiguës soient livrées à l'application ; voir la Section 2.2 de [QUIC]. Pour supporter cette logique de réception, une extrémité enverra des données de flux jusqu'à ce qu'elles soient acquittées, garantissant que les données au début du flux sont envoyées et acquittées en premier.

Une extrémité qui utilise un comportement d'envoi différent et ne négocie pas ce changement avec son pair pourrait rencontrer des problèmes de performance ou des interblocages.

4.4. Interblocages de contrôle de flux (Flow Control Deadlocks)​

Le contrôle de flux QUIC (Section 4 de [QUIC]) fournit un moyen de gérer l'accès aux tampons limités que les extrémités ont pour les données entrantes. Ce mécanisme limite la quantité de données qui peuvent être dans les tampons des extrémités ou en transit sur le réseau. Cependant, il y a plusieurs façons dont les limites peuvent produire des conditions qui peuvent amener une connexion à soit performer de manière sous-optimale, soit devenir interbloquée.

Les interblocages dans le contrôle de flux sont possibles pour tout protocole qui utilise QUIC, bien que le fait qu'ils deviennent un problème dépende de la façon dont les implémentations consomment les données et fournissent le crédit de contrôle de flux. Comprendre ce qui cause l'interblocage pourrait aider les implémentations à éviter les interblocages.

La taille et le rythme des mises à jour du crédit de contrôle de flux peuvent affecter les performances. Les applications qui utilisent QUIC ont souvent un consommateur de données qui lit les données depuis les tampons de transport. Certaines implémentations pourraient avoir des tampons de réception indépendants au niveau de la couche transport et de la couche application. Consommer des données n'implique pas toujours qu'elles sont immédiatement traitées. Cependant, une technique d'implémentation courante est d'étendre le crédit de contrôle de flux à l'expéditeur en émettant des trames MAX_DATA et/ou MAX_STREAM_DATA à mesure que les données sont consommées. La livraison de ces trames est affectée par la latence du canal de retour du récepteur vers l'expéditeur de données. Si le crédit n'est pas étendu en temps opportun, l'application émettrice peut être bloquée, étranglant effectivement l'expéditeur.

Les grands messages d'application peuvent produire un interblocage si le destinataire ne lit pas les données du transport de manière incrémentale. Si le message est plus grand que le crédit de contrôle de flux disponible et que le destinataire ne libère pas de crédit de contrôle de flux supplémentaire jusqu'à ce que le message entier soit reçu et livré, un interblocage peut se produire. Cela est possible même lorsque les limites de contrôle de flux de flux ne sont pas atteintes parce que les limites de contrôle de flux de connexion peuvent être consommées par d'autres flux.

Un format de message préfixé en longueur rend plus facile pour un consommateur de données de laisser des données non lues dans le tampon de transport et ainsi de retenir le crédit de contrôle de flux. Si les limites de contrôle de flux empêchent l'envoi du reste d'un message, un interblocage en résultera. Un préfixe de longueur pourrait aussi permettre la détection de ce type d'interblocage. Lorsque les protocoles d'application ont des messages qui pourraient être traités comme une seule unité, réserver atomiquement le crédit de contrôle de flux pour le message entier rend ce style d'interblocage moins probable.

Un consommateur de données peut lire avidement toutes les données dès qu'elles deviennent disponibles afin d'amener le récepteur à étendre le crédit de contrôle de flux et de réduire les chances d'un interblocage. Cependant, un tel consommateur de données pourrait avoir besoin d'autres moyens pour tenir un pair responsable de l'état supplémentaire qu'il maintient pour les messages partiellement traités.

L'interblocage peut aussi se produire si des données sur différents flux sont interdépendantes. Supposons que des données sur un flux arrivent avant les données sur un second flux dont elles dépendent. Un interblocage peut se produire si le premier flux est laissé non lu, empêchant le récepteur d'étendre le crédit de contrôle de flux pour le second flux. Pour réduire la probabilité d'interblocage pour des données interdépendantes, l'expéditeur devrait s'assurer que les données dépendantes ne sont pas envoyées tant que les données dont elles dépendent n'ont pas été prises en compte dans le crédit de contrôle de flux au niveau du flux et de la connexion.

Certains scénarios d'interblocage pourraient être résolus en annulant les flux affectés avec STOP_SENDING ou RESET_STREAM. L'annulation de certains flux entraîne la terminaison de la connexion dans certains protocoles.

4.5. Engagements de limite de flux (Stream Limit Commitments)​

Les extrémités QUIC sont responsables de communiquer la limite cumulative de flux qu'elles permettraient d'être ouverts par leur pair. Les limites initiales sont annoncées en utilisant les paramètres de transport initial_max_streams_bidi et initial_max_streams_uni. À mesure que les flux sont ouverts et fermés, ils sont consumés, et le total cumulatif est incrémenté. Les limites peuvent être augmentées en utilisant la trame MAX_STREAMS, mais il n'y a aucun mécanisme pour réduire les limites. Une fois que les limites de flux sont atteintes, aucun autre flux ne peut être ouvert, ce qui empêche les applications utilisant QUIC de progresser davantage. À ce stade, les connexions peuvent être terminées via un délai d'inactivité ou une fermeture explicite ; voir la Section 10.

Une application qui utilise QUIC et communique une limite de flux cumulative pourrait exiger que la connexion soit fermée avant que la limite ne soit atteinte, par exemple pour arrêter le serveur afin d'effectuer une maintenance planifiée. La fermeture immédiate de connexion provoque la fermeture abrupte des flux activement utilisés. Selon la façon dont une application utilise les flux QUIC, cela pourrait être indésirable ou préjudiciable au comportement ou aux performances.

Une technique de fermeture plus gracieuse consiste à arrêter d'envoyer des augmentations aux limites de flux et à permettre à la connexion de se terminer naturellement une fois que les flux restants sont consumés. Cependant, la période de temps nécessaire pour le faire dépend du pair, et une période de fermeture imprévisible pourrait ne pas correspondre aux besoins d'application ou opérationnels. Les applications utilisant QUIC peuvent être conservatrices avec les limites de flux ouverts afin de réduire l'engagement et l'indéterminisme. Cependant, être trop conservateur avec les limites de flux affecte la concurrence des flux. Équilibrer ces aspects peut être spécifique aux applications et à leurs déploiements.

Au lieu de s'appuyer sur les limites de flux pour éviter une fermeture abrupte, le mécanisme de fermeture gracieuse d'une couche application peut être utilisé pour communiquer l'intention de fermer explicitement la connexion à un moment futur. HTTP/3 fournit un tel mécanisme en utilisant la trame GOAWAY. Dans HTTP/3, lorsque la trame GOAWAY est reçue par un client, il arrête d'ouvrir de nouveaux flux même si la limite de flux cumulative le permettrait. Au lieu de cela, le client créerait une nouvelle connexion sur laquelle ouvrir d'autres flux. Une fois que tous les flux sont fermés sur l'ancienne connexion, elle peut être terminée en toute sécurité par une fermeture de connexion ou après l'expiration du délai d'inactivité (voir la Section 10).

5. Packetisation et latence (Packetization and Latency)​

QUIC expose une interface qui fournit plusieurs flux à l'application ; cependant, l'application ne peut généralement pas contrôler comment les données transmises sur ces flux sont mappées en trames ou comment ces trames sont regroupées en paquets.

Par défaut, de nombreuses implémentations essaieront d'emballer des trames STREAM d'un ou plusieurs flux dans chaque paquet QUIC, afin de minimiser la consommation de bande passante et les coûts de calcul (voir la Section 13 de [QUIC]). S'il n'y a pas assez de données disponibles pour remplir un paquet, une implémentation pourrait attendre un court moment pour optimiser l'efficacité de bande passante plutôt que la latence. Ce délai peut être soit préconfiguré, soit ajusté dynamiquement en fonction du modèle d'envoi observé de l'application.

Si l'application nécessite une faible latence, avec seulement de petits morceaux de données à envoyer, il peut être utile d'indiquer à QUIC que toutes les données devraient être envoyées immédiatement. Alternativement, si l'application s'attend à utiliser un modèle d'envoi spécifique, elle peut aussi fournir un délai suggéré à QUIC pour le temps d'attente avant de regrouper les trames en un paquet.

De même, une application n'a généralement aucun contrôle sur la longueur d'un paquet QUIC sur le fil. QUIC fournit la capacité d'ajouter une trame PADDING pour augmenter arbitrairement la taille des paquets. Le rembourrage est utilisé par QUIC pour s'assurer que le chemin est capable de transférer des datagrammes d'au moins une certaine taille pendant la négociation (voir les Sections 8.1 et 14.1 de [QUIC]) et pour la validation de chemin après migration de connexion (voir la Section 8.2 de [QUIC]) ainsi que pour Datagram Packetization Layer PMTU Discovery (DPLPMTUD) (voir la Section 14.3 de [QUIC]).

Le rembourrage peut aussi être utilisé par une application pour réduire la fuite d'informations sur les données qui sont envoyées. Une implémentation QUIC peut exposer une interface qui permet à une couche application de spécifier comment appliquer le rembourrage.

6. Gestion des erreurs (Error Handling)​

QUIC recommande que les extrémités signalent toute erreur détectée au pair. Les erreurs peuvent se produire au niveau de la couche transport et de la couche application. Les erreurs de transport, telles qu'une violation de protocole, affectent l'ensemble de la connexion. Les applications qui utilisent QUIC peuvent définir leur propre détection et signalement d'erreurs (voir, par exemple, la Section 8 de [QUIC-HTTP]). Les erreurs d'application peuvent affecter une connexion entière ou un seul flux.

QUIC définit un espace de codes d'erreur qui est utilisé pour la gestion des erreurs au niveau de la couche transport. QUIC encourage les extrémités à utiliser le code le plus spécifique, bien que tout code applicable soit permis, y compris les codes génériques.

Les applications utilisant QUIC définissent un espace de codes d'erreur qui est indépendant de QUIC ou d'autres applications (voir, par exemple, la Section 8.1 de [QUIC-HTTP]). Les valeurs dans un espace de codes d'erreur d'application peuvent être réutilisées entre les erreurs au niveau de la connexion et au niveau du flux.

Les erreurs de connexion mènent à la terminaison de la connexion. Elles sont signalées en utilisant une trame CONNECTION_CLOSE, qui contient un code d'erreur et un champ reason qui peut être de longueur zéro. Différents types de trames CONNECTION_CLOSE sont utilisés pour signaler les erreurs de transport et d'application.

Les erreurs de flux mènent à la terminaison du flux. Celles-ci sont signalées en utilisant des trames STOP_SENDING ou RESET_STREAM, qui contiennent uniquement un code d'erreur.

7. Efficacité des accusés de réception (Acknowledgment Efficiency)​

QUIC version 1 sans extensions utilise une stratégie d'accusé de réception adoptée de TCP (voir la Section 13.2 de [QUIC]). C'est-à-dire qu'elle recommande que tous les autres paquets soient acquittés. Cependant, générer et traiter les accusés de réception QUIC consomme des ressources chez un expéditeur et un récepteur. Les accusés de réception entraînent aussi des coûts de transfert et contribuent à l'utilisation du lien, ce qui peut impacter les performances sur certains types de réseau. Les applications pourraient être en mesure d'améliorer les performances globales en utilisant des stratégies alternatives qui réduisent le taux d'accusés de réception. [QUIC-ACK-FREQUENCY] décrit une extension pour signaler le délai désiré des accusés de réception et discute des cas d'utilisation ainsi que des implications pour le contrôle de congestion et la récupération.

8. Sélection de port et découverte d'extrémité d'application (Port Selection and Application Endpoint Discovery)​

En général, les numéros de port servent deux objectifs : « premièrement, ils fournissent un identifiant de démultiplexage pour différencier les sessions de transport entre la même paire d'extrémités, et deuxièmement, ils peuvent aussi identifier le protocole d'application et le service associé auxquels les processus se connectent » (Section 3 de [RFC6335]). L'hypothèse qu'une application peut être identifiée dans le réseau sur la base du numéro de port est moins vraie aujourd'hui en raison de l'encapsulation et des mécanismes d'assignation dynamique de ports, comme noté dans [RFC6335].

Comme QUIC est un protocole de transport à usage général, il n'y a aucune exigence que les serveurs utilisent un port UDP particulier pour QUIC. Pour une application avec un repli vers TCP qui n'a pas déjà un mappage alternatif vers UDP, il est généralement approprié d'enregistrer (si nécessaire) et d'utiliser le numéro de port UDP correspondant au port TCP déjà enregistré pour l'application. Par exemple, le port par défaut pour HTTP/3 [QUIC-HTTP] est le port UDP 443, analogue à HTTP/1.1 ou HTTP/2 over TLS over TCP.

Étant donné la prévalence de l'hypothèse dans la pratique de gestion réseau qu'un numéro de port mappe sans ambiguïté à une application, l'utilisation de ports qui ne peuvent pas facilement être mappés à un nom de service enregistré pourrait conduire à un blocage ou à d'autres changements du comportement de transfert par des éléments réseau tels que les pare-feu qui utilisent le numéro de port pour l'identification d'application.

Les applications pourraient définir un mécanisme alternatif de découverte d'extrémité pour permettre l'utilisation de ports autres que le port par défaut. Par exemple, HTTP/3 (Sections 3.2 et 3.3 de [QUIC-HTTP]) spécifie l'utilisation d'HTTP Alternative Services [RFC7838] pour qu'une origine HTTP annonce la disponibilité d'une extrémité HTTP/3 équivalente sur un certain port UDP en utilisant "h3" comme jeton Application-Layer Protocol Negotiation (ALPN) [RFC7301].

ALPN permet au client et au serveur de négocier lequel de plusieurs protocoles sera utilisé sur une connexion donnée. Par conséquent, plusieurs applications pourraient être supportées sur un seul port UDP en fonction du jeton ALPN offert. Les applications utilisant QUIC sont tenues d'enregistrer un jeton ALPN pour utilisation dans la négociation TLS.

Comme QUIC version 1 a reporté la définition d'un mécanisme complet de négociation de version, HTTP/3 exige QUIC version 1 et définit le jeton ALPN ("h3") comme ne s'appliquant qu'à cette version. Jusqu'à présent, aucune approche unique n'a été sélectionnée pour gérer l'utilisation de différentes versions de QUIC, ni dans HTTP/3 ni en général. Les protocoles d'application qui utilisent QUIC doivent considérer comment le protocole gérera différentes versions de QUIC. Les décisions pour ces protocoles pourraient être informées par les choix faits par d'autres protocoles, comme HTTP/3.

8.1. Sélection du port source (Source Port Selection)​

Certains protocoles UDP sont vulnérables aux attaques par réflexion, où un attaquant est capable de diriger le trafic vers un tiers comme déni de service. Par exemple, ces ports source sont associés à des applications connues pour être vulnérables aux attaques par réflexion, souvent en raison d'une mauvaise configuration du serveur :

  • port 53 - DNS [RFC1034]
  • port 123 - NTP [RFC5905]
  • port 1900 - SSDP [SSDP]
  • port 5353 - mDNS [RFC6762]
  • port 11211 - memcache

Les services pourraient bloquer les ports source associés à des protocoles connus pour être vulnérables aux attaques par réflexion afin d'éviter le surcoût de traitement de grands nombres de paquets. Cependant, cette pratique a des effets négatifs sur les clients — non seulement elle nécessite l'établissement d'une nouvelle connexion, mais dans certains cas elle pourrait amener le client à éviter d'utiliser QUIC pour ce service pendant une période de temps et à rétrograder vers un protocole non-UDP (voir la Section 2).

En conséquence, les implémentations clientes sont encouragées à éviter d'utiliser des ports source associés à des protocoles connus pour être vulnérables aux attaques par réflexion. Notez que suivre le conseil général pour les implémentations clientes donné dans [RFC6335], d'utiliser des ports éphémères dans la plage 49152-65535, a pour effet d'éviter ces ports. Notez que d'autres ports source pourraient aussi être des vecteurs de réflexion.

9. Migration de connexion (Connection Migration)​

QUIC supporte la migration de connexion par le client. Si l'adresse IP du client change, une extrémité QUIC peut toujours associer des paquets à une connexion de transport existante en utilisant le champ Destination Connection ID (voir la Section 11) dans l'en-tête QUIC. Cela supporte les cas où l'information d'adresse change, tels que le rebinding NAT, le changement intentionnel de l'interface locale, l'expiration d'une adresse IPv6 temporaire [RFC8981], ou l'indication du serveur d'une adresse préférée (Section 9.6 de [QUIC]).

L'utilisation d'un identifiant de connexion de longueur non nulle pour le serveur est fortement recommandée si des clients sont ou pourraient être derrière un NAT. Un identifiant de connexion de longueur non nulle est aussi fortement recommandé lorsque la migration active est supportée. Si une connexion est intentionnellement migrée vers un nouveau chemin, un nouvel identifiant de connexion est utilisé pour minimiser la linkabilité par les observateurs réseau. L'autre extrémité QUIC utilise l'identifiant de connexion pour lier différentes adresses à la même connexion et entité si un identifiant de connexion de longueur non nulle est fourni.

La spécification de base de QUIC version 1 ne supporte que l'utilisation d'un seul chemin réseau à la fois, ce qui permet les cas d'utilisation de basculement. La validation de chemin est requise afin que les extrémités valident les chemins avant utilisation pour éviter les attaques d'usurpation d'adresse. La validation de chemin prend au moins un RTT, et le contrôle de congestion sera aussi réinitialisé après migration de chemin. Par conséquent, la migration a généralement un impact sur les performances.

Les paquets de sondage QUIC, qui peuvent être envoyés sur plusieurs chemins à la fois, sont utilisés pour effectuer la validation d'adresse ainsi que pour mesurer les caractéristiques du chemin. Les paquets de sondage ne peuvent pas transporter de données d'application mais contiennent probablement des trames de rembourrage. Les extrémités peuvent utiliser l'information sur leur réception comme entrée au contrôle de congestion pour ce chemin. Les applications pourraient utiliser l'information apprise du sondage pour informer une décision de changer de chemin.

Seul le client peut migrer activement dans la version 1 de QUIC. Cependant, les serveurs peuvent indiquer pendant la négociation qu'ils préfèrent transférer la connexion vers une adresse différente après la négociation. Par exemple, cela pourrait être utilisé pour passer d'une adresse partagée par plusieurs serveurs à une adresse unique à l'instance de serveur. Le serveur peut fournir une adresse IPv4 et une adresse IPv6 dans un paramètre de transport pendant la négociation TLS, et le client peut choisir entre les deux si les deux sont fournies. Voir la Section 9.6 de [QUIC].

10. Terminaison de connexion (Connection Termination)​

Les connexions QUIC sont terminées de l'une des trois façons suivantes : délai d'inactivité implicite, fermeture immédiate explicite, ou réinitialisation sans état explicite.

QUIC ne fournit aucun mécanisme pour une terminaison de connexion gracieuse ; les applications utilisant QUIC peuvent définir leur propre processus de terminaison gracieuse (voir, par exemple, la Section 5.2 de [QUIC-HTTP]).

Le délai d'inactivité QUIC est activé via des paramètres de transport. Le client et le serveur annoncent une période de délai d'attente, et la valeur effective pour la connexion est le minimum des deux valeurs. Après l'écoulement de la période de délai d'attente, la connexion est silencieusement fermée. Une application devrait donc être capable de configurer sa propre valeur maximale, ainsi qu'avoir accès à la valeur minimale calculée pour cette connexion. Une application peut ajuster le délai d'inactivité maximal pour les nouvelles connexions en fonction du nombre de connexions ouvertes ou attendues puisque des valeurs de délai d'attente plus courtes peuvent libérer des ressources plus rapidement.

Les données d'application échangées sur des flux ou dans des datagrammes reportent le délai d'inactivité QUIC. Les applications qui fournissent leurs propres mécanismes de maintien en vie maintiendront donc une connexion QUIC en vie. Les applications qui ne fournissent pas leur propre maintien en vie peuvent utiliser des mécanismes de couche transport (voir la Section 10.1.2 de [QUIC] et la Section 3.2). Cependant, les interfaces d'implémentation QUIC pour contrôler un tel comportement de transport peuvent varier, affectant la robustesse de telles approches.

Une fermeture immédiate est signalée par une trame CONNECTION_CLOSE (voir la Section 6). La fermeture immédiate amène tous les flux à être immédiatement fermés, ce qui peut affecter les applications ; voir la Section 4.5.

Une réinitialisation sans état est une option de dernier recours pour une extrémité qui n'a pas accès à l'état de connexion. Recevoir une réinitialisation sans état est une indication d'une erreur irrécupérable distincte des erreurs de connexion en ce qu'aucune information de couche application n'est fournie.

11. Exposition d'informations et identifiant de connexion (Information Exposure and the Connection ID)​

QUIC expose certaines informations au réseau dans la partie non chiffrée de l'en-tête soit avant que le contexte de chiffrement ne soit établi, soit parce que l'information est destinée à être utilisée par le réseau. Pour plus d'informations sur la gérabilité de QUIC, voir [QUIC-MANAGEABILITY]. QUIC a un en-tête long qui expose des informations supplémentaires (la version et l'identifiant de connexion source), tandis que l'en-tête court expose uniquement l'identifiant de connexion de destination. Dans QUIC version 1, l'en-tête long est utilisé pendant l'établissement de connexion, tandis que l'en-tête court est utilisé pour la transmission de données dans une connexion établie.

L'identifiant de connexion peut être de longueur zéro. Des identifiants de connexion de longueur zéro peuvent être choisis sur chaque extrémité individuellement et sur tout paquet sauf les premiers paquets envoyés par les clients pendant l'établissement de connexion.

Une extrémité qui sélectionne un identifiant de connexion de longueur zéro recevra des paquets avec un identifiant de connexion de destination de longueur zéro. L'extrémité doit utiliser d'autres informations, telles que les adresses IP source et destination et le numéro de port pour identifier à quelle connexion il est fait référence. Cela pourrait signifier que l'extrémité est incapable de faire correspondre avec succès les datagrammes aux connexions si ces valeurs changent, rendant la connexion effectivement incapable de survivre au rebinding NAT ou de migrer vers un nouveau chemin.

11.1. Identifiant de connexion généré par le serveur (Server-Generated Connection ID)​

QUIC supporte un identifiant de connexion généré par le serveur qui est transmis au client pendant l'établissement de connexion (voir la Section 7.2 de [QUIC]). Les serveurs derrière des équilibreurs de charge peuvent avoir besoin de changer l'identifiant de connexion pendant la négociation, en encodant l'identité du serveur ou des informations sur son pool d'équilibrage de charge, afin de supporter l'équilibrage de charge sans état.

Les déploiements de serveurs avec des équilibreurs de charge et d'autres infrastructures de routage doivent s'assurer que cette infrastructure achemine de manière cohérente les paquets vers l'instance de serveur qui a l'état de connexion, même si les adresses, ports ou identifiants de connexion changent. Cela pourrait nécessiter une coordination entre serveurs et infrastructure. Une méthode pour y parvenir implique d'encoder des informations de routage dans l'identifiant de connexion. Pour un exemple de cette technique, voir [QUIC-LB].

11.2. Atténuer la linkabilité temporelle avec la migration d'identifiant de connexion (Mitigating Timing Linkability with Connection ID Migration)​

Si les extrémités QUIC n'émettent pas de nouveaux identifiants de connexion, alors les clients ne peuvent pas réduire la linkabilité de la migration d'adresse en les utilisant. Choisir des valeurs qui ne sont pas linkables pour un observateur extérieur garantit que l'activité sur différents chemins ne peut pas être trivialement corrélée en utilisant l'identifiant de connexion.

Bien que des schémas de génération d'identifiant de connexion suffisamment robustes atténueront les problèmes de linkabilité, ils ne fournissent pas une protection complète. L'analyse des durées de vie des 6-tuples (adresses source et destination ainsi que le Connection ID migré) peut exposer ces liens de toute façon.

Dans le cas où la migration de connexion dans un pool de serveurs est rare, il est trivial pour un observateur d'associer deux identifiants de connexion. Inversement, lorsque chaque serveur gère plusieurs migrations simultanées, même un mappage de serveur exposé peut être une information insuffisante.

Les atténuations les plus efficaces pour ces attaques passent par la conception du réseau et/ou les pratiques opérationnelles, en utilisant une architecture d'équilibrage de charge qui charge plus de flux sur une seule adresse côté serveur, en coordonnant le timing des migrations dans une tentative d'augmenter le nombre de migrations simultanées à un moment donné, ou en utilisant d'autres moyens.

11.3. Utiliser le Retry serveur pour la redirection (Using Server Retry for Redirection)​

QUIC fournit un paquet Retry qui peut être envoyé par un serveur en réponse au paquet Initial du client. Le serveur peut choisir un nouvel identifiant de connexion dans ce paquet, et le client réessayera en envoyant un autre paquet Initial client avec l'identifiant de connexion sélectionné par le serveur. Ce mécanisme peut être utilisé pour rediriger une connexion vers un serveur différent, par exemple pour des raisons de performance ou lorsque les serveurs d'un pool de serveurs sont mis à niveau progressivement et peuvent donc supporter différentes versions de QUIC.

Dans ce cas, on suppose que tous les serveurs appartenant à un certain pool sont servis en coopération avec des équilibreurs de charge qui transfèrent le trafic sur la base de l'identifiant de connexion. Un serveur peut choisir l'identifiant de connexion dans le paquet Retry de telle sorte que l'équilibreur de charge redirigera le prochain paquet Initial vers un serveur différent de ce pool. Alternativement, l'équilibreur de charge peut offrir directement un offload Retry comme décrit plus en détail dans [QUIC-RETRY].

L'approche décrite dans la Section 4 de [RFC5077] pour construire des tickets de reprise TLS fournit un exemple qui peut aussi être appliqué aux jetons de validation. Cependant, l'utilisation d'algorithmes cryptographiques plus modernes est hautement recommandée.

12. Quality of Service (QoS) et Diffserv Code Point (DSCP)​

QUIC, tel que défini dans [QUIC], a un seul contrôleur de congestion et gestionnaire de récupération. Cette conception suppose que tous les paquets d'une connexion QUIC, ou au moins avec le même 5-tuple {adresse dest, adresse source, protocole, port dest, port source}, qui ont le même Diffserv Code Point (DSCP) [RFC2475] recevront un traitement réseau similaire puisque le retour d'information sur la perte ou le délai de chaque paquet est utilisé comme entrée au contrôleur de congestion. Par conséquent, les paquets appartenant à la même connexion devraient utiliser un seul DSCP. La Section 5.1 de [RFC7657] fournit une discussion des interactions Diffserv avec les protocoles de transport de datagrammes [RFC7657] (à cet égard, les interactions avec QUIC ressemblent à celles de Stream Control Transmission Protocol (SCTP)).

Lors du multiplexage de plusieurs flux sur une seule connexion QUIC, la valeur DSCP sélectionnée devrait être celle associée à la priorité la plus élevée demandée pour tous les flux multiplexés.

Si un traitement réseau différentiel est souhaité, par exemple par l'utilisation de différents DSCP, plusieurs connexions QUIC vers le même serveur peuvent être utilisées. En général, il est recommandé de minimiser le nombre de connexions QUIC vers le même serveur pour éviter une surcharge accrue et, plus important encore, un contrôle de congestion concurrent.

Comme dans d'autres utilisations de Diffserv, lorsqu'un paquet entre dans un segment de réseau qui ne supporte pas la valeur DSCP, cela pourrait entraîner que la connexion ne reçoive pas le traitement réseau qu'elle attend. La valeur DSCP dans ce paquet pourrait aussi être remarquee à mesure que le paquet voyage le long du chemin réseau, changeant le traitement demandé.

13. Utilisation des versions et de la négociation cryptographique (Use of Versions and Cryptographic Handshake)​

Le versionnement dans QUIC peut changer complètement le comportement du protocole, sauf pour la signification de quelques champs d'en-tête qui ont été déclarés invariants [QUIC-INVARIANTS]. Une version de QUIC avec un numéro de version plus élevé ne fournira pas nécessairement un meilleur service mais pourrait simplement fournir un ensemble de fonctionnalités différent. En tant que tel, une application doit être capable de sélectionner quelles versions de QUIC elle veut utiliser.

Une nouvelle version pourrait utiliser un schéma de chiffrement autre que TLS 1.3 ou supérieur. [QUIC] spécifie des exigences pour la négociation cryptographique telle que actuellement réalisée par TLS 1.3 et décrite dans une spécification séparée [QUIC-TLS]. Cette séparation est effectuée pour permettre un versionnement léger avec différentes négociations cryptographiques.

Le registre "QUIC Versions" établi dans [QUIC] permet des enregistrements provisoires pour l'expérimentation. L'enregistrement, également des versions expérimentales, est important pour éviter les collisions. Les versions expérimentales ne devraient pas être utilisées à long terme ni enregistrées comme permanentes pour minimiser le risque d'empreinte digitale basée sur le numéro de version.

14. Permettre le déploiement de nouvelles versions (Enabling Deployment of New Versions)​

QUIC version 1 ne spécifie pas de mécanisme de négociation de version dans la spécification de base, mais [QUIC-VERSION-NEGOTIATION] propose une extension qui fournit une négociation de version compatible.

Cette approche utilise un mécanisme de déploiement en trois étapes, permettant un déploiement progressif et l'expérimentation avec plusieurs versions dans un grand déploiement de serveurs. Dans cette approche, tous les serveurs du déploiement doivent accepter des connexions utilisant une nouvelle version (étape 1) avant qu'un serveur ne l'annonce (étape 2), et l'authentification de la nouvelle version (étape 3) ne procède qu'après que l'annonce de cette version est complètement déployée.

Voir la Section 5 de [QUIC-VERSION-NEGOTIATION] pour les détails.

15. Service de datagrammes non fiables sur QUIC (Unreliable Datagram Service over QUIC)​

[RFC9221] spécifie une extension QUIC pour permettre l'envoi et la réception de datagrammes non fiables sur QUIC. Contrairement au fonctionnement directement sur UDP, les applications qui utilisent le service de datagrammes QUIC n'ont pas besoin d'implémenter leur propre contrôle de congestion, selon [RFC8085], car les datagrammes QUIC sont contrôlés en congestion.

Les datagrammes QUIC ne sont pas contrôlés en flux, et en tant que tels des morceaux de données peuvent être abandonnés si le récepteur est surchargé. Alors que le service de transmission fiable de QUIC fournit une interface basée sur les flux pour envoyer et recevoir des données dans l'ordre sur plusieurs flux QUIC, le service de datagrammes a une interface basée sur les messages non ordonnée. Si nécessaire, un cadrage de couche application peut être utilisé au-dessus pour permettre à des flux séparés de datagrammes non fiables d'être multiplexés sur une connexion QUIC.

16. Considérations IANA (IANA Considerations)​

Le présent document n'a aucune action pour IANA ; cependant, notez que la Section 8 recommande qu'une application qui a déjà enregistré un port TCP mais veut spécifier QUIC comme transport devrait enregistrer un port UDP analogue à son enregistrement TCP existant.

17. Considérations de sécurité (Security Considerations)​

Voir les considérations de sécurité dans [QUIC] et [QUIC-TLS] ; les considérations de sécurité pour le protocole de transport sous-jacent sont pertinentes pour les applications utilisant QUIC. Les considérations sur la linkabilité, les attaques par rejeu et le caractère aléatoire discutées dans [QUIC-TLS] devraient être prises en compte lors du déploiement et de l'utilisation de QUIC.

En outre, la migration vers une nouvelle adresse expose une liaison entre les adresses client au serveur et peut aussi exposer cette liaison au chemin si l'identifiant de connexion ne peut pas être changé ou si les flux peuvent autrement être corrélés. Lorsque la migration est supportée, cela doit être considéré en ce qui concerne la vie privée de l'utilisateur.

Les développeurs d'applications devraient noter que tout repli qu'ils utilisent lorsque QUIC ne peut pas être utilisé en raison du blocage réseau d'UDP devrait garantir les mêmes propriétés de sécurité que QUIC. Si cela n'est pas possible, la connexion devrait échouer pour permettre à l'application de gérer explicitement le repli vers une alternative moins sécurisée. Voir la Section 2.

En outre, [QUIC-HTTP] fournit des considérations de sécurité spécifiques à HTTP. Cependant, des discussions telles que sur les attaques inter-protocoles, l'analyse de trafic et le rembourrage, ou la migration pourraient aussi être pertinentes pour d'autres applications utilisant QUIC.

18. Références (References)​

18.1. Références normatives (Normative References)​

[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, https://www.rfc-editor.org/info/rfc8999.

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, https://www.rfc-editor.org/info/rfc9001.

18.2. Références informatives (Informative References)​

[Edeline16] Edeline, K., Kühlewind, M., Trammell, B., Aben, E., and B. Donnet, "Using UDP for Internet Transport Evolution", DOI 10.48550/arXiv.1612.07816, 22 December 2016, https://arxiv.org/abs/1612.07816.

[Hatonen10] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, "An Experimental Study of Home Gateway Characteristics", Proc. ACM IMC 2010, November 2010, <https://conferences.sigcomm.org/imc/2010/papers/ p260.pdf>.

[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, https://www.rfc-editor.org/info/rfc8470.

[PaaschNanog] Paasch, C., "Network support for TCP Fast Open", NANOG 67 Presentation, 13 June 2016, <https://www.nanog.org/sites/default/files/ Paasch_Network_Support.pdf>.

[QUIC-ACK-FREQUENCY] Iyengar, J. and I. Swett, "QUIC Acknowledgement Frequency", Work in Progress, Internet-Draft, draft-ietf- quic-ack-frequency-02, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic- ack-frequency-02>.

[QUIC-HTTP] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, https://www.rfc-editor.org/info/rfc9114.

[QUIC-LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating Routable QUIC Connection IDs", Work in Progress, Internet- Draft, draft-ietf-quic-load-balancers-14, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic- load-balancers-14>.

[QUIC-MANAGEABILITY] Kühlewind, M. and B. Trammell, "Manageability of the QUIC Transport Protocol", RFC 9312, DOI 10.17487/RFC9312, September 2022, https://www.rfc-editor.org/info/rfc9312.

[QUIC-RETRY] Duke, M. and N. Banks, "QUIC Retry Offload", Work in Progress, Internet-Draft, draft-ietf-quic-retry-offload- 00, 25 May 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-quic-retry-offload-00>.

[QUIC-VERSION-NEGOTIATION] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-version-negotiation-10, 27 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic- version-negotiation-10>.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, https://www.rfc-editor.org/info/rfc1034.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, https://www.rfc-editor.org/info/rfc2475.

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, https://www.rfc-editor.org/info/rfc5077.

[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, https://www.rfc-editor.org/info/rfc5382.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, https://www.rfc-editor.org/info/rfc5905.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, https://www.rfc-editor.org/info/rfc6335.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, https://www.rfc-editor.org/info/rfc6762.

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, https://www.rfc-editor.org/info/rfc7301.

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, https://www.rfc-editor.org/info/rfc7413.

[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, https://www.rfc-editor.org/info/rfc7657.

[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, https://www.rfc-editor.org/info/rfc7838.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, https://www.rfc-editor.org/info/rfc8085.

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, https://www.rfc-editor.org/info/rfc8981.

[RFC9218] Oku, K. and L. Pardue, "Extensible Prioritization Scheme for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022, https://www.rfc-editor.org/info/rfc9218.

[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, https://www.rfc-editor.org/info/rfc9221.

[SSDP] Donoho, A., Roe, B., Bodlaender, M., Gildred, J., Messer, A., Kim, Y., Fairman, B., and J. Tourzan, "UPnP Device Architecture 2.0", 17 April 2020, <https://openconnectivity.org/upnp-specs/UPnP-arch- DeviceArchitecture-v2.0-20200417.pdf>.

[Swett16] Swett, I., "QUIC Deployment Experience @Google", IETF96 QUIC BoF Presentation, 20 July 2016, <https://www.ietf.org/proceedings/96/slides/slides-96- quic-3.pdf>.

[TAPS-ARCH] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and C. Perkins, "An Architecture for Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-arch-14, 27 September 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-taps-arch-14>.

[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, https://www.rfc-editor.org/info/rfc8446.

[Trammell16] Trammell, B. and M. Kühlewind, "Internet Path Transparency Measurements using RIPE Atlas", RIPE 72 MAT Presentation, 25 May 2016, <https://ripe72.ripe.net/wp-content/uploads/ presentations/86-atlas-udpdiff.pdf>.

Remerciements (Acknowledgments)​

Remerciements particuliers aux relecteurs Last Call Chris Lonvick et Ines Robles.

Ce travail a été partiellement soutenu par la Commission européenne dans le cadre de l'accord de subvention Horizon 2020 no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI) et par le Secrétariat d'État suisse à la formation, à la recherche et à l'innovation sous le contrat no. 15.0268. Ce soutien n'implique pas d'approbation.

Contributeurs (Contributors)​

Les personnes suivantes ont contribué un texte significatif ou des commentaires sur le présent document :

Gorry Fairhurst, Ian Swett, Igor Lubashev, Lucas Pardue, Mike Bishop, Mark Nottingham, Martin Duke, Martin Thomson, Sean Turner, Tommy Pauly

Adresses des auteurs (Authors' Addresses)​

Mirja Kühlewind
Ericsson
Email: [email protected]

Brian Trammell
Google Switzerland GmbH
Gustav-Gull-Platz 1
CH-8004 Zurich
Switzerland
Email: [email protected]