Zum Hauptinhalt springen

RFC 9221 - An Unreliable Datagram Extension to QUIC

  • Status: Proposed Standard
  • Veröffentlicht: March 2022
  • Stream: IETF
  • Errata: Keine 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.

Dieses Dokument definiert eine Erweiterung des QUIC-Transportprotokolls, um Unterstützung für das Senden und Empfangen von unzuverlässigen Datagrammen über eine QUIC-Verbindung hinzuzufügen.

Status of This Memo

This is an Internet Standards Track document.

Dies ist ein Internet Standards Track-Dokument.

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.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es stellt den Konsens der IETF-Community dar. Es wurde öffentlich überprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung freigegeben. Weitere Informationen zu Internetstandards finden Sie in Abschnitt 2 von 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.

Informationen zum aktuellen Status dieses Dokuments, zu etwaigen Errata und zur Abgabe von Feedback finden Sie unter 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 und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

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.

Dieses Dokument unterliegt BCP 78 und den gesetzlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (https://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments gelten. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Aus diesem Dokument extrahierte Codekomponenten müssen den überarbeiteten BSD-Lizenztext enthalten, wie in Abschnitt 4.e der gesetzlichen Bestimmungen des Trust beschrieben, und werden ohne Gewährleistung bereitgestellt, wie in der überarbeiteten BSD-Lizenz beschrieben.

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.

Das QUIC-Transportprotokoll [RFC9000] bietet eine sichere, gemultiplexte Verbindung zur Übertragung zuverlässiger Ströme von Anwendungsdaten. QUIC verwendet verschiedene Rahmentypen, um Daten innerhalb von Paketen zu übertragen, und jeder Rahmentyp definiert, ob die darin enthaltenen Daten erneut übertragen werden. Ströme zuverlässiger Anwendungsdaten werden mithilfe von STREAM-Rahmen gesendet.

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.

Einige Anwendungen, insbesondere solche, die Echtzeitdaten übertragen müssen, ziehen es vor, Daten unzuverlässig zu übertragen. In der Vergangenheit bauten diese Anwendungen direkt auf UDP [RFC0768] als Transport auf und fügten häufig Sicherheit mit DTLS [RFC6347] hinzu. Die Erweiterung von QUIC zur Unterstützung der Übertragung unzuverlässiger Anwendungsdaten bietet eine weitere Option für sichere Datagramme mit dem zusätzlichen Vorteil, den kryptografischen und Authentifizierungskontext zu teilen, der für zuverlässige Ströme verwendet wird.

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

Dieses Dokument definiert zwei neue DATAGRAM QUIC-Rahmentypen, die Anwendungsdaten übertragen, ohne dass Neuübertragungen erforderlich sind.

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.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

2. Motivation

Transmitting unreliable data over QUIC provides benefits over existing solutions:

Die Übertragung unzuverlässiger Daten über QUIC bietet Vorteile gegenüber bestehenden Lösungen:

  • 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.
  • Anwendungen, die sowohl einen zuverlässigen Strom als auch einen unzuverlässigen Fluss zum selben Peer verwenden möchten, können davon profitieren, dass sie einen einzigen Handshake- und Authentifizierungskontext zwischen einem zuverlässigen QUIC-Strom und einem Fluss unzuverlässiger QUIC-Datagramme teilen. Dies kann die für Handshakes erforderliche Latenz im Vergleich zum Öffnen sowohl einer TLS-Verbindung als auch einer DTLS-Verbindung reduzieren.
  • 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 verwendet einen nuancierteren Verlustwiederherstellungsmechanismus als der DTLS-Handshake. Dies kann dazu führen, dass die Verlustwiederherstellung für QUIC-Daten schneller erfolgt.
  • 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.
  • QUIC-Datagramme unterliegen der QUIC-Überlastungskontrolle. Die Bereitstellung einer einzigen Überlastungskontrolle sowohl für zuverlässige als auch für unzuverlässige Daten kann effektiver und effizienter sein.

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

Diese Funktionen können nützlich sein, um Audio-/Video-Streaming-Anwendungen, Spieleanwendungen und andere Echtzeit-Netzwerkanwendungen zu optimieren.

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.

Unzuverlässige QUIC-Datagramme können auch verwendet werden, um einen IP-Pakettunnel über QUIC zu implementieren, beispielsweise für ein virtuelles privates Netzwerk (VPN). Tunneling-Protokolle auf Internetschicht erfordern im Allgemeinen einen zuverlässigen und authentifizierten Handshake, gefolgt von einer unzuverlässigen sicheren Kommunikation.

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.

Dieses Dokument definiert einen neuen Transportparameter, max_datagram_frame_size (Wert 0x20). Dieser Parameter stellt die maximale Größe eines DATAGRAM-Rahmens (einschließlich Rahmentyp, Länge und Nutzlast) dar, die der Endpunkt bereit ist zu empfangen, in Bytes.

4. Datagram Frame Types

This document defines two new frame types:

Dieses Dokument definiert zwei neue Rahmentypen:

  • 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): Ein DATAGRAM-Rahmen, der Anwendungsdaten enthält. Der Rahmen enthält kein Längenfeld; die Daten erstrecken sich bis zum Ende des Pakets.
  • DATAGRAM_WITH_LEN (0x31): A DATAGRAM frame containing application data. The frame contains a length field.
  • DATAGRAM_WITH_LEN (0x31): Ein DATAGRAM-Rahmen, der Anwendungsdaten enthält. Der Rahmen enthält ein Längenfeld.

5. Behavior and Usage

5.1. Multiplexing Datagrams

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

DATAGRAM-Rahmen werden mit anderen QUIC-Rahmen innerhalb von QUIC-Paketen gemultiplext.

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.

Obwohl DATAGRAM-Rahmen bei Verlust nicht erneut übertragen werden, werden sie bestätigt. Dies ermöglicht es dem Absender, den Überlastungskontrollstatus aufrechtzuerhalten und möglicherweise Statistiken über die Zustellung zu sammeln.

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.

DATAGRAM-Rahmen unterliegen keiner Flusskontrolle. Der Transportparameter max_datagram_frame_size begrenzt die Größe einzelner Rahmen, es gibt jedoch keine Begrenzung für die Gesamtzahl der Bytes oder Rahmen.

5.4. Congestion Control

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

DATAGRAM-Rahmen unterliegen der Überlastungskontrolle. Der Absender MUSS beim Senden von DATAGRAM-Rahmen die Grenzen des Überlastungscontrollers einhalten.

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.

Die Sicherheitsüberlegungen für dieses Dokument ähneln denen für QUIC [RFC9000]. Die Verwendung unzuverlässiger Datagramme führt einige zusätzliche Überlegungen ein, wie z. B. das Potenzial für Verstärkungsangriffe, wenn die Datagramme verwendet werden, um Verkehr zu reflektieren.

7. IANA Considerations

7.1. QUIC Transport Parameter

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

Dieses Dokument registriert einen neuen Wert im Register "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:

Dieses Dokument registriert zwei neue Werte im Register "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...

Die Autoren möchten danken...

Authors' Addresses

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]