Passa al contenuto principale

RFC 9221 - An Unreliable Datagram Extension to QUIC

  • Stato: Proposed Standard
  • Pubblicato: March 2022
  • Stream: IETF
  • Errata: Nessun errata

Abstract​

This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.

Questo documento definisce un'estensione al protocollo di trasporto QUIC per aggiungere il supporto per l'invio e la ricezione di datagrammi inaffidabili su una connessione QUIC.

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 dell'Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una 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/rfc9221.

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

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

Copyright (c) 2022 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 alla BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i propri diritti e restrizioni in relazione a questo documento. I componenti di codice estratti da questo documento devono includere il testo della licenza BSD revisionata come descritto nella Sezione 4.e delle disposizioni legali del Trust e sono forniti senza garanzia come descritto nella licenza BSD revisionata.

Table of Contents​

    1. Introduction
    1. Motivation
    1. Transport Parameter
    1. Datagram Frame Types
    1. Behavior and Usage
    1. Security Considerations
    1. IANA Considerations
    1. References
  • Acknowledgments
  • Authors' Addresses

1. Introduction​

The QUIC transport protocol [RFC9000] provides a secure, multiplexed connection for transmitting reliable streams of application data. QUIC uses various frame types to transmit data within packets, and each frame type defines whether the data it contains will be retransmitted. Streams of reliable application data are sent using STREAM frames.

Il protocollo di trasporto QUIC [RFC9000] fornisce una connessione sicura e multiplexata per la trasmissione di flussi affidabili di dati applicativi. QUIC utilizza vari tipi di frame per trasmettere dati all'interno dei pacchetti e ogni tipo di frame definisce se i dati in esso contenuti verranno ritrasmessi. I flussi di dati applicativi affidabili vengono inviati utilizzando frame STREAM.

Some applications, particularly those that need to transmit real-time data, prefer to transmit data unreliably. In the past, these applications have built directly upon UDP [RFC0768] as a transport and have often added security with DTLS [RFC6347]. Extending QUIC to support transmitting unreliable application data provides another option for secure datagrams with the added benefit of sharing the cryptographic and authentication context used for reliable streams.

Alcune applicazioni, in particolare quelle che devono trasmettere dati in tempo reale, preferiscono trasmettere i dati in modo inaffidabile. In passato, queste applicazioni sono state create direttamente su UDP [RFC0768] come trasporto e hanno spesso aggiunto sicurezza con DTLS [RFC6347]. L'estensione di QUIC per supportare la trasmissione di dati applicativi inaffidabili fornisce un'altra opzione per datagrammi sicuri con l'ulteriore vantaggio di condividere il contesto crittografico e di autenticazione utilizzato per i flussi affidabili.

This document defines two new DATAGRAM QUIC frame types that carry application data without requiring retransmissions.

Questo documento definisce due nuovi tipi di frame DATAGRAM QUIC che trasportano dati applicativi senza richiedere ritrasmissioni.

1.1. Specification of Requirements​

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 in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

2. Motivation​

Transmitting unreliable data over QUIC provides benefits over existing solutions:

La trasmissione di dati inaffidabili su QUIC offre vantaggi rispetto alle soluzioni esistenti:

  • Applications that want to use both a reliable stream and an unreliable flow to the same peer can benefit by sharing a single handshake and authentication context between a reliable QUIC stream and a flow of unreliable QUIC datagrams. This can reduce the latency required for handshakes compared to opening both a TLS connection and a DTLS connection.
  • Le applicazioni che desiderano utilizzare sia un flusso affidabile che un flusso inaffidabile verso lo stesso peer possono trarre vantaggio dalla condivisione di un singolo handshake e contesto di autenticazione tra un flusso QUIC affidabile e un flusso di datagrammi QUIC inaffidabili. Ciò può ridurre la latenza richiesta per gli handshake rispetto all'apertura sia di una connessione TLS che di una connessione DTLS.
  • QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake. This can allow loss recovery to occur more quickly for QUIC data.
  • QUIC utilizza un meccanismo di recupero delle perdite più sfumato rispetto all'handshake DTLS. Ciò può consentire che il recupero delle perdite avvenga più rapidamente per i dati QUIC.
  • QUIC datagrams are subject to QUIC congestion control. Providing a single congestion control for both reliable and unreliable data can be more effective and efficient.
  • I datagrammi QUIC sono soggetti al controllo della congestione QUIC. Fornire un unico controllo della congestione sia per i dati affidabili che per quelli inaffidabili può essere più efficace ed efficiente.

These features can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications.

Queste funzionalità possono essere utili per ottimizzare le applicazioni di streaming audio/video, le applicazioni di gioco e altre applicazioni di rete in tempo reale.

Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN). Internet-layer tunneling protocols generally require a reliable and authenticated handshake followed by unreliable secure communication.

I datagrammi QUIC inaffidabili possono anche essere utilizzati per implementare un tunnel di pacchetti IP su QUIC, come per una rete privata virtuale (VPN). I protocolli di tunneling a livello Internet richiedono generalmente un handshake affidabile e autenticato seguito da una comunicazione sicura inaffidabile.

3. Transport Parameter​

This document defines a new transport parameter, max_datagram_frame_size (value 0x20). This parameter represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) that the endpoint is willing to receive, in bytes.

Questo documento definisce un nuovo parametro di trasporto, max_datagram_frame_size (valore 0x20). Questo parametro rappresenta la dimensione massima di un frame DATAGRAM (inclusi tipo di frame, lunghezza e payload) che l'endpoint è disposto a ricevere, in byte.

4. Datagram Frame Types​

This document defines two new frame types:

Questo documento definisce due nuovi tipi di frame:

  • DATAGRAM (0x30): A DATAGRAM frame containing application data. The frame does not contain a length field; the data extends to the end of the packet.
  • DATAGRAM (0x30): Un frame DATAGRAM contenente dati applicativi. Il frame non contiene un campo lunghezza; i dati si estendono fino alla fine del pacchetto.
  • DATAGRAM_WITH_LEN (0x31): A DATAGRAM frame containing application data. The frame contains a length field.
  • DATAGRAM_WITH_LEN (0x31): Un frame DATAGRAM contenente dati applicativi. Il frame contiene un campo lunghezza.

5. Behavior and Usage​

5.1. Multiplexing Datagrams​

DATAGRAM frames are multiplexed with other QUIC frames within QUIC packets.

I frame DATAGRAM sono multiplexati con altri frame QUIC all'interno dei pacchetti QUIC.

5.2. Acknowledgement Handling​

Although DATAGRAM frames are not retransmitted upon loss, they are acknowledged. This allows the sender to maintain congestion control state and potentially gather statistics about delivery.

Sebbene i frame DATAGRAM non vengano ritrasmessi in caso di perdita, vengono riconosciuti. Ciò consente al mittente di mantenere lo stato di controllo della congestione e potenzialmente raccogliere statistiche sulla consegna.

5.3. Flow Control​

DATAGRAM frames are not subject to flow control. The max_datagram_frame_size transport parameter limits the size of individual frames, but there is no limit on the total number of bytes or frames.

I frame DATAGRAM non sono soggetti al controllo del flusso. Il parametro di trasporto max_datagram_frame_size limita la dimensione dei singoli frame, ma non vi è alcun limite al numero totale di byte o frame.

5.4. Congestion Control​

DATAGRAM frames are congestion controlled. The sender MUST respect the congestion controller's limits when sending DATAGRAM frames.

I frame DATAGRAM sono controllati dalla congestione. Il mittente DEVE rispettare i limiti del controller di congestione durante l'invio di frame DATAGRAM.

6. Security Considerations​

The security considerations for this document are similar to those for QUIC [RFC9000]. The use of unreliable datagrams introduces some additional considerations, such as the potential for amplification attacks if the datagrams are used to reflect traffic.

Le considerazioni sulla sicurezza per questo documento sono simili a quelle per QUIC [RFC9000]. L'uso di datagrammi inaffidabili introduce alcune considerazioni aggiuntive, come il potenziale per attacchi di amplificazione se i datagrammi vengono utilizzati per riflettere il traffico.

7. IANA Considerations​

7.1. QUIC Transport Parameter​

This document registers a new value in the "QUIC Transport Parameters" registry:

Questo documento registra un nuovo valore nel registro "QUIC Transport Parameters":

  • Value: 0x20
  • Parameter Name: max_datagram_frame_size
  • Status: permanent
  • Specification: RFC 9221

7.2. QUIC Frame Types​

This document registers two new values in the "QUIC Frame Types" registry:

Questo documento registra due nuovi valori nel registro "QUIC Frame Types":

  • Value: 0x30-0x31
  • Frame Name: DATAGRAM
  • Status: permanent
  • Specification: RFC 9221

8. References​

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

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

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

8.2. Informative References​

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc0768.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, https://www.rfc-editor.org/info/rfc6347.

Acknowledgements​

The authors would like to thank...

Gli autori desiderano ringraziare...

Authors' Addresses​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]

Ultimo aggiornamento il