Zum Hauptinhalt springen

RFC 9287 - Greasing des QUIC-Bits (Greasing the QUIC Bit)

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

Zusammenfassung (Abstract)​

Dieses Dokument beschreibt ein Verfahren zur Aushandlung der Fähigkeit, für das zweitwichtigste Bit in QUIC-Paketen einen beliebigen Wert zu senden.

Status dieses Memos (Status of This Memo)​

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, zu Errata und dazu, wie Feedback gegeben werden kann, sind unter https://www.rfc-editor.org/info/rfc9287 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), die zum Veröffentlichungsdatum dieses Dokuments gelten. Bitte prüfen Sie diese Dokumente sorgfältig, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Aus diesem Dokument extrahierte Codekomponenten müssen den Text der Revised BSD License gemäß Section 4.e der Trust Legal Provisions enthalten und werden ohne Gewährleistung bereitgestellt, wie in der Revised BSD License beschrieben.

Inhaltsverzeichnis (Table of Contents)​

    1. Einleitung
    1. Konventionen und Definitionen
    1. Transportparameter Grease QUIC Bit
    1. Sicherheitsbetrachtungen
    1. IANA-Erwägungen
    1. Referenzen
  • Adresse des Autors

1. Einleitung​

Die versionsunabhängige Definition von QUIC [QUIC-INVARIANTS] beschreibt absichtlich eine sehr enge Menge von Feldern, die für andere Entitäten als Endpunkte sichtbar sind. Jenseits dieser invarianten Merkmale ist sehr wenig vom „Wire Image“ [RFC8546] von QUIC sichtbar.

Das zweitwichtigste Bit des ersten Bytes jedes QUIC-Pakets ist in QUIC Version 1 [QUIC] mit einem festen Wert definiert. Der Zweck eines festen Werts ist es, Endpunkten die effiziente Unterscheidung von QUIC von anderen Protokollen zu ermöglichen; siehe [DEMUX] für die Beschreibung eines Systems, das diese Eigenschaft nutzen könnte. Da dieses Bit ein Paket als QUIC identifizieren kann, wird es manchmal als „QUIC-Bit“ (QUIC Bit) bezeichnet.

Wenn Endpunkte und die sie unterstützenden Intermediäre nicht vom festen Wert des QUIC-Bits abhängen, ist das Senden desselben Werts in jedem Paket eher eine Belastung als ein Vorteil. Wenn Systeme von einem festen Wert abhängig werden, könnte es unpraktikabel werden, eine QUIC-Version zu definieren, die diesem Bit eine Semantik zuweist.

Um die künftige Nutzung dieses Bits zu sichern, definiert dieses Dokument einen QUIC-Transportparameter, der anzeigt, dass ein Endpunkt bereit ist, QUIC-Pakete mit einem beliebigen Wert für dieses Bit zu empfangen. Durch das Senden unterschiedlicher Werte für dieses Bit soll der Wert für künftige Nutzung verfügbar bleiben [USE-IT].

2. Konventionen und Definitionen​

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.

Dieses Dokument verwendet Begriffe und Notationskonventionen aus [QUIC].

3. Transportparameter Grease QUIC Bit​

Der Transportparameter grease_quic_bit (0x2ab2) ist für QUIC Version 1 [QUIC] definiert. Dieser Transportparameter kann sowohl vom Client als auch vom Server gesendet werden. Er wird mit leerem Wert gesendet; ein Endpunkt, der diesen Transportparameter versteht, MUST den Empfang eines nicht leeren Werts als Verbindungsfehler vom Typ TRANSPORT_PARAMETER_ERROR behandeln.

Ein Endpunkt, der den Transportparameter grease_quic_bit ankündigt, MUST Pakete mit dem QUIC-Bit auf den Wert 0 akzeptieren. Das QUIC-Bit ist als das zweitwichtigste Bit des ersten Bytes von QUIC-Paketen definiert (also der Wert 0x40).

3.1. Löschen des QUIC-Bits​

Endpunkte, die den Transportparameter grease_quic_bit von einem Peer empfangen, SHOULD das QUIC-Bit auf einen unvorhersagbaren Wert setzen, sofern nicht eine andere Erweiterung dem Wert des Bits eine spezifische Bedeutung zuweist.

Endpunkte können das QUIC-Bit auf 0 setzen bei allen Paketen, die nach Empfang und Verarbeitung der Transportparameter gesendet werden. Dies kann Initial-, Handshake- und Retry-Pakete umfassen.

Ein Client MAY das QUIC-Bit auch in Initial-, Handshake- oder 0-RTT-Paketen auf 0 setzen, die vor dem Empfang der Transportparameter vom Server gesendet werden. Ein Client MUST NOT jedoch das QUIC-Bit auf 0 setzen, wenn er auch ein Token sendet, das in einem Retry-Paket oder in einem NEW_TOKEN-Frame (Section 19.7 von [QUIC]) bereitgestellt wurde.

3.2. Verwendung des QUIC-Bits​

Dieses Dokument beschreibt eine Nutzung des QUIC-Bits, die mit der Definition in [QUIC] kompatibel ist.

4. Sicherheitsbetrachtungen​

Das Greasing des QUIC-Bits soll die künftige Nutzung des Bits absichern. Es stellt keine Sicherheitseigenschaften bereit.

5. IANA-Erwägungen​

Dieses Dokument registriert den Transportparameter grease_quic_bit im Register „QUIC Transport Parameters“, das in Section 22.3 von [QUIC] eingerichtet wurde.

Registrierte Felder:

  • Value: 0x2ab2
  • Parameter Name: grease_quic_bit
  • Status: Permanent
  • Specification: RFC 9287

6. Referenzen​

6.1. Normative Referenzen​

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

[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, https://www.rfc-editor.org/info/rfc8999.

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

6.2. Informative Referenzen​

[DEMUX] Kühlewind, M. and C. Huitema, "Multiplexing Scheme Updates for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multiplexing-02, 22 October 2020, https://datatracker.ietf.org/doc/html/draft-ietf-quic-multiplexing-02.

[RFC8546] Trammell, B. and M. Kühlewind, "The Wire Image of a Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2019, https://www.rfc-editor.org/info/rfc8546.

[USE-IT] Thomson, M., "Use It or Lose It", RFC 9170, DOI 10.17487/RFC9170, December 2021, https://www.rfc-editor.org/info/rfc9170.

Adresse des Autors​

Martin Thomson Mozilla Email: [email protected]