Aller au contenu principal

RFC 9221 - Extension de datagrammes non fiables pour QUIC

  • Statut: Proposed Standard
  • Publication: March 2022
  • Stream: IETF
  • Errata: Aucune errata

Résumé (Abstract)​

Le présent document définit une extension au protocole de transport QUIC pour ajouter la prise en charge de l'envoi et de la réception de datagrammes non fiables sur une connexion QUIC.

État de ce mémo​

Il s'agit d'un document de la série Internet Standards Track.

Ce 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). Des informations supplémentaires sur les Internet Standards sont disponibles dans la Section 2 du RFC 7841.

Des informations sur l'état actuel de ce document, toute errata et la façon de fournir des retours sont disponibles à https://www.rfc-editor.org/info/rfc9221.

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

Ce document est soumis au 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 de ce document. Veuillez examiner attentivement ces documents. Les composants de code extraits de ce document doivent inclure le texte de la Revised BSD License décrit à la Section 4.e des Trust Legal Provisions et sont fournis sans garantie.

Table des matières​

    1. Introduction
    1. Motivation
    1. Paramètre de transport
    1. Types de trames Datagram
    1. Comportement et usage
    1. Considérations de sécurité
    1. Considérations IANA
    1. Références
  • Remerciements
  • Adresses des auteurs

1. Introduction​

Le protocole de transport QUIC [RFC9000] fournit une connexion sécurisée et multiplexée pour transmettre des flux fiables de données d'application. QUIC utilise divers types de trames pour transmettre des données dans des paquets, et chaque type de trame définit si les données qu'il contient seront retransmises. Les flux de données d'application fiables sont envoyés à l'aide de trames STREAM.

Certaines applications, en particulier celles qui doivent transmettre des données en temps réel, préfèrent transmettre des données de façon non fiable. Par le passé, ces applications se sont construites directement sur UDP [RFC0768] comme transport et ont souvent ajouté la sécurité avec DTLS [RFC6347]. Étendre QUIC pour prendre en charge la transmission de données d'application non fiables fournit une autre option pour des datagrammes sécurisés, avec l'avantage supplémentaire de partager le contexte cryptographique et d'authentification utilisé pour les flux fiables.

Le présent document définit deux nouveaux types de trames DATAGRAM QUIC qui transportent des données d'application sans exiger de retransmissions.

1.1. Spécification des exigences​

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsqu'ils apparaissent en majuscules, et uniquement dans ce cas.

2. Motivation​

Transmettre des données non fiables sur QUIC apporte des avantages par rapport aux solutions existantes:

  • Les applications qui souhaitent utiliser à la fois un flux fiable et un flux non fiable vers le même pair peuvent bénéficier du partage d'une seule poignée de main et d'un seul contexte d'authentification entre un flux QUIC fiable et un flux de datagrammes QUIC non fiables. Cela peut réduire la latence des poignées de main par rapport à l'ouverture d'une connexion TLS et d'une connexion DTLS.
  • QUIC utilise un mécanisme de récupération de pertes plus nuancé que la poignée de main DTLS. Cela peut permettre une récupération de pertes plus rapide pour les données QUIC.
  • Les datagrammes QUIC sont soumis au contrôle de congestion QUIC. Fournir un seul contrôle de congestion pour les données fiables et non fiables peut être plus efficace.

Ces fonctionnalités peuvent être utiles pour optimiser les applications de diffusion audio/vidéo, les applications de jeu et d'autres applications réseau en temps réel.

Les datagrammes QUIC non fiables peuvent aussi être utilisés pour implémenter un tunnel de paquets IP sur QUIC, par exemple pour un réseau privé virtuel (VPN). Les protocoles de tunnelisation de couche Internet exigent généralement une poignée de main fiable et authentifiée suivie d'une communication sécurisée non fiable.

3. Paramètre de transport​

Le présent document définit un nouveau paramètre de transport, max_datagram_frame_size (valeur 0x20). Ce paramètre représente la taille maximale d'une trame DATAGRAM (y compris le type de trame, la longueur et la charge utile) que l'extrémité est disposée à recevoir, en octets.

4. Types de trames Datagram​

Le présent document définit deux nouveaux types de trames:

  • DATAGRAM (0x30): Une trame DATAGRAM contenant des données d'application. La trame ne contient pas de champ de longueur; les données s'étendent jusqu'à la fin du paquet.
  • DATAGRAM_WITH_LEN (0x31): Une trame DATAGRAM contenant des données d'application. La trame contient un champ de longueur.

5. Comportement et usage​

5.1. Multiplexage des datagrammes​

Les trames DATAGRAM sont multiplexées avec d'autres trames QUIC dans les paquets QUIC.

5.2. Gestion des accusés de réception​

Bien que les trames DATAGRAM ne soient pas retransmises en cas de perte, elles sont acquittées. Cela permet à l'émetteur de maintenir l'état du contrôle de congestion et éventuellement de recueillir des statistiques sur la livraison.

5.3. Contrôle de flux​

Les trames DATAGRAM ne sont pas soumises au contrôle de flux. Le paramètre de transport max_datagram_frame_size limite la taille des trames individuelles, mais il n'y a pas de limite sur le nombre total d'octets ou de trames.

5.4. Contrôle de congestion​

Les trames DATAGRAM sont soumises au contrôle de congestion. L'émetteur MUST respecter les limites du contrôleur de congestion lors de l'envoi de trames DATAGRAM.

6. Considérations de sécurité​

Les considérations de sécurité pour ce document sont similaires à celles de QUIC [RFC9000]. L'utilisation de datagrammes non fiables introduit des considérations supplémentaires, telles que le potentiel d'attaques par amplification si les datagrammes sont utilisés pour réfléchir du trafic.

7. Considérations IANA​

7.1. Paramètre de transport QUIC​

Le présent document enregistre une nouvelle valeur dans le registre « QUIC Transport Parameters »:

  • Value: 0x20
  • Parameter Name: max_datagram_frame_size
  • Status: permanent
  • Specification: RFC 9221

7.2. Types de trames QUIC​

Le présent document enregistre deux nouvelles valeurs dans le registre « QUIC Frame Types »:

  • Value: 0x30-0x31
  • Frame Name: DATAGRAM
  • Status: permanent
  • Specification: RFC 9221

8. Références​

8.1. Références normatives​

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

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

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

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc0768.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, https://www.rfc-editor.org/info/rfc6347.

Remerciements​

Les auteurs tiennent à remercier...

Adresses des auteurs​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]