Aller au contenu principal

RFC 9287 - Greasing the QUIC Bit

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

Abstract​

This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets.

Ce document décrit une méthode permettant de négocier la capacité d'envoyer une valeur arbitraire pour le deuxième bit le plus significatif des paquets 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/rfc9287.

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/rfc9287.

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. Conventions and Definitions
    1. The Grease QUIC Bit Transport Parameter
    1. Security Considerations
    1. IANA Considerations
    1. References
  • Author's Address

1. Introduction​

The version-independent definition of QUIC [QUIC-INVARIANTS] intentionally describes a very narrow set of fields that are visible to entities other than endpoints. Beyond those characteristics that are invariant, very little about the "wire image" [RFC8546] of QUIC is visible.

La définition de QUIC indépendante de la version [QUIC-INVARIANTS] décrit intentionnellement un ensemble très restreint de champs visibles par des entités autres que les points de terminaison. Au-delà de ces caractéristiques invariantes, très peu de choses sur l'« image filaire » [RFC8546] de QUIC sont visibles.

The second-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 [QUIC]. The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see [DEMUX] for a description of a system that might use this property. As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit".

Le deuxième bit le plus significatif du premier octet de chaque paquet QUIC est défini comme ayant une valeur fixe dans la version 1 de QUIC [QUIC]. Le but d'avoir une valeur fixe est de permettre aux points de terminaison de distinguer efficacement QUIC des autres protocoles ; voir [DEMUX] pour une description d'un système qui pourrait utiliser cette propriété. Comme ce bit peut identifier un paquet comme QUIC, il est parfois appelé « bit QUIC ».

Where endpoints and the intermediaries that support them do not depend on the QUIC Bit having a fixed value, sending the same value in every packet is more of a liability than an asset. If systems come to depend on a fixed value, then it might become infeasible to define a version of QUIC that attributes semantics to this bit.

Lorsque les points de terminaison et les intermédiaires qui les prennent en charge ne dépendent pas du fait que le bit QUIC ait une valeur fixe, envoyer la même valeur dans chaque paquet est plus un handicap qu'un atout. Si les systèmes en viennent à dépendre d'une valeur fixe, il pourrait alors devenir impossible de définir une version de QUIC qui attribue une sémantique à ce bit.

In order to safeguard future use of this bit, this document defines a QUIC transport parameter that indicates that an endpoint is willing to receive QUIC packets containing any value for this bit. By sending different values for this bit, the hope is that the value will remain available for future use [USE-IT].

Afin de préserver l'utilisation future de ce bit, ce document définit un paramètre de transport QUIC qui indique qu'un point de terminaison est prêt à recevoir des paquets QUIC contenant n'importe quelle valeur pour ce bit. En envoyant des valeurs différentes pour ce bit, l'espoir est que la valeur restera disponible pour une utilisation future [USE-IT].

2. Conventions and Definitions​

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.

This document uses terms and notational conventions from [QUIC].

Ce document utilise des termes et des conventions de notation de [QUIC].

3. The Grease QUIC Bit Transport Parameter​

The grease_quic_bit transport parameter (0x2ab2) is defined for QUIC version 1 [QUIC]. This transport parameter can be sent by both client and server. The transport parameter is sent with an empty value; an endpoint that understands this transport parameter MUST treat receipt of a non-empty value of the transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR.

Le paramètre de transport grease_quic_bit (0x2ab2) est défini pour la version 1 de QUIC [QUIC]. Ce paramètre de transport peut être envoyé par le client et le serveur. Le paramètre de transport est envoyé avec une valeur vide ; un point de terminaison qui comprend ce paramètre de transport DOIT traiter la réception d'une valeur non vide du paramètre de transport comme une erreur de connexion de type TRANSPORT_PARAMETER_ERROR.

An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0. The QUIC Bit is defined as the second-most significant bit of the first byte of QUIC packets (that is, the value 0x40).

Un point de terminaison qui annonce le paramètre de transport grease_quic_bit DOIT accepter les paquets dont le bit QUIC est défini sur une valeur de 0. Le bit QUIC est défini comme le deuxième bit le plus significatif du premier octet des paquets QUIC (c'est-à-dire la valeur 0x40).

3.1. Clearing the QUIC Bit​

Endpoints that receive the grease_quic_bit transport parameter from a peer SHOULD set the QUIC Bit to an unpredictable value unless another extension assigns specific meaning to the value of the bit.

Les points de terminaison qui reçoivent le paramètre de transport grease_quic_bit d'un pair DOIVENT définir le bit QUIC sur une valeur imprévisible, à moins qu'une autre extension n'attribue une signification spécifique à la valeur du bit.

Endpoints can set the QUIC Bit to 0 on all packets that are sent after receiving and processing transport parameters. This could include Initial, Handshake, and Retry packets.

Les points de terminaison peuvent définir le bit QUIC sur 0 sur tous les paquets envoyés après la réception et le traitement des paramètres de transport. Cela pourrait inclure les paquets Initial, Handshake et Retry.

A client MAY also set the QUIC Bit to 0 in Initial, Handshake, or 0-RTT packets that are sent prior to receiving transport parameters from the server. However, a client MUST NOT set the QUIC Bit to 0 if it also sends a token provided in a Retry packet or in a NEW_TOKEN frame (Section 19.7 of [QUIC]).

Un client PEUT également définir le bit QUIC sur 0 dans les paquets Initial, Handshake ou 0-RTT envoyés avant de recevoir les paramètres de transport du serveur. Cependant, un client NE DOIT PAS définir le bit QUIC sur 0 s'il envoie également un jeton fourni dans un paquet Retry ou dans une trame NEW_TOKEN (Section 19.7 de [QUIC]).

3.2. Using the QUIC Bit​

This document describes a use of the QUIC Bit that is compatible with the definition in [QUIC].

Ce document décrit une utilisation du bit QUIC compatible avec la définition de [QUIC].

4. Security Considerations​

Greasing the QUIC Bit is intended to safeguard the future use of the bit. It does not provide any security properties.

Le graissage du bit QUIC est destiné à préserver l'utilisation future du bit. Il ne fournit aucune propriété de sécurité.

5. IANA Considerations​

This document registers the grease_quic_bit transport parameter in the "QUIC Transport Parameters" registry established in Section 22.3 of [QUIC].

Ce document enregistre le paramètre de transport grease_quic_bit dans le registre "QUIC Transport Parameters" établi dans la section 22.3 de [QUIC].

The following fields are registered:

Les champs suivants sont enregistrés :

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

6. References​

6.1. Normative References​

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

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

Author's Address​

Martin Thomson Mozilla Email: [email protected]

Dernière mise à jour le