Zum Hauptinhalt springen

RFC 9221 - Eine unzuverlässige Datagramm-Erweiterung für QUIC

  • Status: Proposed Standard
  • Veröffentlicht: March 2022
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Dokument definiert eine Erweiterung des QUIC-Transportprotokolls zur Unterstützung des Sendens und Empfangens unzuverlässiger Datagramme über eine QUIC-Verbindung.

Status dieses Memos​

Dies ist ein Internet-Standards-Track-Dokument.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Gemeinschaft. Es wurde öffentlich geprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung freigegeben. Weitere Informationen zu Internet Standards finden sich in Section 2 von RFC 7841.

Informationen zum aktuellen Status dieses Dokuments sind unter https://www.rfc-editor.org/info/rfc9221 verfügbar.

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

Dieses Dokument unterliegt BCP 78 und den Legal Provisions des IETF Trust zu IETF-Dokumenten (https://trustee.ietf.org/license-info). Aus diesem Dokument extrahierte Codekomponenten müssen den Text der Revised BSD License gemäß Section 4.e der Trust Legal Provisions enthalten.

Inhaltsverzeichnis​

    1. Einleitung
    1. Motivation
    1. Transportparameter
    1. Datagramm-Frame-Typen
    1. Verhalten und Nutzung
    1. Sicherheitsbetrachtungen
    1. IANA-Erwägungen
    1. Referenzen
  • Danksagungen
  • Adressen der Autoren

1. Einleitung​

Das QUIC-Transportprotokoll [RFC9000] stellt eine sichere, multiplexte Verbindung zur Übertragung zuverlässiger Ströme von Anwendungsdaten bereit. QUIC verwendet verschiedene Frame-Typen zur Übertragung von Daten in Paketen, und jeder Frame-Typ definiert, ob die enthaltenen Daten retransmittiert werden. Ströme zuverlässiger Anwendungsdaten werden mit STREAM-Frames gesendet.

Einige Anwendungen, insbesondere solche, die Echtzeitdaten übertragen müssen, bevorzugen die unzuverlässige Übertragung von Daten. In der Vergangenheit haben diese Anwendungen oft direkt auf UDP [RFC0768] als Transport aufgebaut und häufig Sicherheit mit DTLS [RFC6347] hinzugefügt. Die Erweiterung von QUIC zur Unterstützung 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.

Dieses Dokument definiert zwei neue DATAGRAM-QUIC-Frame-Typen, die Anwendungsdaten ohne erforderliche Retransmissionen tragen.

1.1. Spezifikation der Anforderungen​

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, und zwar nur, wenn sie in Großbuchstaben erscheinen.

2. Motivation​

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

  • Anwendungen, die sowohl einen zuverlässigen Strom als auch einen unzuverlässigen Fluss zum selben Peer nutzen wollen, können von der gemeinsamen Nutzung eines einzigen Handshake- und Authentifizierungskontexts zwischen einem zuverlässigen QUIC-Strom und einem Fluss unzuverlässiger QUIC-Datagramme profitieren. Dies kann die für Handshakes erforderliche Latenz im Vergleich zum Öffnen sowohl einer TLS- als auch einer DTLS-Verbindung verringern.
  • QUIC verwendet einen nuancierteren Verlustwiederherstellungsmechanismus als der DTLS-Handshake. Dies kann eine schnellere Verlustwiederherstellung für QUIC-Daten ermöglichen.
  • QUIC-Datagramme unterliegen der QUIC-Staukontrolle. Eine einzige Staukontrolle für zuverlässige und unzuverlässige Daten kann effektiver und effizienter sein.

Diese Funktionen können zur Optimierung von Audio-/Video-Streaming-, Gaming- und anderen Echtzeit-Netzwerkanwendungen nützlich sein.

Unzuverlässige QUIC-Datagramme können auch verwendet werden, um einen IP-Pakettunnel über QUIC zu implementieren, z. B. für ein Virtual Private Network (VPN). Tunnelprotokolle der Internetschicht erfordern im Allgemeinen einen zuverlässigen und authentifizierten Handshake, gefolgt von unzuverlässiger sicherer Kommunikation.

3. Transportparameter​

Dieses Dokument definiert einen neuen Transportparameter, max_datagram_frame_size (Wert 0x20). Dieser Parameter stellt die maximale Größe eines DATAGRAM-Frames (einschließlich Frame-Typ, Länge und Nutzlast) dar, die der Endpunkt empfangen möchte, in Bytes.

4. Datagramm-Frame-Typen​

Dieses Dokument definiert zwei neue Frame-Typen:

  • DATAGRAM (0x30): Ein DATAGRAM-Frame mit Anwendungsdaten. Der Frame enthält kein Längenfeld; die Daten erstrecken sich bis zum Ende des Pakets.
  • DATAGRAM_WITH_LEN (0x31): Ein DATAGRAM-Frame mit Anwendungsdaten. Der Frame enthält ein Längenfeld.

5. Verhalten und Nutzung​

5.1. Multiplexen von Datagrammen​

DATAGRAM-Frames werden mit anderen QUIC-Frames in QUIC-Paketen gemultiplex.

5.2. Behandlung von Bestätigungen​

Obwohl DATAGRAM-Frames bei Verlust nicht retransmittiert werden, werden sie bestätigt. Dies ermöglicht dem Sender, den Staukontrollzustand zu pflegen und möglicherweise Statistiken über die Zustellung zu sammeln.

5.3. Flusskontrolle​

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

5.4. Staukontrolle​

DATAGRAM-Frames unterliegen der Staukontrolle. Der Sender MUST die Grenzen des Staucontrollers beim Senden von DATAGRAM-Frames einhalten.

6. Sicherheitsbetrachtungen​

Die Sicherheitsbetrachtungen für dieses Dokument ähneln denen für QUIC [RFC9000]. Die Verwendung unzuverlässiger Datagramme führt zu zusätzlichen Überlegungen, z. B. dem Potenzial für Amplification-Angriffe, wenn die Datagramme zur Reflexion von Verkehr verwendet werden.

7. IANA-Erwägungen​

7.1. QUIC-Transportparameter​

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

Dieses Dokument registriert zwei neue Werte im Register „QUIC Frame Types“:

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

8. Referenzen​

8.1. Normative Referenzen​

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

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

Danksagungen​

Die Autoren danken...

Adressen der Autoren​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]