Aller au contenu principal

RFC 9221 - An Unreliable Datagram Extension to QUIC

  • Statut: Proposed Standard
  • Publié: March 2022
  • Stream: IETF
  • Errata: Pas d'errata

Abstract​

This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.

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

Status of This Memo​

This is an Internet Standards Track document.

Ceci est un document de la voie de normalisation de l'Internet (Standards Track).

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

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). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9221.

Des informations sur l'état actuel de ce document, les éventuels errata et la manière de fournir des commentaires à son sujet peuvent être obtenues à l'adresse https://www.rfc-editor.org/info/rfc9221.

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

Copyright (c) 2022 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Ce document est soumis aux dispositions légales du BCP 78 et 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, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de licence BSD révisée tel que décrit dans la section 4.e des dispositions légales du Trust et sont fournis sans garantie telle que décrite dans la licence BSD révisée.

Table of Contents​

    1. Introduction
    1. Motivation
    1. Transport Parameter
    1. Datagram Frame Types
    1. Behavior and Usage
    1. Security Considerations
    1. IANA Considerations
    1. References
  • Acknowledgments
  • Authors' Addresses

1. Introduction​

The QUIC transport protocol [RFC9000] provides a secure, multiplexed connection for transmitting reliable streams of application data. QUIC uses various frame types to transmit data within packets, and each frame type defines whether the data it contains will be retransmitted. Streams of reliable application data are sent using STREAM frames.

Le protocole de transport QUIC [RFC9000] fournit une connexion sécurisée et multiplexée pour la transmission de 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'elle contient seront retransmises. Les flux de données d'application fiables sont envoyés à l'aide de trames STREAM.

Some applications, particularly those that need to transmit real-time data, prefer to transmit data unreliably. In the past, these applications have built directly upon UDP [RFC0768] as a transport and have often added security with DTLS [RFC6347]. Extending QUIC to support transmitting unreliable application data provides another option for secure datagrams with the added benefit of sharing the cryptographic and authentication context used for reliable streams.

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

This document defines two new DATAGRAM QUIC frame types that carry application data without requiring retransmissions.

Ce document définit deux nouveaux types de trames DATAGRAM QUIC qui transportent des données d'application sans nécessiter de retransmissions.

1.1. Specification of Requirements​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

2. Motivation​

Transmitting unreliable data over QUIC provides benefits over existing solutions:

La transmission de données non fiables sur QUIC offre des avantages par rapport aux solutions existantes :

  • Applications that want to use both a reliable stream and an unreliable flow to the same peer can benefit by sharing a single handshake and authentication context between a reliable QUIC stream and a flow of unreliable QUIC datagrams. This can reduce the latency required for handshakes compared to opening both a TLS connection and a DTLS connection.
  • 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'un contexte de poignée de main et d'authentification unique entre un flux QUIC fiable et un flux de datagrammes QUIC non fiables. Cela peut réduire la latence requise pour les poignées de main par rapport à l'ouverture à la fois d'une connexion TLS et d'une connexion DTLS.
  • QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake. This can allow loss recovery to occur more quickly for QUIC data.
  • QUIC utilise un mécanisme de récupération de perte plus nuancé que la poignée de main DTLS. Cela peut permettre une récupération de perte plus rapide pour les données QUIC.
  • QUIC datagrams are subject to QUIC congestion control. Providing a single congestion control for both reliable and unreliable data can be more effective and efficient.
  • Les datagrammes QUIC sont soumis au contrôle de congestion QUIC. Fournir un contrôle de congestion unique pour les données fiables et non fiables peut être plus efficace et efficient.

These features can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications.

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

Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN). Internet-layer tunneling protocols generally require a reliable and authenticated handshake followed by unreliable secure communication.

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

3. Transport Parameter​

This document defines a new transport parameter, max_datagram_frame_size (value 0x20). This parameter represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) that the endpoint is willing to receive, in bytes.

Ce 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 le point de terminaison est prêt à recevoir, en octets.

4. Datagram Frame Types​

This document defines two new frame types:

Ce document définit deux nouveaux types de trames :

  • DATAGRAM (0x30): A DATAGRAM frame containing application data. The frame does not contain a length field; the data extends to the end of the packet.
  • 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): A DATAGRAM frame containing application data. The frame contains a length field.
  • DATAGRAM_WITH_LEN (0x31) : Une trame DATAGRAM contenant des données d'application. La trame contient un champ de longueur.

5. Behavior and Usage​

5.1. Multiplexing Datagrams​

DATAGRAM frames are multiplexed with other QUIC frames within QUIC packets.

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

5.2. Acknowledgement Handling​

Although DATAGRAM frames are not retransmitted upon loss, they are acknowledged. This allows the sender to maintain congestion control state and potentially gather statistics about delivery.

Bien que les trames DATAGRAM ne soient pas retransmises en cas de perte, elles font l'objet d'un accusé de réception. Cela permet à l'expéditeur de maintenir l'état du contrôle de congestion et éventuellement de collecter des statistiques sur la livraison.

5.3. Flow Control​

DATAGRAM frames are not subject to flow control. The max_datagram_frame_size transport parameter limits the size of individual frames, but there is no limit on the total number of bytes or frames.

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. Congestion Control​

DATAGRAM frames are congestion controlled. The sender MUST respect the congestion controller's limits when sending DATAGRAM frames.

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

6. Security Considerations​

The security considerations for this document are similar to those for QUIC [RFC9000]. The use of unreliable datagrams introduces some additional considerations, such as the potential for amplification attacks if the datagrams are used to reflect traffic.

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

7. IANA Considerations​

7.1. QUIC Transport Parameter​

This document registers a new value in the "QUIC Transport Parameters" registry:

Ce 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. QUIC Frame Types​

This document registers two new values in the "QUIC Frame Types" registry:

Ce document enregistre deux nouvelles valeurs dans le registre "QUIC Frame Types" :

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

8. References​

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

[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. Informative References​

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

Acknowledgements​

The authors would like to thank...

Les auteurs tiennent à remercier...

Authors' Addresses​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]

Dernière mise à jour le