Zum Hauptinhalt springen

RFC 8999 - Versionsunabhängige Eigenschaften von QUIC

  • Status: Proposed Standard
  • Veröffentlicht: May 2021
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Dokument definiert die Eigenschaften des QUIC-Transportprotokolls (QUIC Transport Protocol), die allen Versionen des Protokolls gemeinsam sind.

Inhaltsverzeichnis (Table of Contents)​

1. Eine äußerst abstrakte Beschreibung von QUIC (An Extremely Abstract Description of QUIC)​

QUIC ist ein verbindungsorientiertes Protokoll (Connection-Oriented Protocol) zwischen zwei Endpunkten (Endpoints). Diese Endpunkte tauschen UDP-Datagramme (UDP Datagrams) aus. Diese UDP-Datagramme enthalten QUIC-Pakete (QUIC Packets). QUIC-Endpunkte verwenden QUIC-Pakete, um eine QUIC-Verbindung (QUIC Connection) herzustellen, bei der es sich um einen gemeinsamen Protokollzustand (Shared Protocol State) zwischen diesen Endpunkten handelt.

2. Feste Eigenschaften aller QUIC-Versionen (Fixed Properties of All QUIC Versions)​

Zusätzlich zur Bereitstellung eines sicheren, gemultiplexten Transports (Secure, Multiplexed Transport) ermöglicht QUIC [QUIC-TRANSPORT] die Option, eine Version auszuhandeln. Dies ermöglicht es dem Protokoll, sich im Laufe der Zeit als Reaktion auf neue Anforderungen zu ändern. Viele Eigenschaften des Protokolls könnten sich zwischen den Versionen ändern.

Dieses Dokument beschreibt die Teilmenge von QUIC, die beim Entwickeln und Bereitstellen neuer Versionen stabil bleiben soll. Alle diese Invarianten (Invariants) sind unabhängig von der IP-Version.

Das Hauptziel dieses Dokuments ist es sicherzustellen, dass neue Versionen von QUIC bereitgestellt werden können. Durch die Dokumentation der Eigenschaften, die sich nicht ändern können, zielt dieses Dokument darauf ab, die Fähigkeit der QUIC-Endpunkte zu bewahren, Änderungen in jedem anderen Aspekt des Protokolls auszuhandeln. Folglich garantiert dies auch eine minimale Menge an Informationen, die Entitäten außer Endpunkten zur Verfügung gestellt wird. Sofern nicht ausdrücklich in diesem Dokument verboten, kann sich jeder Aspekt des Protokolls zwischen verschiedenen Versionen ändern.

Anhang A enthält eine nicht erschöpfende Liste einiger falscher Annahmen, die auf der Grundlage der Kenntnis von QUIC Version 1 gemacht werden könnten; diese gelten nicht für alle Versionen von QUIC.

3. Konventionen und Definitionen (Conventions and Definitions)​

Die Schlüsselwörter "MUST" (muss), "MUST NOT" (darf nicht), "REQUIRED" (erforderlich), "SHALL" (muss), "SHALL NOT" (darf nicht), "SHOULD" (sollte), "SHOULD NOT" (sollte nicht), "RECOMMENDED" (empfohlen), "NOT RECOMMENDED" (nicht empfohlen), "MAY" (kann) und "OPTIONAL" (optional) in diesem Dokument sind gemäß BCP 14 [RFC2119] [RFC8174] zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Dieses Dokument definiert Anforderungen an zukünftige QUIC-Versionen, auch wenn keine normative Sprache verwendet wird.

Dieses Dokument verwendet Begriffe und Notationskonventionen aus [QUIC-TRANSPORT].

4. Notationskonventionen (Notational Conventions)​

Das Format von Paketen wird unter Verwendung der in diesem Abschnitt definierten Notation beschrieben. Diese Notation ist dieselbe wie in [QUIC-TRANSPORT] verwendet.

Komplexe Felder werden benannt und dann von einer Liste von Feldern gefolgt, die von einem Paar übereinstimmender geschweifter Klammern umgeben sind. Jedes Feld in dieser Liste ist durch Kommas getrennt.

Einzelne Felder enthalten Längeninformationen sowie Angaben über feste Werte, Optionalität oder Wiederholungen. Einzelne Felder verwenden die folgenden Notationskonventionen, wobei alle Längen in Bits angegeben sind:

x (A): gibt an, dass x A Bits lang ist

x (A..B): gibt an, dass x eine beliebige Länge von A bis B haben kann; A kann weggelassen werden, um ein Minimum von null Bits anzuzeigen, und B kann weggelassen werden, um keine festgelegte Obergrenze anzuzeigen; Werte in diesem Format enden immer an einer Bytegrenze

x (L) = C: gibt an, dass x einen festen Wert von C hat; die Länge von x wird durch L beschrieben, das eine der oben genannten Längenformen verwenden kann

x (L) ...: gibt an, dass x null- oder mehrmals wiederholt wird und dass jede Instanz eine Länge von L hat

Dieses Dokument verwendet Netzwerk-Byte-Reihenfolge (Network Byte Order, d. h. Big Endian) Werte. Felder werden beginnend mit den höchstwertigen Bits jedes Bytes platziert.

Abbildung 1 zeigt eine Beispielstruktur:

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) ...,
}

Abbildung 1: Beispielformat

5. QUIC-Pakete (QUIC Packets)​

QUIC-Endpunkte tauschen UDP-Datagramme aus, die ein oder mehrere QUIC-Pakete enthalten. Dieser Abschnitt beschreibt die invarianten Eigenschaften eines QUIC-Pakets.

QUIC definiert zwei Arten von Paket-Headern: lange und kurze Header. Pakete mit einem langen Header werden durch das höchstwertige Bit (Most Significant Bit) des ersten Bytes identifiziert, das auf 1 gesetzt ist; Pakete mit einem kurzen Header haben dieses Bit gelöscht.

5.1 Langer Header (Long Header)​

Lange Header haben die in Abbildung 2 beschriebene Form.

5.2 Kurzer Header (Short Header)​

Kurze Header haben die in Abbildung 3 beschriebene Form.

5.3 Verbindungs-ID (Connection ID)​

Eine Verbindungs-ID (Connection ID) ist ein undurchsichtiges Feld (Opaque Field) beliebiger Länge.

5.4 Version​

Das Versionsfeld (Version Field) enthält einen 4-Byte-Identifikator.

6. Versionsverhandlung (Version Negotiation)​

Ein QUIC-Endpunkt, der ein Paket mit einem langen Header und einer Version erhält, die er entweder nicht versteht oder nicht unterstützt, kann als Antwort ein Versionsverhandlungspaket (Version Negotiation Packet) senden. Pakete mit einem kurzen Header lösen keine Versionsverhandlung aus.

7. Sicherheits- und Datenschutzüberlegungen (Security and Privacy Considerations)​

Es ist möglich, dass Middleboxes Merkmale einer bestimmten Version von QUIC beobachten und annehmen, dass wenn andere Versionen von QUIC ähnliche Merkmale aufweisen, dieselbe zugrunde liegende Semantik ausgedrückt wird.

8. Referenzen (References)​

8.1 Normative Referenzen (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.

Anhang A. Falsche Annahmen (Incorrect Assumptions)​

Es gibt mehrere Merkmale von QUIC Version 1 [QUIC-TRANSPORT], die nicht vor Beobachtung geschützt sind, aber dennoch als änderbar betrachtet werden, wenn eine neue Version bereitgestellt wird.

Jede der folgenden Aussagen kann für eine gegebene QUIC-Version falsch sein:

  • QUIC verwendet TLS [QUIC-TLS], und einige TLS-Nachrichten sind auf dem Draht sichtbar.
  • QUIC-Langheader werden nur während der Verbindungsherstellung ausgetauscht.
  • Ein QUIC-Verbindungs-ID ändert sich selten.