Passa al contenuto principale

RFC 9221 - Un'estensione di datagrammi non affidabili per QUIC

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

Sommario (Abstract)​

Il presente documento definisce un'estensione al protocollo di trasporto QUIC per aggiungere il supporto all'invio e alla ricezione di datagrammi non affidabili su una connessione QUIC.

Stato di questo memo​

Questo è un documento Internet Standards Track.

Il presente documento è un prodotto dell'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 Internet Standards sono disponibili nella Sezione 2 di RFC 7841.

Informazioni sullo stato corrente di questo documento sono disponibili 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.

Il presente documento è soggetto a BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (https://trustee.ietf.org/license-info). I componenti di codice estratti da questo documento devono includere il testo della Revised BSD License descritto nella Sezione 4.e delle Trust Legal Provisions.

Indice​

    1. Introduzione
    1. Motivazione
    1. Parametro di trasporto
    1. Tipi di frame Datagram
    1. Comportamento e uso
    1. Considerazioni sulla sicurezza
    1. Considerazioni IANA
    1. Riferimenti
  • Ringraziamenti
  • Indirizzi degli autori

1. Introduzione​

Il protocollo di trasporto QUIC [RFC9000] fornisce una connessione sicura e multiplexed per trasmettere flussi affidabili di dati applicativi. QUIC usa vari tipi di frame per trasmettere dati all'interno dei pacchetti, e ciascun tipo di frame definisce se i dati che contiene saranno ritrasmessi. I flussi di dati applicativi affidabili sono inviati usando frame STREAM.

Alcune applicazioni, in particolare quelle che devono trasmettere dati in tempo reale, preferiscono trasmettere dati in modo non affidabile. In passato, queste applicazioni si sono basate direttamente su UDP [RFC0768] come trasporto e hanno spesso aggiunto la sicurezza con DTLS [RFC6347]. Estendere QUIC per supportare la trasmissione di dati applicativi non affidabili fornisce un'altra opzione per datagrammi sicuri, con il beneficio aggiuntivo di condividere il contesto crittografico e di autenticazione usato per i flussi affidabili.

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

1.1. Specifica dei requisiti​

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

2. Motivazione​

Trasmettere dati non affidabili su QUIC fornisce vantaggi rispetto alle soluzioni esistenti:

  • Le applicazioni che vogliono usare sia un flusso affidabile sia un flusso non affidabile verso lo stesso peer possono beneficiare condividendo un singolo handshake e contesto di autenticazione tra un flusso QUIC affidabile e un flusso di datagrammi QUIC non affidabili. Ciò può ridurre la latenza richiesta per gli handshake rispetto all'apertura sia di una connessione TLS sia di una connessione DTLS.
  • QUIC usa un meccanismo di recupero delle perdite più sfumato dell'handshake DTLS. Ciò può consentire un recupero delle perdite più rapido per i dati QUIC.
  • I datagrammi QUIC sono soggetti al controllo di congestione QUIC. Fornire un singolo controllo di congestione per dati affidabili e non affidabili può essere più efficace ed efficiente.

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

I datagrammi QUIC non affidabili possono anche essere usati per implementare un tunnel di pacchetti IP su QUIC, ad esempio per una Virtual Private Network (VPN). I protocolli di tunneling a livello Internet richiedono generalmente un handshake affidabile e autenticato seguito da comunicazione sicura non affidabile.

3. Parametro di trasporto​

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

4. Tipi di frame Datagram​

Il presente documento definisce due nuovi tipi di frame:

  • 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): Un frame DATAGRAM contenente dati applicativi. Il frame contiene un campo lunghezza.

5. Comportamento e uso​

5.1. Multiplexing dei datagrammi​

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

5.2. Gestione degli acknowledgement​

Sebbene i frame DATAGRAM non siano ritrasmessi in caso di perdita, sono acknowledgati. Ciò consente al mittente di mantenere lo stato del controllo di congestione e potenzialmente raccogliere statistiche sulla consegna.

5.3. Controllo di flusso​

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

5.4. Controllo di congestione​

I frame DATAGRAM sono soggetti al controllo di congestione. Il mittente MUST rispettare i limiti del controller di congestione quando invia frame DATAGRAM.

6. Considerazioni sulla sicurezza​

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

7. Considerazioni IANA​

7.1. Parametro di trasporto QUIC​

Il presente 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. Tipi di frame QUIC​

Il presente documento registra due nuovi valori nel registro «QUIC Frame Types»:

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

8. Riferimenti​

8.1. Riferimenti normativi​

[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. Riferimenti informativi​

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

Ringraziamenti​

Gli autori desiderano ringraziare...

Indirizzi degli autori​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]