Passa al contenuto principale

RFC 9369 - QUIC Version 2

  • Stato: Proposed Standard
  • Pubblicato: May 2023
  • Stream: IETF
  • Errata: Nessun errata

Abstract​

This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.

Questo documento specifica la versione 2 di QUIC, che è identica alla versione 1 di QUIC tranne per alcuni dettagli banali. Il suo scopo è combattere vari vettori di ossificazione ed esercitare il framework di negoziazione della versione. Serve anche come modello per le modifiche minime in qualsiasi versione futura di QUIC.

Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks.

Si noti che "versione 2" è un nome informale per questa proposta che indica che è la seconda versione di QUIC ad essere pubblicata come documento Standards Track. Il protocollo specificato qui utilizza un numero di versione diverso da 2 nell'immagine wire, al fine di ridurre al minimo i rischi di ossificazione.

Status of This Memo​

This is an Internet Standards Track document.

Questo è un documento 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.

Questo documento è un prodotto della Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli standard Internet sono disponibili nella sezione 2 della 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/rfc9369.

Informazioni sullo stato attuale di questo documento, eventuali errata e come fornire feedback su di esso possono essere ottenute su https://www.rfc-editor.org/info/rfc9369.

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

Copyright (c) 2023 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

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.

Questo documento è soggetto al BCP 78 e alle Disposizioni legali del IETF Trust relative ai documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di rivedere attentamente questi documenti, poiché descrivono i vostri diritti e restrizioni rispetto a questo documento. I componenti di codice estratti da questo documento devono includere il testo della licenza BSD rivista come descritto nella sezione 4.e delle Disposizioni legali del Trust e sono forniti senza garanzia come descritto nella licenza BSD rivista.

Table of Contents​

    1. Introduction
    1. Conventions
    1. Differences with QUIC Version 1
    1. Version Negotiation Considerations
    1. TLS Resumption and NEW_TOKEN Tokens
    1. Ossification Considerations
    1. Applicability
    1. Security Considerations
    1. IANA Considerations
    1. References
  • Appendix A. Sample Packet Protection
  • Acknowledgments
  • Author's Address

1. Introduction​

QUIC version 1 [QUIC] has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see [QUIC-INVARIANTS]). If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes that are usually 0x00000001.

La versione 1 di QUIC [QUIC] ha numerosi punti di estensione, incluso il numero di versione che occupa dal secondo al quinto byte di ogni intestazione lunga (vedere [QUIC-INVARIANTS]). Se le versioni sperimentali sono rare e la versione 1 di QUIC costituisce la stragrande maggioranza del traffico QUIC, esiste il potenziale per i middlebox di ossificarsi sui byte della versione che sono solitamente 0x00000001.

In QUIC version 1, Initial packets are encrypted with the version-specific salt, as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats.

Nella versione 1 di QUIC, i pacchetti iniziali sono crittografati con il salt specifico della versione, come descritto nella Sezione 5.2 di [QUIC-TLS]. Proteggere i pacchetti iniziali in questo modo consente agli osservatori di ispezionare il loro contenuto, che include i messaggi TLS Client Hello o Server Hello. Ancora una volta, esiste il potenziale per i middlebox di ossificarsi sulla derivazione della chiave e sui formati dei pacchetti della versione 1.

Finally, [QUIC-VN] describes two mechanisms endpoints can use to negotiate which QUIC version to select. The "incompatible" version negotiation method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round trip at the start of the connection. "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically.

Infine, [QUIC-VN] descrive due meccanismi che gli endpoint possono utilizzare per negoziare quale versione QUIC selezionare. Il metodo di negoziazione della versione "incompatibile" può supportare il passaggio da qualsiasi versione QUIC a qualsiasi altra versione con piena generalità, al costo di un round trip aggiuntivo all'inizio della connessione. La negoziazione della versione "compatibile" elimina la penalità del round trip ma impone alcune restrizioni su quanto le due versioni possono differire semanticamente.

QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms. The changes provide an example of the minimum set of changes necessary to specify a new QUIC version. However, note that the choice of the version number on the wire is randomly chosen instead of "2", and the two bits that identify each Long Header packet type are different from version 1; both of these properties are meant to combat ossification and are not strictly required of a new QUIC version.

La versione 2 di QUIC è intesa a mitigare le preoccupazioni di ossificazione ed esercitare i meccanismi di negoziazione della versione. Le modifiche forniscono un esempio del set minimo di modifiche necessarie per specificare una nuova versione QUIC. Tuttavia, si noti che la scelta del numero di versione sul cavo è scelta casualmente invece di "2", e i due bit che identificano ciascun tipo di pacchetto Long Header sono diversi dalla versione 1; entrambe queste proprietà sono intese a combattere l'ossificazione e non sono strettamente richieste per una nuova versione QUIC.

Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks.

Qualsiasi endpoint che supporta due versioni deve implementare la negoziazione della versione per proteggersi dagli attacchi di downgrade.

2. Conventions​

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.

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nel BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

3. Differences with QUIC Version 1​

Except for a few differences, QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY]. The remainder of this section lists the differences.

A parte alcune differenze, gli endpoint QUIC versione 2 DEVONO implementare la specifica QUIC versione 1 come descritto in [QUIC], [QUIC-TLS] e [QUIC-RECOVERY]. Il resto di questa sezione elenca le differenze.

3.1. Version Field​

The Version field of long headers is 0x6b3343cf. This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number".

Il campo Version delle intestazioni lunghe è 0x6b3343cf. Questo è stato generato prendendo i primi quattro byte dello sha256sum di "QUICv2 version number".

3.2. Long Header Packet Types​

All version 2 Long Header packet types are different. The Type field values are:

Tutti i tipi di pacchetti Long Header della versione 2 sono diversi. I valori del campo Type sono:

  • Initial: 0b01
  • 0-RTT: 0b10
  • Handshake: 0b11
  • Retry: 0b00

3.3. Cryptography Changes​

3.3.1. Initial Salt​

The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] changes to:

Il salt utilizzato per derivare le chiavi iniziali nella Sezione 5.2 di [QUIC-TLS] cambia in:

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

This is the first 20 bytes of the sha256sum of "QUICv2 salt".

Questi sono i primi 20 byte dello sha256sum di "QUICv2 salt".

3.3.2. HMAC-based Key Derivation Function (HKDF) Labels​

The labels used in [QUIC-TLS] to derive packet protection keys (Section 5.1), header protection keys (Section 5.4), Retry Integrity Tag keys (Section 5.8), and key updates (Section 6.1) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku" to meet the guidance for new versions in Section 9.6 of that document.

Le etichette utilizzate in [QUIC-TLS] per derivare le chiavi di protezione dei pacchetti (Sezione 5.1), le chiavi di protezione dell'intestazione (Sezione 5.4), le chiavi del tag di integrità di riprova (Sezione 5.8) e gli aggiornamenti delle chiavi (Sezione 6.1) cambiano da "quic key" a "quicv2 key", da "quic iv" a "quicv2 iv", da "quic hp" a "quicv2 hp" e da "quic ku" a "quicv2 ku" per soddisfare le linee guida per le nuove versioni nella Sezione 9.6 di quel documento.

3.3.3. Retry Integrity Tag​

The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS]) change to:

La chiave e il nonce utilizzati per il Retry Integrity Tag (Sezione 5.8 di [QUIC-TLS]) cambiano in:

secret = 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f key = 0x8fb4b01b56ac48e260fbcbcead7ccc92 nonce = 0xd86969bc2d7c6d9990efb04a

The secret is the sha256sum of "QUICv2 retry secret". The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively.

Il segreto è lo sha256sum di "QUICv2 retry secret". La chiave e il nonce sono derivati da questo segreto con le etichette "quicv2 key" e "quicv2 iv", rispettivamente.

4. Version Negotiation Considerations​

QUIC version 2 is not intended to deprecate version 1. Endpoints that support version 2 might continue support for version 1 to maximize compatibility with other endpoints. In particular, HTTP clients often use Alt-Svc [RFC7838] to discover QUIC support. As this mechanism does not currently distinguish between QUIC versions, HTTP servers SHOULD support multiple versions to reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback. For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version 1, as it was the original QUIC version used by HTTP/3; therefore, some clients will only support that version.

La versione 2 di QUIC non è intesa a deprecate la versione 1. Gli endpoint che supportano la versione 2 potrebbero continuare a supportare la versione 1 per massimizzare la compatibilità con altri endpoint. In particolare, i client HTTP utilizzano spesso Alt-Svc [RFC7838] per scoprire il supporto QUIC. Poiché questo meccanismo attualmente non distingue tra le versioni QUIC, i server HTTP DOVREBBERO supportare più versioni per ridurre la probabilità di incompatibilità e il costo associato alla negoziazione della versione QUIC o al fallback TCP. Ad esempio, un'origine che pubblicizza il supporto per "h3" in Alt-Svc dovrebbe supportare la versione 1 di QUIC, in quanto era la versione QUIC originale utilizzata da HTTP/3; pertanto, alcuni client supporteranno solo quella versione.

Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks.

Qualsiasi endpoint QUIC che supporta la versione 2 di QUIC DEVE inviare, elaborare e convalidare il parametro di trasporto version_information specificato in [QUIC-VN] per prevenire attacchi di downgrade della versione.

Note that version 2 meets the definition in [QUIC-VN] of a compatible version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip.

Si noti che la versione 2 soddisfa la definizione in [QUIC-VN] di una versione compatibile con la versione 1, e la versione 1 è compatibile con la versione 2. Pertanto, i server possono utilizzare la negoziazione compatibile per commutare una connessione tra le due versioni. Gli endpoint che supportano entrambe le versioni DOVREBBERO supportare la negoziazione della versione compatibile per evitare un round trip.

4.1. Compatible Negotiation Requirements​

Compatible version negotiation between versions 1 and 2 follows the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from [QUIC-VN].

La negoziazione della versione compatibile tra le versioni 1 e 2 segue gli stessi requisiti in entrambe le direzioni. Questa sezione utilizza i termini "versione originale" e "versione negoziata" da [QUIC-VN].

If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions. The client MUST NOT use a different version in the subsequent Initial packet that contains the Retry token. The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched, to enforce client compliance.

Se il server invia un pacchetto Retry, DEVE utilizzare la versione originale. Il client ignora i pacchetti Retry che utilizzano altre versioni. Il client NON DEVE utilizzare una versione diversa nel successivo pacchetto Initial che contiene il token Retry. Il server PUÒ codificare la versione QUIC nel suo token Retry per convalidare che il client non abbia cambiato versione e scartare il pacchetto se è cambiato, per imporre la conformità del client.

QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1. After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in Section 7.3 of [QUIC].

La versione 2 di QUIC utilizza gli stessi parametri di trasporto per autenticare il Retry della versione 1 di QUIC. Dopo essere passati a una versione negoziata dopo un Retry, il server DEVE includere i parametri di trasporto pertinenti per convalidare che il server ha inviato il Retry e gli ID di connessione utilizzati nello scambio, come descritto nella Sezione 7.3 di [QUIC].

The server cannot send CRYPTO frames until it has processed the client's transport parameters. The server MUST send all CRYPTO frames using the negotiated version.

Il server non può inviare frame CRYPTO finché non ha elaborato i parametri di trasporto del client. Il server DEVE inviare tutti i frame CRYPTO utilizzando la versione negoziata.

The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version, it indicates that the negotiated version is equal to the original version.

Il client apprende la versione negoziata osservando il primo campo Version dell'intestazione lunga che differisce dalla versione originale. Se il client riceve un frame CRYPTO dal server nella versione originale, indica che la versione negoziata è uguale alla versione originale.

Before the server is able to process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version.

Prima che il server sia in grado di elaborare i parametri di trasporto dal client, potrebbe dover rispondere ai pacchetti Initial dal client. Per questi pacchetti, il server utilizza la versione originale.

Once the client has learned the negotiated version, it SHOULD send subsequent Initial packets using that version. The server MUST NOT discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version.

Una volta che il client ha appreso la versione negoziata, DOVREBBE inviare i successivi pacchetti Initial utilizzando quella versione. Il server NON DEVE scartare le sue chiavi di ricezione Initial della versione originale finché non elabora con successo un pacchetto Handshake con la versione negoziata.

Both endpoints MUST send Handshake and 1-RTT packets using the negotiated version. An endpoint MUST drop packets using any other version. Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate such packets.

Entrambi gli endpoint DEVONO inviare pacchetti Handshake e 1-RTT utilizzando la versione negoziata. Un endpoint DEVE scartare i pacchetti che utilizzano qualsiasi altra versione. Gli endpoint non hanno bisogno di generare il materiale della chiave che consentirebbe loro di decrittografare o autenticare tali pacchetti.

The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version.

Il client NON DEVE inviare pacchetti 0-RTT utilizzando la versione negoziata, anche dopo aver elaborato un pacchetto di quella versione dal server. I server possono accettare 0-RTT e quindi elaborare i pacchetti 0-RTT dalla versione originale.

5. TLS Resumption and NEW_TOKEN Tokens​

TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients MUST NOT use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, and vice versa. When a connection includes compatible version negotiation, any issued server tokens are considered to originate from the negotiated version, not the original one.

I ticket di sessione TLS e i token NEW_TOKEN sono specifici per la versione QUIC della connessione che li ha forniti. I client NON DEVONO utilizzare un ticket di sessione o un token da una connessione QUIC versione 1 per avviare una connessione QUIC versione 2, e viceversa. Quando una connessione include la negoziazione della versione compatibile, qualsiasi token del server emesso è considerato originato dalla versione negoziata, non da quella originale.

Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version. A rejected ticket results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in the client address remaining unverified, which limits the amount of data the server can send.

I server DEVONO convalidare la versione di origine di qualsiasi ticket di sessione o token e non accettarne uno emesso da una versione diversa. Un ticket rifiutato comporta il fallback a un handshake TLS completo, senza 0-RTT. Un token rifiutato comporta che l'indirizzo del client rimanga non verificato, il che limita la quantità di dati che il server può inviare.

After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than the original one.

Dopo la negoziazione della versione compatibile, qualsiasi ticket di sessione risultante viene mappato alla versione negoziata anziché a quella originale.

6. Ossification Considerations​

QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets.

La versione 2 di QUIC fornisce protezione contro alcune forme di ossificazione. I dispositivi che presumono che tutte le intestazioni lunghe codificheranno la versione 1, o che la formula di derivazione della chiave Initial della versione 1 rimarrà invariante rispetto alla versione, non elaboreranno correttamente i pacchetti della versione 2.

However, many middleboxes, such as firewalls, focus on the first packet in a connection, which will often remain in the version 1 format due to the considerations above.

Tuttavia, molti middlebox, come i firewall, si concentrano sul primo pacchetto di una connessione, che rimarrà spesso nel formato versione 1 a causa delle considerazioni di cui sopra.

Clients interested in combating middlebox ossification can initiate a connection using version 2 if they are reasonably certain the server supports it and if they are willing to suffer a round-trip penalty if they are incorrect. In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed.

I client interessati a combattere l'ossificazione dei middlebox possono avviare una connessione utilizzando la versione 2 se sono ragionevolmente certi che il server la supporti e se sono disposti a subire una penalità di round trip se non sono corretti. In particolare, un server che emette un ticket di sessione per la versione 2 indica l'intenzione di mantenere il supporto della versione 2 finché il ticket rimane valido, anche se il supporto non può essere garantito.

7. Applicability​

QUIC version 2 provides no change from QUIC version 1 for the capabilities available to applications. Therefore, all Application-Layer Protocol Negotiation (ALPN) [RFC7301] codepoints specified to operate over QUIC version 1 can also operate over this version of QUIC. In particular, both the "h3" [HTTP/3] and "doq" [RFC9250] ALPNs can operate over QUIC version 2.

La versione 2 di QUIC non fornisce alcuna modifica rispetto alla versione 1 di QUIC per le capacità disponibili per le applicazioni. Pertanto, tutti i codepoint Application-Layer Protocol Negotiation (ALPN) [RFC7301] specificati per operare sulla versione 1 di QUIC possono operare anche su questa versione di QUIC. In particolare, sia gli ALPN "h3" [HTTP/3] che "doq" [RFC9250] possono operare sulla versione 2 di QUIC.

Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2.

Se non diversamente specificato, tutte le estensioni QUIC definite per funzionare con la versione 1 funzionano anche con la versione 2.

8. Security Considerations​

QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.

La versione 2 di QUIC non introduce modifiche alle proprietà di sicurezza o privacy della versione 1 di QUIC.

The mandatory version negotiation mechanism guards against downgrade attacks, but downgrades have no security implications, as the version properties are identical.

Il meccanismo di negoziazione della versione obbligatorio protegge dagli attacchi di downgrade, ma i downgrade non hanno implicazioni di sicurezza, poiché le proprietà della versione sono identiche.

Support for QUIC version 2 can help an observer to fingerprint both client and server devices.

Il supporto per la versione 2 di QUIC può aiutare un osservatore a rilevare l'impronta digitale sia dei dispositivi client che server.

9. IANA Considerations​

IANA has added the following entries to the "QUIC Versions" registry maintained at https://www.iana.org/assignments/quic.

La IANA ha aggiunto le seguenti voci al registro "QUIC Versions" mantenuto su https://www.iana.org/assignments/quic.

Value: 0x6b3343cf Status: permanent Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG

Value: 0x709a50c4 Status: provisional Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG Notes: QUIC v2 draft codepoint

10. References​

10.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-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, https://www.rfc-editor.org/info/rfc9002.

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, https://www.rfc-editor.org/info/rfc9001.

[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, May 2023, https://www.rfc-editor.org/info/rfc9368.

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

10.2. Informative References​

[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, https://www.rfc-editor.org/info/rfc9114.

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

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, https://www.rfc-editor.org/info/rfc7301.

[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, https://www.rfc-editor.org/info/rfc7838.

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, https://www.rfc-editor.org/info/rfc9250.

Appendix A. Sample Packet Protection​

This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both the client and server plus a Retry packet are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included. All values are shown in hexadecimal.

Questa sezione mostra esempi di protezione dei pacchetti in modo che le implementazioni possano essere verificate in modo incrementale. Vengono definiti esempi di pacchetti Initial sia dal client che dal server più un pacchetto Retry. Questi pacchetti utilizzano un Destination Connection ID scelto dal client di 8 byte di 0x8394c8f03e515708. Sono inclusi alcuni valori intermedi. Tutti i valori sono mostrati in esadecimale.

(See RFC text for details on A.1 - A.5, code blocks are untranslated)

Acknowledgments​

The author would like to thank Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin Thomson for their helpful suggestions.

L'autore desidera ringraziare Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa e Martin Thomson per i loro utili suggerimenti.

Author's Address​

Martin Duke Google LLC Email: [email protected]

Ultimo aggiornamento il