Aller au contenu principal

RFC 8999 - Propriétés indépendantes de la version de QUIC

  • Statut: Proposed Standard
  • Publié: May 2021
  • Stream: IETF
  • Errata: Pas d'errata

Résumé (Abstract)​

Ce document définit les propriétés du protocole de transport QUIC (QUIC Transport Protocol) qui sont communes à toutes les versions du protocole.

Table des matières (Table of Contents)​

1. Description extrêmement abstraite de QUIC (An Extremely Abstract Description of QUIC)​

QUIC est un protocole orienté connexion (Connection-Oriented Protocol) entre deux points de terminaison (Endpoints). Ces points de terminaison échangent des datagrammes UDP (UDP Datagrams). Ces datagrammes UDP contiennent des paquets QUIC (QUIC Packets). Les points de terminaison QUIC utilisent des paquets QUIC pour établir une connexion QUIC (QUIC Connection), qui est un état de protocole partagé (Shared Protocol State) entre ces points de terminaison.

2. Propriétés fixes de toutes les versions QUIC (Fixed Properties of All QUIC Versions)​

En plus de fournir un transport sécurisé et multiplexé (Secure, Multiplexed Transport), QUIC [QUIC-TRANSPORT] permet l'option de négocier une version. Cela permet au protocole d'évoluer dans le temps en réponse à de nouvelles exigences. De nombreuses caractéristiques du protocole peuvent changer entre les versions.

Ce document décrit le sous-ensemble de QUIC qui est destiné à rester stable lors du développement et du déploiement de nouvelles versions. Tous ces invariants (Invariants) sont indépendants de la version IP.

L'objectif principal de ce document est de garantir qu'il est possible de déployer de nouvelles versions de QUIC. En documentant les propriétés qui ne peuvent pas changer, ce document vise à préserver la capacité des points de terminaison QUIC à négocier des changements dans tout autre aspect du protocole. En conséquence, cela garantit également une quantité minimale d'informations mises à disposition des entités autres que les points de terminaison. Sauf interdiction expresse dans ce document, tout aspect du protocole peut changer entre différentes versions.

L'annexe A contient une liste non exhaustive de certaines hypothèses incorrectes qui pourraient être faites sur la base de la connaissance de QUIC version 1 ; celles-ci ne s'appliquent pas à toutes les versions de QUIC.

3. Conventions et définitions (Conventions and Definitions)​

Les mots-clés "MUST" (doit), "MUST NOT" (ne doit pas), "REQUIRED" (requis), "SHALL" (doit), "SHALL NOT" (ne doit pas), "SHOULD" (devrait), "SHOULD NOT" (ne devrait pas), "RECOMMENDED" (recommandé), "NOT RECOMMENDED" (non recommandé), "MAY" (peut) et "OPTIONAL" (optionnel) dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Ce document définit des exigences pour les futures versions de QUIC, même lorsque un langage normatif n'est pas utilisé.

Ce document utilise les termes et les conventions de notation de [QUIC-TRANSPORT].

4. Conventions de notation (Notational Conventions)​

Le format des paquets est décrit en utilisant la notation définie dans cette section. Cette notation est la même que celle utilisée dans [QUIC-TRANSPORT].

Les champs complexes sont nommés puis suivis d'une liste de champs entourée par une paire d'accolades correspondantes. Chaque champ de cette liste est séparé par des virgules.

Les champs individuels incluent des informations de longueur, ainsi que des indications sur la valeur fixe, l'optionnalité ou les répétitions. Les champs individuels utilisent les conventions de notation suivantes, toutes les longueurs étant en bits :

x (A) : indique que x a une longueur de A bits

x (A..B) : indique que x peut avoir n'importe quelle longueur de A à B ; A peut être omis pour indiquer un minimum de zéro bit, et B peut être omis pour indiquer aucune limite supérieure définie ; les valeurs de ce format se terminent toujours sur une limite d'octet

x (L) = C : indique que x a une valeur fixe de C ; la longueur de x est décrite par L, qui peut utiliser l'une des formes de longueur ci-dessus

x (L) ... : indique que x est répété zéro fois ou plus et que chaque instance a une longueur de L

Ce document utilise des valeurs en ordre des octets réseau (Network Byte Order, c'est-à-dire big endian). Les champs sont placés en commençant par les bits de poids fort de chaque octet.

La figure 1 montre un exemple de structure :

Example Structure {
  One-bit Field (1),
  7-bit Field with Fixed Value (7) = 61,
  Arbitrary-Length Field (..),
  Variable-Length Field (8..24),
  Repeated Field (8) ...,
}

Figure 1 : Format d'exemple

5. Paquets QUIC (QUIC Packets)​

Les points de terminaison QUIC échangent des datagrammes UDP contenant un ou plusieurs paquets QUIC. Cette section décrit les caractéristiques invariantes d'un paquet QUIC. Une version de QUIC pourrait permettre plusieurs paquets QUIC dans un seul datagramme UDP, mais les propriétés invariantes ne décrivent que le premier paquet d'un datagramme.

QUIC définit deux types d'en-têtes de paquet (Packet Headers) : long et court. Les paquets avec un en-tête long sont identifiés par le bit le plus significatif (Most Significant Bit) du premier octet étant défini ; les paquets avec un en-tête court ont ce bit effacé.

Les paquets QUIC peuvent être protégés en intégrité (Integrity Protected), y compris l'en-tête. Cependant, les paquets de négociation de version QUIC (Version Negotiation Packets) ne sont pas protégés en intégrité ; voir la section 6.

Outre les valeurs décrites ici, la charge utile (Payload) des paquets QUIC est spécifique à la version (Version-Specific) et de longueur arbitraire (Arbitrary Length).

5.1 En-tête long (Long Header)​

Les en-têtes longs prennent la forme décrite dans la figure 2.

Long Header Packet {
  Header Form (1) = 1,
  Version-Specific Bits (7),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Version-Specific Data (..),
}

Figure 2 : En-tête long QUIC

Un paquet QUIC avec un en-tête long a le bit de poids fort du premier octet défini à 1. Tous les autres bits de cet octet sont spécifiques à la version.

Les quatre octets suivants incluent un champ Version de 32 bits (Version Field). Les versions sont décrites dans la section 5.4.

L'octet suivant contient la longueur en octets du champ ID de connexion de destination (Destination Connection ID Field) qui le suit. Cette longueur est encodée comme un entier non signé de 8 bits. Le champ ID de connexion de destination suit le champ Longueur de l'ID de connexion de destination et mesure entre 0 et 255 octets. Les ID de connexion sont décrits dans la section 5.3.

L'octet suivant contient la longueur en octets du champ ID de connexion source (Source Connection ID Field) qui le suit. Cette longueur est encodée comme un entier non signé de 8 bits. Le champ ID de connexion source suit le champ Longueur de l'ID de connexion source et mesure entre 0 et 255 octets.

Le reste du paquet contient un contenu spécifique à la version.

5.2 En-tête court (Short Header)​

Les en-têtes courts prennent la forme décrite dans la figure 3.

Short Header Packet {
  Header Form (1) = 0,
  Version-Specific Bits (7),
  Destination Connection ID (..),
  Version-Specific Data (..),
}

Figure 3 : En-tête court QUIC

Un paquet QUIC avec un en-tête court a le bit de poids fort du premier octet défini à 0.

Un paquet QUIC avec un en-tête court inclut un ID de connexion de destination immédiatement après le premier octet. L'en-tête court n'inclut pas les champs Longueur de l'ID de connexion de destination, Longueur de l'ID de connexion source, ID de connexion source ou Version. La longueur de l'ID de connexion de destination n'est pas encodée dans les paquets avec un en-tête court et n'est pas contrainte par cette spécification.

Le reste du paquet a une sémantique spécifique à la version.

5.3 ID de connexion (Connection ID)​

Un ID de connexion (Connection ID) est un champ opaque (Opaque Field) de longueur arbitraire.

La fonction principale d'un ID de connexion est de garantir que les changements d'adressage aux couches de protocole inférieures (UDP, IP et en dessous) ne causent pas la livraison de paquets pour une connexion QUIC au mauvais point de terminaison QUIC. L'ID de connexion est utilisé par les points de terminaison et les intermédiaires (Intermediaries) qui les supportent pour garantir que chaque paquet QUIC peut être livré à l'instance correcte d'un point de terminaison. Au point de terminaison, l'ID de connexion est utilisé pour identifier la connexion QUIC à laquelle le paquet est destiné.

L'ID de connexion est choisi par chaque point de terminaison en utilisant des méthodes spécifiques à la version. Les paquets pour la même connexion QUIC peuvent utiliser différentes valeurs d'ID de connexion.

5.4 Version​

Le champ Version (Version Field) contient un identifiant de 4 octets. Cette valeur peut être utilisée par les points de terminaison pour identifier une version de QUIC. Un champ Version avec une valeur de 0x00000000 est réservé pour la négociation de version ; voir la section 6. Toutes les autres valeurs sont potentiellement valides.

Les propriétés décrites dans ce document s'appliquent à toutes les versions de QUIC. Un protocole qui ne se conforme pas aux propriétés décrites dans ce document n'est pas QUIC. Les documents futurs pourraient décrire des propriétés supplémentaires qui s'appliquent à une version spécifique de QUIC ou à une plage de versions QUIC.

6. Négociation de version (Version Negotiation)​

Un point de terminaison QUIC qui reçoit un paquet avec un en-tête long et une version qu'il ne comprend pas ou ne supporte pas peut envoyer un paquet de négociation de version (Version Negotiation Packet) en réponse. Les paquets avec un en-tête court ne déclenchent pas de négociation de version.

Un paquet de négociation de version définit le bit de poids fort du premier octet, et se conforme donc au format d'un paquet avec un en-tête long tel que défini dans la section 5.1. Un paquet de négociation de version est identifiable en tant que tel par le champ Version, qui est défini à 0x00000000.

Version Negotiation Packet {
  Header Form (1) = 1,
  Unused (7),
  Version (32) = 0,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Supported Version (32) ...,
}

Figure 4 : Paquet de négociation de version

Seul le bit le plus significatif du premier octet d'un paquet de négociation de version a une valeur définie. Les 7 bits restants, étiquetés "Unused" (inutilisé), peuvent être définis à n'importe quelle valeur lors de l'envoi et doivent (MUST) être ignorés à la réception.

Après le champ ID de connexion source, le paquet de négociation de version contient une liste de champs Version supportée (Supported Version Fields), chacun identifiant une version que le point de terminaison envoyant le paquet supporte. Un paquet de négociation de version ne contient aucun autre champ. Un point de terminaison doit (MUST) ignorer un paquet qui ne contient aucun champ Version supportée ou contient une valeur de Version supportée tronquée.

Les paquets de négociation de version n'utilisent pas de protection d'intégrité ou de confidentialité. Les versions spécifiques de QUIC peuvent inclure des éléments de protocole qui permettent aux points de terminaison de détecter des modifications ou des corruptions dans l'ensemble des versions supportées.

Un point de terminaison doit (MUST) inclure la valeur du champ ID de connexion source du paquet qu'il reçoit dans le champ ID de connexion de destination. La valeur du champ ID de connexion source doit (MUST) être copiée du champ ID de connexion de destination du paquet reçu, qui est initialement sélectionné aléatoirement par un client. L'écho des deux ID de connexion donne aux clients une certaine assurance que le serveur a reçu le paquet et que le paquet de négociation de version n'a pas été généré par un attaquant incapable d'observer les paquets.

Un point de terminaison qui reçoit un paquet de négociation de version peut changer la version qu'il décide d'utiliser pour les paquets suivants. Les conditions dans lesquelles un point de terminaison change sa version QUIC dépendront de la version de QUIC qu'il choisit.

Voir [QUIC-TRANSPORT] pour une description plus complète de la façon dont un point de terminaison qui supporte QUIC version 1 génère et consomme un paquet de négociation de version.

7. Considérations de sécurité et de confidentialité (Security and Privacy Considerations)​

Il est possible que les middleboxes (Middleboxes) observent des caractéristiques d'une version spécifique de QUIC et supposent que lorsque d'autres versions de QUIC présentent des caractéristiques similaires, la même sémantique sous-jacente est exprimée. Il peut potentiellement y avoir de nombreuses telles caractéristiques ; voir l'annexe A. Certains efforts ont été faits pour éliminer ou obscurcir certaines caractéristiques observables dans QUIC version 1, mais beaucoup de celles-ci subsistent. D'autres versions de QUIC pourraient prendre différentes décisions de conception et ainsi présenter différentes caractéristiques.

Le numéro de version QUIC n'apparaît pas dans tous les paquets QUIC, ce qui signifie qu'extraire de manière fiable des informations d'un flux basé sur des caractéristiques spécifiques à la version nécessite que les middleboxes conservent un état pour chaque ID de connexion qu'ils voient.

Le paquet de négociation de version décrit dans ce document n'est pas protégé en intégrité ; il n'a qu'une protection modeste contre l'insertion par des attaquants. Un point de terminaison doit (MUST) authentifier le contenu sémantique d'un paquet de négociation de version s'il tente une version QUIC différente en conséquence.

8. Références (References)​

8.1 Références normatives (Normative References)​

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119.

[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174.

8.2 Références informatives (Informative References)​

[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.

[QUIC-TRANSPORT]
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.

[RFC5116]
McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
https://www.rfc-editor.org/info/rfc5116.

Annexe A. Hypothèses incorrectes (Incorrect Assumptions)​

Il existe plusieurs caractéristiques de QUIC version 1 [QUIC-TRANSPORT] qui ne sont pas protégées contre l'observation mais qui sont néanmoins considérées comme modifiables lors du déploiement d'une nouvelle version.

Cette section énumère un échantillon d'hypothèses incorrectes qui pourraient être faites sur QUIC sur la base de la connaissance de QUIC version 1. Certaines de ces déclarations ne sont même pas vraies pour QUIC version 1. Cette liste n'est pas exhaustive ; elle est destinée à être illustrative uniquement.

Toutes les déclarations suivantes peuvent être fausses pour une version QUIC donnée :

  • QUIC utilise TLS [QUIC-TLS], et certains messages TLS sont visibles sur le fil.

  • Les en-têtes longs QUIC sont échangés uniquement pendant l'établissement de la connexion.

  • Chaque flux sur un 5-tuple donné inclura une phase d'établissement de connexion.

  • Les premiers paquets échangés sur un flux utilisent l'en-tête long.

  • Le dernier paquet avant une longue période de silence peut être supposé ne contenir qu'un accusé de réception (Acknowledgment).

  • QUIC utilise une fonction de chiffrement authentifié avec données associées (AEAD) (AEAD_AES_128_GCM ; voir [RFC5116]) pour protéger les paquets qu'il échange pendant l'établissement de la connexion.

  • Les numéros de paquet QUIC (Packet Numbers) sont chiffrés et apparaissent comme les premiers octets chiffrés.

  • Les numéros de paquet QUIC augmentent de un pour chaque paquet envoyé.

  • QUIC a une taille minimale pour le premier paquet de poignée de main envoyé par un client.

  • QUIC stipule qu'un client parle en premier.

  • Les paquets QUIC ont toujours le deuxième bit du premier octet (0x40) défini.

  • Un paquet de négociation de version QUIC est uniquement envoyé par un serveur.

  • Un ID de connexion QUIC change rarement.

  • Les points de terminaison QUIC changent la version qu'ils utilisent s'ils reçoivent un paquet de négociation de version.

  • Le champ Version dans un en-tête long QUIC est le même dans les deux directions.

  • Un paquet QUIC avec une valeur particulière dans le champ Version signifie que la version correspondante de QUIC est utilisée.

  • Une seule connexion à la fois est établie entre une paire de points de terminaison QUIC.