Aller au contenu principal

RFC 9287 - Graissage du bit QUIC (Greasing the QUIC Bit)

  • Statut: Proposed Standard
  • Publication: August 2022
  • Stream: IETF
  • Errata: Aucune errata

Résumé (Abstract)​

Le présent document décrit une méthode pour négocier la capacité d'envoyer une valeur arbitraire pour le second bit le plus significatif dans les paquets QUIC.

État de ce mémo (Status of This Memo)​

Il s'agit d'un document de la série Internet Standards Track.

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). Des informations supplémentaires sur les Internet Standards sont disponibles dans la Section 2 du RFC 7841.

Des informations sur l'état actuel de ce document, toute errata et la façon de fournir des retours sont disponibles à https://www.rfc-editor.org/info/rfc9287.

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

Ce document est soumis au BCP 78 et aux dispositions juridiques 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 la Revised BSD License décrit à la Section 4.e des Trust Legal Provisions et sont fournis sans garantie comme décrit dans la Revised BSD License.

Table des matières (Table of Contents)​

    1. Introduction
    1. Conventions et définitions
    1. Paramètre de transport Grease QUIC Bit
    1. Considérations de sécurité
    1. Considérations IANA
    1. Références
  • Adresse de l'auteur

1. Introduction​

La définition indépendante de la version de QUIC [QUIC-INVARIANTS] décrit intentionnellement un ensemble très étroit de champs visibles pour des entités autres que les extrémités. Au-delà de ces caractéristiques invariantes, très peu de l'« image filaire » (wire image) [RFC8546] de QUIC est visible.

Le second bit le plus significatif du premier octet de chaque paquet QUIC est défini comme ayant une valeur fixe dans QUIC version 1 [QUIC]. Le but d'une valeur fixe est de permettre aux extrémités de distinguer efficacement QUIC des autres protocoles ; voir [DEMUX] pour la description d'un système pouvant utiliser cette propriété. Comme ce bit peut identifier un paquet comme QUIC, on l'appelle parfois le « bit QUIC » (QUIC Bit).

Lorsque les extrémités et les intermédiaires qui les prennent en charge ne dépendent pas d'une valeur fixe du bit QUIC, envoyer la même valeur dans chaque paquet est davantage un passif qu'un atout. Si des systèmes en viennent à dépendre d'une valeur fixe, il pourrait devenir irréalisable de définir une version de QUIC qui attribue une sémantique à ce bit.

Afin de préserver l'usage futur de ce bit, le présent document définit un paramètre de transport QUIC indiquant qu'une extrémité est disposée à recevoir des paquets QUIC contenant n'importe quelle valeur pour ce bit. En envoyant des valeurs différentes pour ce bit, on espère que la valeur restera disponible pour un usage futur [USE-IT].

2. Conventions et définitions​

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 le BCP 14 [RFC2119] [RFC8174] lorsqu'ils apparaissent en majuscules, et uniquement dans ce cas.

Le présent document utilise les termes et conventions de notation de [QUIC].

3. Paramètre de transport Grease QUIC Bit​

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

Une extrémité qui annonce le paramètre grease_quic_bit MUST accepter les paquets avec le bit QUIC positionné à 0. Le bit QUIC est défini comme le second bit le plus significatif du premier octet des paquets QUIC (c'est-à-dire la valeur 0x40).

3.1. Effacement du bit QUIC​

Les extrémités qui reçoivent le paramètre grease_quic_bit d'un pair SHOULD positionner le bit QUIC à une valeur imprévisible, sauf si une autre extension attribue une sémantique spécifique à la valeur du bit.

Les extrémités peuvent positionner le bit QUIC à 0 sur tous les paquets envoyés après réception et traitement des paramètres de transport. Cela peut inclure les paquets Initial, Handshake et Retry.

Un client MAY aussi positionner le bit QUIC à 0 dans les paquets Initial, Handshake ou 0-RTT envoyés avant de recevoir les paramètres de transport du serveur. Cependant, un client MUST NOT positionner le bit QUIC à 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. Utilisation du bit QUIC​

Le présent document décrit un usage du bit QUIC compatible avec la définition de [QUIC].

4. Considérations de sécurité​

Le graissage du bit QUIC vise à préserver l'usage futur du bit. Il ne fournit aucune propriété de sécurité.

5. Considérations IANA​

Le présent document enregistre le paramètre de transport grease_quic_bit dans le registre « QUIC Transport Parameters » établi à la Section 22.3 de [QUIC].

Champs enregistrés:

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

6. Références​

6.1. Références normatives​

[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. Références informatives​

[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 de l'auteur​

Martin Thomson Mozilla Email: [email protected]