Passa al contenuto principale

RFC 9308 - Applicabilità del protocollo di trasporto QUIC (Applicability of the QUIC Transport Protocol)

  • Stato: Informational
  • Pubblicato: September 2022
  • Stream: IETF
  • Errata: Nessuna errata

Sommario (Abstract)​

Il presente documento discute l'applicabilità del protocollo di trasporto QUIC, concentrandosi sulle avvertenze che influenzano lo sviluppo e il dispiegamento di protocolli applicativi su QUIC. Il pubblico previsto è costituito dai progettisti delle mappature di protocolli applicativi su QUIC e dagli implementatori di tali protocolli applicativi.

Stato di questo memorandum (Status of This Memo)​

Il presente documento non è una specifica dell'Internet Standards Track; è pubblicato a fini informativi.

Il presente 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). Non tutti i documenti approvati dall'IESG sono candidati per un qualsiasi livello di Internet Standard; vedere la Sezione 2 di RFC 7841.

Informazioni sullo stato attuale del presente documento, eventuali errata e su come fornire feedback possono essere ottenute all'indirizzo https://www.rfc-editor.org/info/rfc9308.

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) in vigore alla data di pubblicazione del presente documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i propri diritti e restrizioni rispetto al presente documento. I componenti di codice estratti dal presente documento devono includere il testo della Revised BSD License come descritto nella Sezione 4.e delle Trust Legal Provisions e sono forniti senza garanzia come descritto nella Revised BSD License.

Indice (Table of Contents)​

  1. Introduzione
  2. La necessità del fallback
  3. 0-RTT
  4. Uso dei flussi
  5. Packetizzazione e latenza
  6. Gestione degli errori
  7. Efficienza degli acknowledgement
  8. Selezione della porta e scoperta degli endpoint applicativi
  9. Migrazione della connessione
  10. Terminazione della connessione
  11. Esposizione di informazioni e Connection ID
  12. QoS e DSCP
  13. Uso delle versioni e dell'handshake crittografico
  14. Abilitare il dispiegamento di nuove versioni
  15. Servizio di datagrammi non affidabili su QUIC
  16. Considerazioni IANA
  17. Considerazioni sulla sicurezza
  18. Riferimenti

1. Introduzione (Introduction)​

QUIC [QUIC] è un nuovo protocollo di trasporto che fornisce numerose funzionalità avanzate. Sebbene inizialmente progettato per il caso d'uso HTTP, fornisce capacità che possono essere utilizzate con una varietà molto più ampia di applicazioni. QUIC è incapsulato in UDP. QUIC versione 1 integra TLS 1.3 [TLS13] per cifrare tutti i dati del payload e la maggior parte delle informazioni di controllo. La versione di HTTP che utilizza QUIC è nota come HTTP/3 [QUIC-HTTP].

Il presente documento fornisce indicazioni per gli sviluppatori di applicazioni che vogliono utilizzare il protocollo QUIC senza implementarlo autonomamente. Ciò include indicazioni generali per applicazioni che operano su HTTP/3 o direttamente su QUIC.

Nelle sezioni seguenti, discutiamo avvertenze specifiche sull'applicabilità di QUIC e questioni che gli sviluppatori di applicazioni devono considerare quando usano QUIC come trasporto per le proprie applicazioni.

2. La necessità del fallback (The Necessity of Fallback)​

QUIC utilizza UDP come substrato. Ciò abilita l'implementazione in spazio utente e consente l'attraversamento di middlebox di rete (incluso il NAT) senza richiedere aggiornamenti all'infrastruttura di rete esistente.

Studi di misurazione hanno mostrato che tra il 3% [Trammell16] e il 5% [Swett16] delle reti blocca tutto il traffico UDP, sebbene vi siano poche evidenze di altre forme di svantaggio sistematico per il traffico UDP rispetto a TCP [Edeline16]. Questo blocco implica che tutte le applicazioni che girano su QUIC devono essere o preparate ad accettare un fallimento di connettività su tali reti, oppure progettate per fare fallback su qualche altro protocollo di trasporto. Nel caso di HTTP, questo fallback è TLS over TCP.

Le specifiche IETF Transport Services (TAPS) [TAPS-ARCH] descrivono un sistema con un'API comune per più protocolli. Ciò è particolarmente rilevante per QUIC poiché affronta le implicazioni del fallback tra più protocolli.

In particolare, il fallback verso protocolli non sicuri o verso versioni più deboli di protocolli sicuri deve essere evitato. In generale, un'applicazione che implementa il fallback deve considerare le conseguenze sulla sicurezza. Un fallback a TCP e TLS espone le informazioni di controllo a modifica e manipolazione nella rete. Inoltre, i downgrade a versioni di TLS più vecchie di 1.3, usata in QUIC versione 1, potrebbero risultare in una protezione crittografica significativamente più debole. Ad esempio, i risultati della negoziazione del protocollo [RFC7301] hanno protezione di riservatezza solo se viene usato TLS 1.3.

Queste applicazioni devono operare, forse con funzionalità ridotta, in assenza di funzionalità fornite da QUIC non presenti nel protocollo di fallback. Per il fallback a TLS over TCP, la differenza più ovvia è che TCP non fornisce il multiplexing dei flussi e quindi il multiplexing dei flussi andrebbe implementato a livello applicativo se necessario. Inoltre, le implementazioni TCP e i percorsi di rete spesso non supportano l'opzione TCP Fast Open (TFO) [RFC7413], che abilita l'invio di dati del payload insieme al primo pacchetto di controllo di una nuova connessione, come fornito anche dalla ripresa di sessione 0-RTT in QUIC. Si noti che vi sono evidenze di middlebox che bloccano i dati SYN anche se TFO è stato negoziato con successo (vedere [PaaschNanog]). E anche se Fast Open opera con successo end-to-end, è limitato a un singolo pacchetto di handshake TLS e dati applicativi, a differenza del 0-RTT di QUIC.

Inoltre, mentre la cifratura (in questo caso TLS) è inseparabilmente integrata con QUIC, la negoziazione TLS su TCP può essere bloccata. Se TLS over TCP non può essere supportato, la connessione dovrebbe essere abortita e l'applicazione dovrebbe quindi presentare all'utente un avviso appropriato che la comunicazione sicura non è disponibile.

In sintesi, qualsiasi meccanismo di fallback è probabile che imponga un degrado delle prestazioni e può degradare la sicurezza; tuttavia, il fallback non deve violare silenziosamente l'aspettativa dell'applicazione di riservatezza o integrità dei propri dati del payload.

3. 0-RTT​

QUIC prevede lo stabilimento della connessione 0-RTT. Sebbene la stessa facilità esista in TLS 1.3 con TCP, il 0-RTT presenta opportunità e sfide per le applicazioni che usano QUIC.

Un protocollo di trasporto che fornisce lo stabilimento della connessione 0-RTT è qualitativamente diverso da uno che non fornisce il 0-RTT dal punto di vista dell'applicazione che lo usa. I compromessi relativi tra il costo di chiudere e riaprire una connessione e il tentativo di mantenerla aperta sono diversi; vedere la Sezione 3.2.

Un'applicazione deve scegliere deliberatamente di usare il 0-RTT, poiché il 0-RTT comporta un rischio di attacco di replay. I protocolli applicativi che usano il 0-RTT richiedono un profilo che descrive i tipi di informazioni che possono essere inviate in sicurezza. Per HTTP, questo profilo è descritto in [HTTP-REPLAY].

3.1. Attacchi di replay (Replay Attacks)​

La ritrasmissione o il replay malevolo dei dati contenuti nei pacchetti 0-RTT potrebbe far sì che il lato server riceva più copie degli stessi dati.

I dati applicativi inviati dal client nei pacchetti 0-RTT potrebbero essere elaborati più di una volta se vengono riprodotti. Le applicazioni devono essere consapevoli di ciò che è sicuro inviare in 0-RTT. I protocolli applicativi che cercano di abilitare l'uso del 0-RTT necessitano di un'analisi attenta e di una descrizione di ciò che può essere inviato in 0-RTT; vedere la Sezione 5.6 di [QUIC-TLS].

In alcuni casi, potrebbe essere sufficiente limitare i dati applicativi inviati in 0-RTT a dati che non causano azioni con effetti duraturi su un server. L'avvio di un recupero di dati o la configurazione di impostazioni sono esempi di azioni che potrebbero essere sicure. Le operazioni idempotenti — quelle per cui la ripetizione ha lo stesso effetto netto di una singola operazione — potrebbero essere sicure. Tuttavia, è anche possibile combinare operazioni individualmente idempotenti in una sequenza di operazioni non idempotente.

Una volta che un server accetta dati 0-RTT, non vi è alcun mezzo per scartare selettivamente i dati ricevuti. Tuttavia, i protocolli possono definire modi per rifiutare azioni individuali che potrebbero essere non sicure se riprodotte.

Alcune implementazioni e dispiegamenti TLS potrebbero essere in grado di fornire una protezione parziale o addirittura completa dal replay, che potrebbe essere usata per gestire il rischio di replay.

3.2. Ripresa di sessione versus keep-alive (Session Resumption versus Keep-Alive)​

Poiché QUIC è incapsulato in UDP, le applicazioni che usano QUIC devono gestire timeout di inattività di rete brevi. Le middlebox stateful dispiegate generalmente stabiliscono stato per i flussi UDP sul primo pacchetto inviato e mantengono lo stato per periodi di inattività molto più brevi che per TCP. [RFC5382] suggerisce un periodo di inattività TCP di almeno 124 minuti, sebbene non vi siano evidenze di un'implementazione diffusa di questa linea guida nella letteratura. Tuttavia, il timeout di rete breve per UDP è ben documentato. Secondo uno studio del 2010 ([Hatonen10]), le applicazioni UDP possono assumere che qualsiasi binding NAT o altra voce di stato possa scadere dopo soli trenta secondi di inattività. La Sezione 3.5 di [RFC8085] discute ulteriormente gli intervalli di keep-alive per UDP: richiede un valore minimo di 15 secondi, ma raccomanda valori più grandi, o che il keep-alive sia omesso del tutto.

Usando un connection ID, QUIC è progettato per essere robusto al rebinding NAT dopo un timeout. Tuttavia, ciò aiuta solo se un endpoint mantiene la disponibilità all'indirizzo che il peer usa e il peer è quello che invia dopo che si verifica il timeout.

Alcune connessioni QUIC potrebbero non essere robuste al rebinding NAT perché l'infrastruttura di routing (in particolare i bilanciatori di carico) usa il 4-tupla indirizzo/porta per dirigere il traffico. Inoltre, middlebox con funzioni diverse dalla traduzione di indirizzi potrebbero ancora influenzare il percorso. In particolare, alcuni firewall non ammettono il traffico del server per cui il firewall non ha stato recente per un pacchetto corrispondente inviato dal client.

Le applicazioni QUIC possono regolare i periodi di inattività per gestire il rischio di timeout. I periodi di inattività e il timeout di inattività di rete sono distinti dal timeout di inattività della connessione, che è definito come il minimo del parametro idle timeout di uno dei due endpoint; vedere la Sezione 10.1 di [QUIC]. Vi sono tre opzioni:

  • Ignorare il problema se il protocollo di livello applicativo consiste solo in interazioni senza o con periodi di inattività molto brevi, o se la resistenza del protocollo al rebinding NAT è sufficiente.
  • Assicurarsi che non vi siano lunghi periodi di inattività.
  • Riprendere la sessione dopo un lungo periodo di inattività, usando la ripresa 0-RTT quando appropriato.

La prima strategia è la più facile, ma si applica solo a certe applicazioni.

Il server o il client in un'applicazione QUIC possono inviare frame PING come keep-alive per impedire che la connessione e qualsiasi stato sul percorso scadano. Le raccomandazioni per l'uso dei keep-alive sono specifiche dell'applicazione, dipendendo principalmente dai requisiti di latenza e dalla frequenza dei messaggi dell'applicazione. In questo caso, la mappatura applicativa deve specificare se il client o il server è responsabile di mantenere viva l'applicazione. Sebbene [Hatonen10] suggerisca che 30 secondi potrebbero essere un valore adatto per l'Internet pubblica quando un NAT è sul percorso, valori più grandi sono preferibili se il dispiegamento può sopravvivere in modo coerente al rebinding NAT o è noto essere in un ambiente controllato (ad es., data center) al fine di ridurre il carico di rete e computazionale.

L'invio di frame PING più frequentemente di ogni 30 secondi su lunghi periodi di inattività può risultare in traffico improduttivo eccessivo in alcune situazioni e in un uso di energia inaccettabile per dispositivi con vincoli di energia (mobili). Inoltre, timeout più brevi di 30 secondi possono rendere più difficile gestire interruzioni di rete transitorie, come la migrazione di macchine virtuali (VM) o la perdita di copertura durante la mobilità. Vedere [RFC8085], specialmente la Sezione 3.5.

In alternativa, il client (ma non il server) può usare la ripresa di sessione invece di inviare traffico di keep-alive. In questo caso, un client che vuole inviare dati a un server su una connessione che è rimasta inattiva più a lungo del timeout di inattività del server (disponibile dal parametro di trasporto idle_timeout) può semplicemente riconnettersi. Quando possibile, questa riconnessione può usare la ripresa di sessione 0-RTT, riducendo la latenza coinvolta nel riavvio della connessione. Naturalmente, questo approccio è valido solo nei casi in cui è sicuro usare il 0-RTT e quando il client è il peer che si riavvia.

I compromessi tra ripresa e keep-alive devono essere valutati per applicazione. In generale, le applicazioni dovrebbero usare i keep-alive solo in circostanze in cui la comunicazione continuata è altamente probabile; [QUIC-HTTP], ad esempio, raccomanda di usare i keep-alive solo quando una richiesta è in sospeso.

4. Uso dei flussi (Use of Streams)​

La funzionalità di multiplexing dei flussi di QUIC consente alle applicazioni di eseguire più flussi su una singola connessione senza head-of-line blocking tra i flussi. I dati di flusso sono trasportati all'interno di frame in cui un pacchetto QUIC sul filo può trasportare uno o più frame di flusso.

I flussi possono essere unidirezionali o bidirezionali, e un flusso può essere iniziato dal client o dal server. Solo l'iniziatore di un flusso unidirezionale può inviare dati su di esso.

I flussi e le connessioni possono ciascuno trasportare un massimo di 2^62-1 byte in ciascuna direzione a causa di limitazioni di codifica sugli offset di flusso e sui limiti di controllo di flusso della connessione. Nell'evento attualmente improbabile che questo limite sia raggiunto da un'applicazione, andrebbe stabilita una nuova connessione.

I flussi possono essere aperti e chiusi indipendentemente, in modo graceful o abrupto. Un'applicazione può chiudere gracefully la direzione di uscita di un flusso istruendo QUIC a inviare un bit FIN in un frame STREAM. Non può chiudere gracefully la direzione di ingresso senza un FIN generato dal peer, un po' come in TCP. Tuttavia, un endpoint può chiudere abruptamente la direzione di uscita o richiedere che il peer chiuda abruptamente la direzione di ingresso; queste azioni sono completamente indipendenti l'una dall'altra.

QUIC non fornisce un'interfaccia per la gestione eccezionale di un flusso qualsiasi. Se un flusso critico per un'applicazione viene chiuso, l'applicazione può generare messaggi di errore a livello applicativo per informare l'altra estremità e/o il livello superiore, che può eventualmente terminare la connessione QUIC.

La mappatura dei dati applicativi sui flussi è specifica dell'applicazione e descritta per HTTP/3 in [QUIC-HTTP]. Vi sono alcuni principi generali da applicare quando si progetta l'uso dei flussi da parte di un'applicazione:

  • Un singolo flusso fornisce l'ordinamento. Se l'applicazione richiede che certi dati siano ricevuti in ordine, quei dati dovrebbero essere inviati sullo stesso flusso. Non vi è alcuna garanzia di ordine di trasmissione, ricezione o consegna tra i flussi.
  • Più flussi forniscono concorrenza. I dati che possono essere elaborati indipendentemente e che quindi soffrirebbero di head-of-line blocking se fossero forzati a essere ricevuti in ordine dovrebbero essere trasmessi su flussi separati.
  • I flussi possono fornire orientamento a messaggi e consentire la cancellazione dei messaggi. Se un messaggio è mappato su un singolo flusso, il reset del flusso per far scadere un messaggio non confermato può essere usato per emulare affidabilità parziale per quel messaggio.

Se un ricevitore QUIC ha aperto il massimo di flussi concorrenti consentiti e il mittente indica che sono necessari più flussi, ciò non porta automaticamente a un aumento del numero massimo di flussi da parte del ricevitore. Pertanto, un'applicazione dovrebbe considerare il numero massimo di flussi consentiti, attualmente aperti e attualmente usati quando determina come mappare i dati sui flussi.

QUIC assegna un identificatore numerico, chiamato stream ID, a ciascun flusso. Sebbene la relazione tra questi identificatori e i tipi di flusso sia chiaramente definita nella versione 1 di QUIC, le versioni future potrebbero cambiare questa relazione per varie ragioni. Le implementazioni QUIC dovrebbero esporre le proprietà di ciascun flusso (quale endpoint ha iniziato il flusso, se il flusso è unidirezionale o bidirezionale, lo stream ID usato per il flusso); le applicazioni dovrebbero interrogare queste proprietà piuttosto che tentare di inferirle dallo stream ID.

Il metodo di allocazione degli identificatori di flusso ai flussi aperti dall'applicazione potrebbe variare tra le implementazioni di trasporto. Pertanto, un'applicazione non dovrebbe assumere che un particolare stream ID sarà assegnato a un flusso che non è ancora stato allocato. Ad esempio, HTTP/3 usa stream ID per riferirsi a flussi che sono già stati aperti ma non fa assunzioni su futuri stream ID o sul modo in cui vengono assegnati (vedere la Sezione 6 di [QUIC-HTTP]).

4.1. Multiplexing di flussi versus multiplexing di flussi di rete (Stream versus Flow Multiplexing)​

I flussi hanno significato solo per l'applicazione; poiché le informazioni di flusso sono trasportate all'interno del confine di cifratura di QUIC, un dato pacchetto non espone alcuna informazione su quali flussi sono trasportati all'interno del pacchetto. Pertanto, il multiplexing dei flussi non è destinato a essere usato per differenziare i flussi in termini di trattamento di rete. Il traffico applicativo che richiede un diverso trattamento di rete dovrebbe quindi essere trasportato su 5-tuple diverse (cioè più connessioni QUIC). Data la capacità di QUIC di inviare dati applicativi nel primo RTT di una connessione (se una connessione precedente allo stesso host è stata stabilita con successo per fornire le credenziali necessarie), il costo di stabilire un'altra connessione è estremamente basso.

4.2. Prioritizzazione (Prioritization)​

La prioritizzazione dei flussi non è esposta né alla rete né al ricevitore. La prioritizzazione è gestita dal mittente e il trasporto QUIC dovrebbe fornire un'interfaccia affinché le applicazioni diano priorità ai flussi [QUIC]. Le applicazioni possono implementare il proprio schema di prioritizzazione su QUIC: un protocollo applicativo che gira su QUIC può definire messaggi espliciti per segnalare la priorità, come quelli definiti in [RFC9218] per HTTP. Un protocollo applicativo può definire regole che consentono a un endpoint di determinare la priorità in base al contesto, oppure può fornire un'interfaccia di livello superiore e lasciare la determinazione all'applicazione superiore.

La gestione della priorità delle ritrasmissioni può essere implementata dal mittente a livello di trasporto. [QUIC] raccomanda di ritrasmettere i dati persi prima dei nuovi dati, a meno che l'applicazione non indichi diversamente. Quando un endpoint QUIC usa flussi completamente affidabili per la trasmissione, la prioritizzazione delle ritrasmissioni sarà benefica nella maggior parte dei casi, colmando le lacune e liberando la finestra di controllo di flusso. Per flussi parzialmente affidabili o non affidabili, lo scheduling prioritario delle ritrasmissioni rispetto a dati di flussi a priorità più alta potrebbe non essere desiderabile. Per tali flussi, QUIC potrebbe fornire un'interfaccia esplicita per controllare la prioritizzazione oppure derivare la decisione di prioritizzazione dal livello di affidabilità del flusso.

4.3. Consegna ordinata e affidabile (Ordered and Reliable Delivery)​

I flussi QUIC abilitano la consegna ordinata e affidabile. Sebbene sia possibile per un'implementazione fornire opzioni che usano i flussi per affidabilità parziale o consegna out-of-order, la maggior parte delle implementazioni assumerà che i dati siano consegnati in modo affidabile e in ordine.

Sotto questa assunzione, un endpoint che riceve dati di flusso potrebbe non progredire finché non sono disponibili dati contigui con l'inizio di un flusso. In particolare, un ricevitore potrebbe trattenere il credito di controllo di flusso finché i dati contigui non sono consegnati all'applicazione; vedere la Sezione 2.2 di [QUIC]. Per supportare questa logica di ricezione, un endpoint invierà dati di flusso fino a quando non sono confermati, assicurando che i dati all'inizio del flusso siano inviati e confermati per primi.

Un endpoint che usa un comportamento di invio diverso e non negozia tale cambiamento con il peer potrebbe incontrare problemi di prestazioni o deadlock.

4.4. Deadlock del controllo di flusso (Flow Control Deadlocks)​

Il controllo di flusso QUIC (Sezione 4 di [QUIC]) fornisce un mezzo per gestire l'accesso ai buffer limitati che gli endpoint hanno per i dati in arrivo. Questo meccanismo limita la quantità di dati che possono essere nei buffer degli endpoint o in transito sulla rete. Tuttavia, vi sono diversi modi in cui i limiti possono produrre condizioni che possono far sì che una connessione o performi in modo subottimale o diventi in deadlock.

I deadlock nel controllo di flusso sono possibili per qualsiasi protocollo che usa QUIC, sebbene se diventino un problema dipenda da come le implementazioni consumano i dati e forniscono il credito di controllo di flusso. Comprendere cosa causa i deadlock potrebbe aiutare le implementazioni a evitarli.

La dimensione e la frequenza degli aggiornamenti del credito di controllo di flusso possono influenzare le prestazioni. Le applicazioni che usano QUIC spesso hanno un consumatore di dati che legge i dati dai buffer di trasporto. Alcune implementazioni potrebbero avere buffer di ricezione indipendenti a livello di trasporto e a livello applicativo. Consumare i dati non implica sempre che siano elaborati immediatamente. Tuttavia, una tecnica di implementazione comune è estendere il credito di controllo di flusso al mittente emettendo frame MAX_DATA e/o MAX_STREAM_DATA man mano che i dati vengono consumati. La consegna di questi frame è influenzata dalla latenza del canale di ritorno dal ricevitore al mittente dei dati. Se il credito non viene esteso in modo tempestivo, l'applicazione mittente può essere bloccata, strozzando di fatto il mittente.

Messaggi applicativi grandi possono produrre deadlock se il destinatario non legge i dati dal trasporto in modo incrementale. Se il messaggio è più grande del credito di controllo di flusso disponibile e il destinatario non rilascia credito di controllo di flusso aggiuntivo finché l'intero messaggio non è ricevuto e consegnato, può verificarsi un deadlock. Ciò è possibile anche quando i limiti di controllo di flusso del flusso non sono raggiunti perché i limiti di controllo di flusso della connessione possono essere consumati da altri flussi.

Un formato di messaggio con prefisso di lunghezza rende più facile per un consumatore di dati lasciare i dati non letti nel buffer di trasporto e quindi trattenere il credito di controllo di flusso. Se i limiti di controllo di flusso impediscono l'invio del resto di un messaggio, ne risulterà un deadlock. Un prefisso di lunghezza potrebbe anche abilitare il rilevamento di questo tipo di deadlock. Dove i protocolli applicativi hanno messaggi che potrebbero essere elaborati come una singola unità, riservare atomicamente il credito di controllo di flusso per l'intero messaggio rende questo stile di deadlock meno probabile.

Un consumatore di dati può leggere avidamente tutti i dati non appena diventano disponibili al fine di far estendere al ricevitore il credito di controllo di flusso e ridurre le probabilità di un deadlock. Tuttavia, tale consumatore di dati potrebbe aver bisogno di altri mezzi per ritenere un peer responsabile dello stato aggiuntivo che mantiene per messaggi parzialmente elaborati.

Il deadlock può anche verificarsi se i dati su flussi diversi sono interdipendenti. Si supponga che i dati su un flusso arrivino prima dei dati su un secondo flusso da cui dipendono. Un deadlock può verificarsi se il primo flusso è lasciato non letto, impedendo al ricevitore di estendere il credito di controllo di flusso per il secondo flusso. Per ridurre la probabilità di deadlock per dati interdipendenti, il mittente dovrebbe assicurarsi che i dati dipendenti non siano inviati finché i dati da cui dipendono non siano stati contabilizzati nel credito di controllo di flusso sia a livello di flusso sia a livello di connessione.

Alcuni scenari di deadlock potrebbero essere risolti cancellando i flussi interessati con STOP_SENDING o RESET_STREAM. La cancellazione di alcuni flussi risulta nella terminazione della connessione in alcuni protocolli.

4.5. Impegni sui limiti di flusso (Stream Limit Commitments)​

Gli endpoint QUIC sono responsabili di comunicare il limite cumulativo di flussi che consentirebbero di essere aperti dal peer. I limiti iniziali sono annunciati usando i parametri di trasporto initial_max_streams_bidi e initial_max_streams_uni. Man mano che i flussi vengono aperti e chiusi, vengono consumati e il totale cumulativo viene incrementato. I limiti possono essere aumentati usando il frame MAX_STREAMS, ma non vi è alcun meccanismo per ridurre i limiti. Una volta raggiunti i limiti di flusso, non possono essere aperti altri flussi, il che impedisce alle applicazioni che usano QUIC di progredire ulteriormente. In questa fase, le connessioni possono essere terminate tramite timeout di inattività o chiusura esplicita; vedere la Sezione 10.

Un'applicazione che usa QUIC e comunica un limite di flusso cumulativo potrebbe richiedere che la connessione sia chiusa prima che il limite sia raggiunto, ad es. per arrestare il server al fine di eseguire manutenzione programmata. La chiusura immediata della connessione causa la chiusura abrupta dei flussi usati attivamente. A seconda di come un'applicazione usa i flussi QUIC, ciò potrebbe essere indesiderabile o dannoso per il comportamento o le prestazioni.

Una tecnica di chiusura più graceful è smettere di inviare aumenti ai limiti di flusso e consentire alla connessione di terminare naturalmente una volta che i flussi rimanenti sono consumati. Tuttavia, il periodo di tempo necessario per farlo dipende dal peer e un periodo di chiusura imprevedibile potrebbe non adattarsi alle esigenze applicative o operative. Le applicazioni che usano QUIC possono essere conservative con i limiti di flussi aperti al fine di ridurre l'impegno e l'indeterminismo. Tuttavia, essere eccessivamente conservativi con i limiti di flusso influenza la concorrenza dei flussi. Bilanciare questi aspetti può essere specifico delle applicazioni e dei loro dispiegamenti.

Invece di basarsi sui limiti di flusso per evitare la chiusura abrupta, il meccanismo di chiusura graceful di un livello applicativo può essere usato per comunicare l'intenzione di chiudere esplicitamente la connessione in un punto futuro. HTTP/3 fornisce tale meccanismo usando il frame GOAWAY. In HTTP/3, quando il frame GOAWAY è ricevuto da un client, smette di aprire nuovi flussi anche se il limite di flusso cumulativo lo consentirebbe. Invece, il client creerebbe una nuova connessione su cui aprire ulteriori flussi. Una volta che tutti i flussi sono chiusi sulla vecchia connessione, può essere terminata in sicurezza da una chiusura di connessione o dopo la scadenza del timeout di inattività (vedere la Sezione 10).

5. Packetizzazione e latenza (Packetization and Latency)​

QUIC espone un'interfaccia che fornisce più flussi all'applicazione; tuttavia, l'applicazione di solito non può controllare come i dati trasmessi su quei flussi siano mappati in frame o come quei frame siano raggruppati in pacchetti.

Per impostazione predefinita, molte implementazioni cercheranno di impacchettare frame STREAM da uno o più flussi in ciascun pacchetto QUIC, al fine di minimizzare il consumo di banda e i costi computazionali (vedere la Sezione 13 di [QUIC]). Se non vi sono abbastanza dati disponibili per riempire un pacchetto, un'implementazione potrebbe attendere per un breve tempo per ottimizzare l'efficienza di banda invece della latenza. Questo ritardo può essere o preconfigurato o regolato dinamicamente in base al pattern di invio osservato dell'applicazione.

Se l'applicazione richiede bassa latenza, con solo piccoli pezzi di dati da inviare, può essere utile indicare a QUIC che tutti i dati dovrebbero essere inviati immediatamente. In alternativa, se l'applicazione si aspetta di usare un pattern di invio specifico, può anche fornire a QUIC un ritardo suggerito su quanto a lungo attendere prima di raggruppare i frame in un pacchetto.

Allo stesso modo, un'applicazione di solito non ha controllo sulla lunghezza di un pacchetto QUIC sul filo. QUIC fornisce la capacità di aggiungere un frame PADDING per aumentare arbitrariamente la dimensione dei pacchetti. Il padding è usato da QUIC per assicurare che il percorso sia capace di trasferire datagrammi di almeno una certa dimensione durante l'handshake (vedere le Sezioni 8.1 e 14.1 di [QUIC]) e per la validazione del percorso dopo la migrazione della connessione (vedere la Sezione 8.2 di [QUIC]) nonché per Datagram Packetization Layer PMTU Discovery (DPLPMTUD) (vedere la Sezione 14.3 di [QUIC]).

Il padding può anche essere usato da un'applicazione per ridurre la fuga di informazioni sui dati che vengono inviati. Un'implementazione QUIC può esporre un'interfaccia che consente a un livello applicativo di specificare come applicare il padding.

6. Gestione degli errori (Error Handling)​

QUIC raccomanda che gli endpoint segnalino qualsiasi errore rilevato al peer. Gli errori possono verificarsi a livello di trasporto e a livello applicativo. Gli errori di trasporto, come una violazione del protocollo, influenzano l'intera connessione. Le applicazioni che usano QUIC possono definire il proprio rilevamento e segnalazione degli errori (vedere, ad esempio, la Sezione 8 di [QUIC-HTTP]). Gli errori applicativi possono influenzare un'intera connessione o un singolo flusso.

QUIC definisce uno spazio di codici di errore che è usato per la gestione degli errori a livello di trasporto. QUIC incoraggia gli endpoint a usare il codice più specifico, sebbene qualsiasi codice applicabile sia consentito, inclusi quelli generici.

Le applicazioni che usano QUIC definiscono uno spazio di codici di errore indipendente da QUIC o da altre applicazioni (vedere, ad esempio, la Sezione 8.1 di [QUIC-HTTP]). I valori in uno spazio di codici di errore applicativo possono essere riutilizzati tra errori a livello di connessione e a livello di flusso.

Gli errori di connessione portano alla terminazione della connessione. Sono segnalati usando un frame CONNECTION_CLOSE, che contiene un codice di errore e un campo reason che può avere lunghezza zero. Diversi tipi di frame CONNECTION_CLOSE sono usati per segnalare errori di trasporto e applicativi.

Gli errori di flusso portano alla terminazione del flusso. Questi sono segnalati usando frame STOP_SENDING o RESET_STREAM, che contengono solo un codice di errore.

7. Efficienza degli acknowledgement (Acknowledgment Efficiency)​

QUIC versione 1 senza estensioni usa una strategia di acknowledgement adottata da TCP (vedere la Sezione 13.2 di [QUIC]). Cioè, raccomanda che ogni altro pacchetto sia confermato. Tuttavia, generare e elaborare gli acknowledgement QUIC consuma risorse presso un mittente e un ricevitore. Gli acknowledgement comportano anche costi di inoltro e contribuiscono all'utilizzo del collegamento, il che può influenzare le prestazioni su alcuni tipi di rete. Le applicazioni potrebbero essere in grado di migliorare le prestazioni complessive usando strategie alternative che riducono il tasso di acknowledgement. [QUIC-ACK-FREQUENCY] descrive un'estensione per segnalare il ritardo desiderato degli acknowledgement e discute casi d'uso nonché implicazioni per il controllo di congestione e il recovery.

8. Selezione della porta e scoperta degli endpoint applicativi (Port Selection and Application Endpoint Discovery)​

In generale, i numeri di porta servono due scopi: «primo, forniscono un identificatore di demultiplexing per differenziare le sessioni di trasporto tra la stessa coppia di endpoint, e secondo, possono anche identificare il protocollo applicativo e il servizio associato a cui i processi si connettono» (Sezione 3 di [RFC6335]). L'assunzione che un'applicazione possa essere identificata nella rete in base al numero di porta è meno vera oggi a causa dell'incapsulamento e dei meccanismi di assegnazione dinamica delle porte, come notato in [RFC6335].

Poiché QUIC è un protocollo di trasporto di uso generale, non vi sono requisiti che i server usino una particolare porta UDP per QUIC. Per un'applicazione con fallback a TCP che non ha già una mappatura alternativa a UDP, di solito è appropriato registrare (se necessario) e usare il numero di porta UDP corrispondente alla porta TCP già registrata per l'applicazione. Ad esempio, la porta predefinita per HTTP/3 [QUIC-HTTP] è la porta UDP 443, analoga a HTTP/1.1 o HTTP/2 over TLS over TCP.

Data la prevalenza dell'assunzione nella pratica di gestione di rete che un numero di porta mappa in modo non ambiguo a un'applicazione, l'uso di porte che non possono essere facilmente mappate a un nome di servizio registrato potrebbe portare a blocco o ad altri cambiamenti nel comportamento di inoltro da parte di elementi di rete come i firewall che usano il numero di porta per l'identificazione dell'applicazione.

Le applicazioni potrebbero definire un meccanismo alternativo di scoperta degli endpoint per consentire l'uso di porte diverse da quella predefinita. Ad esempio, HTTP/3 (Sezioni 3.2 e 3.3 di [QUIC-HTTP]) specifica l'uso di HTTP Alternative Services [RFC7838] affinché un origin HTTP annunci la disponibilità di un endpoint HTTP/3 equivalente su una certa porta UDP usando "h3" come token Application-Layer Protocol Negotiation (ALPN) [RFC7301].

ALPN consente al client e al server di negoziare quale di diversi protocolli sarà usato su una data connessione. Pertanto, più applicazioni potrebbero essere supportate su una singola porta UDP in base al token ALPN offerto. Le applicazioni che usano QUIC sono tenute a registrare un token ALPN per l'uso nell'handshake TLS.

Poiché QUIC versione 1 ha rimandato la definizione di un meccanismo completo di negoziazione della versione, HTTP/3 richiede QUIC versione 1 e definisce il token ALPN ("h3") come applicabile solo a quella versione. Finora, nessun approccio singolo è stato selezionato per gestire l'uso di diverse versioni di QUIC, né in HTTP/3 né in generale. I protocolli applicativi che usano QUIC devono considerare come il protocollo gestirà diverse versioni di QUIC. Le decisioni per quei protocolli potrebbero essere informate dalle scelte fatte da altri protocolli, come HTTP/3.

8.1. Selezione della porta sorgente (Source Port Selection)​

Alcuni protocolli UDP sono vulnerabili ad attacchi di reflection, in cui un attaccante è in grado di dirigere traffico verso una terza parte come denial of service. Ad esempio, queste porte sorgente sono associate ad applicazioni note per essere vulnerabili ad attacchi di reflection, spesso a causa di configurazione errata del server:

  • porta 53 - DNS [RFC1034]
  • porta 123 - NTP [RFC5905]
  • porta 1900 - SSDP [SSDP]
  • porta 5353 - mDNS [RFC6762]
  • porta 11211 - memcache

I servizi potrebbero bloccare le porte sorgente associate a protocolli noti per essere vulnerabili ad attacchi di reflection per evitare l'overhead di elaborare grandi numeri di pacchetti. Tuttavia, questa pratica ha effetti negativi sui client — non solo richiede lo stabilimento di una nuova connessione ma in alcune istanze potrebbe far sì che il client eviti di usare QUIC per quel servizio per un periodo di tempo e faccia downgrade a un protocollo non UDP (vedere la Sezione 2).

Di conseguenza, le implementazioni client sono incoraggiate a evitare l'uso di porte sorgente associate a protocolli noti per essere vulnerabili ad attacchi di reflection. Si noti che seguire le indicazioni generali per le implementazioni client date in [RFC6335], di usare porte effimere nell'intervallo 49152-65535, ha l'effetto di evitare queste porte. Si noti che anche altre porte sorgente potrebbero essere vettori di reflection.

9. Migrazione della connessione (Connection Migration)​

QUIC supporta la migrazione della connessione da parte del client. Se l'indirizzo IP del client cambia, un endpoint QUIC può ancora associare i pacchetti a una connessione di trasporto esistente usando il campo Destination Connection ID (vedere la Sezione 11) nell'header QUIC. Ciò supporta casi in cui le informazioni di indirizzo cambiano, come il rebinding NAT, il cambiamento intenzionale dell'interfaccia locale, la scadenza di un indirizzo IPv6 temporaneo [RFC8981], o l'indicazione dal server di un indirizzo preferito (Sezione 9.6 di [QUIC]).

L'uso di un connection ID di lunghezza non zero per il server è fortemente raccomandato se eventuali client sono o potrebbero essere dietro un NAT. Un connection ID di lunghezza non zero è anche fortemente raccomandato quando è supportata la migrazione attiva. Se una connessione è intenzionalmente migrata a un nuovo percorso, viene usato un nuovo connection ID per minimizzare la linkability da parte degli osservatori di rete. L'altro endpoint QUIC usa il connection ID per collegare indirizzi diversi alla stessa connessione ed entità se viene fornito un connection ID di lunghezza non zero.

La specifica di base di QUIC versione 1 supporta solo l'uso di un singolo percorso di rete alla volta, il che abilita casi d'uso di failover. La validazione del percorso è richiesta in modo che gli endpoint validino i percorsi prima dell'uso per evitare attacchi di spoofing di indirizzo. La validazione del percorso richiede almeno un RTT e anche il controllo di congestione sarà resettato dopo la migrazione del percorso. Pertanto, la migrazione di solito ha un impatto sulle prestazioni.

I pacchetti di probing QUIC, che possono essere inviati su più percorsi contemporaneamente, sono usati per eseguire la validazione degli indirizzi nonché per misurare le caratteristiche del percorso. I pacchetti di probing non possono trasportare dati applicativi ma probabilmente contengono frame di padding. Gli endpoint possono usare informazioni sulla loro ricezione come input al controllo di congestione per quel percorso. Le applicazioni potrebbero usare le informazioni apprese dal probing per informare una decisione di cambiare percorso.

Solo il client può migrare attivamente nella versione 1 di QUIC. Tuttavia, i server possono indicare durante l'handshake che preferiscono trasferire la connessione a un indirizzo diverso dopo l'handshake. Ad esempio, ciò potrebbe essere usato per spostarsi da un indirizzo condiviso da più server a un indirizzo unico per l'istanza del server. Il server può fornire un indirizzo IPv4 e un indirizzo IPv6 in un parametro di trasporto durante l'handshake TLS e il client può scegliere tra i due se entrambi sono forniti. Vedere la Sezione 9.6 di [QUIC].

10. Terminazione della connessione (Connection Termination)​

Le connessioni QUIC sono terminate in uno di tre modi: timeout di inattività implicito, chiusura immediata esplicita o reset stateless esplicito.

QUIC non fornisce alcun meccanismo per la terminazione graceful della connessione; le applicazioni che usano QUIC possono definire il proprio processo di terminazione graceful (vedere, ad esempio, la Sezione 5.2 di [QUIC-HTTP]).

Il timeout di inattività QUIC è abilitato tramite parametri di trasporto. Il client e il server annunciano un periodo di timeout e il valore effettivo per la connessione è il minimo dei due valori. Dopo che il periodo di timeout scade, la connessione viene chiusa silenziosamente. Un'applicazione dovrebbe quindi essere in grado di configurare il proprio valore massimo, nonché avere accesso al valore minimo calcolato per questa connessione. Un'applicazione può regolare il timeout di inattività massimo per le nuove connessioni in base al numero di connessioni aperte o attese poiché valori di timeout più brevi possono liberare risorse più rapidamente.

I dati applicativi scambiati sui flussi o nei datagrammi differiscono il timeout di inattività QUIC. Le applicazioni che forniscono i propri meccanismi di keep-alive manterranno quindi viva una connessione QUIC. Le applicazioni che non forniscono il proprio keep-alive possono usare meccanismi di livello di trasporto (vedere la Sezione 10.1.2 di [QUIC] e la Sezione 3.2). Tuttavia, le interfacce delle implementazioni QUIC per controllare tale comportamento di trasporto possono variare, influenzando la robustezza di tali approcci.

Una chiusura immediata è segnalata da un frame CONNECTION_CLOSE (vedere la Sezione 6). La chiusura immediata fa sì che tutti i flussi diventino immediatamente chiusi, il che può influenzare le applicazioni; vedere la Sezione 4.5.

Un reset stateless è un'opzione di ultima istanza per un endpoint che non ha accesso allo stato della connessione. Ricevere un reset stateless è un'indicazione di un errore irrecuperabile distinto dagli errori di connessione in quanto non vengono fornite informazioni a livello applicativo.

11. Esposizione di informazioni e Connection ID (Information Exposure and the Connection ID)​

QUIC espone alcune informazioni alla rete nella parte non cifrata dell'header o prima che il contesto di cifratura sia stabilito o perché le informazioni sono destinate a essere usate dalla rete. Per ulteriori informazioni sulla gestibilità di QUIC, vedere [QUIC-MANAGEABILITY]. QUIC ha un header lungo che espone alcune informazioni aggiuntive (la versione e il source connection ID), mentre l'header corto espone solo il destination connection ID. In QUIC versione 1, l'header lungo è usato durante lo stabilimento della connessione, mentre l'header corto è usato per la trasmissione di dati in una connessione stabilita.

Il connection ID può avere lunghezza zero. I connection ID di lunghezza zero possono essere scelti su ciascun endpoint individualmente e su qualsiasi pacchetto tranne i primi pacchetti inviati dai client durante lo stabilimento della connessione.

Un endpoint che seleziona un connection ID di lunghezza zero riceverà pacchetti con un destination connection ID di lunghezza zero. L'endpoint deve usare altre informazioni, come l'indirizzo IP e il numero di porta di origine e destinazione per identificare a quale connessione si fa riferimento. Ciò potrebbe significare che l'endpoint non è in grado di abbinare con successo i datagrammi alle connessioni se questi valori cambiano, rendendo la connessione effettivamente incapace di sopravvivere al rebinding NAT o di migrare a un nuovo percorso.

11.1. Connection ID generato dal server (Server-Generated Connection ID)​

QUIC supporta un connection ID generato dal server che è trasmesso al client durante lo stabilimento della connessione (vedere la Sezione 7.2 di [QUIC]). I server dietro bilanciatori di carico potrebbero aver bisogno di cambiare il connection ID durante l'handshake, codificando l'identità del server o informazioni sul suo pool di bilanciamento del carico, al fine di supportare il bilanciamento del carico stateless.

I dispiegamenti di server con bilanciatori di carico e altra infrastruttura di routing devono assicurare che questa infrastruttura instradi in modo coerente i pacchetti all'istanza del server che ha lo stato della connessione, anche se cambiano indirizzi, porte o connection ID. Ciò potrebbe richiedere coordinamento tra server e infrastruttura. Un metodo per ottenere questo implica la codifica di informazioni di routing nel connection ID. Per un esempio di questa tecnica, vedere [QUIC-LB].

11.2. Mitigare la linkability di timing con la migrazione del Connection ID (Mitigating Timing Linkability with Connection ID Migration)​

Se gli endpoint QUIC non emettono connection ID freschi, allora i client non possono ridurre la linkability della migrazione di indirizzo usandoli. Scegliere valori che non sono collegabili a un osservatore esterno assicura che l'attività su percorsi diversi non possa essere correlata banalmente usando il connection ID.

Sebbene schemi di generazione di connection ID sufficientemente robusti mitighino i problemi di linkability, non forniscono protezione completa. L'analisi delle vite dei 6-tuple (indirizzi di origine e destinazione nonché il Connection ID migrato) può esporre comunque questi collegamenti.

Nel caso in cui la migrazione della connessione in un pool di server sia rara, è banale per un osservatore associare due connection ID. Al contrario, dove ogni server gestisce più migrazioni simultanee, anche una mappatura di server esposta può essere informazione insufficiente.

Le mitigazioni più efficienti per questi attacchi passano attraverso la progettazione di rete e/o le pratiche operative, usando un'architettura di bilanciamento del carico che carica più flussi su un singolo indirizzo lato server, coordinando il timing delle migrazioni nel tentativo di aumentare il numero di migrazioni simultanee in un dato momento, o usando altri mezzi.

11.3. Usare il Retry del server per il reindirizzamento (Using Server Retry for Redirection)​

QUIC fornisce un pacchetto Retry che può essere inviato da un server in risposta al pacchetto Initial del client. Il server può scegliere un nuovo connection ID in quel pacchetto e il client ritenterà inviando un altro pacchetto Initial client con il connection ID selezionato dal server. Questo meccanismo può essere usato per reindirizzare una connessione a un server diverso, ad es. per ragioni di prestazioni o quando i server in un pool di server sono aggiornati gradualmente e quindi possono supportare diverse versioni di QUIC.

In questo caso, si assume che tutti i server appartenenti a un certo pool siano serviti in cooperazione con bilanciatori di carico che inoltrano il traffico in base al connection ID. Un server può scegliere il connection ID nel pacchetto Retry in modo che il bilanciatore di carico reindirizzi il successivo pacchetto Initial a un server diverso in quel pool. In alternativa, il bilanciatore di carico può offrire direttamente un offload Retry come ulteriormente descritto in [QUIC-RETRY].

L'approccio descritto nella Sezione 4 di [RFC5077] per costruire ticket di ripresa TLS fornisce un esempio che può essere applicato anche ai token di validazione. Tuttavia, l'uso di algoritmi crittografici più moderni è altamente raccomandato.

12. Quality of Service (QoS) e Diffserv Code Point (DSCP)​

QUIC, come definito in [QUIC], ha un singolo controllore di congestione e gestore di recovery. Questo progetto assume che tutti i pacchetti di una connessione QUIC, o almeno con lo stesso 5-tupla {indirizzo dest, indirizzo sorgente, protocollo, porta dest, porta sorgente}, che hanno lo stesso Diffserv Code Point (DSCP) [RFC2475] riceveranno un trattamento di rete simile poiché il feedback su perdita o ritardo di ciascun pacchetto è usato come input al controllore di congestione. Pertanto, i pacchetti appartenenti alla stessa connessione dovrebbero usare un singolo DSCP. La Sezione 5.1 di [RFC7657] fornisce una discussione delle interazioni Diffserv con i protocolli di trasporto a datagrammi [RFC7657] (a questo riguardo, le interazioni con QUIC assomigliano a quelle di Stream Control Transmission Protocol (SCTP)).

Quando si multiplexano più flussi su una singola connessione QUIC, il valore DSCP selezionato dovrebbe essere quello associato alla priorità più alta richiesta per tutti i flussi multiplexati.

Se è desiderato un trattamento di rete differenziale, ad es. mediante l'uso di DSCP diversi, possono essere usate più connessioni QUIC verso lo stesso server. In generale, è raccomandato minimizzare il numero di connessioni QUIC verso lo stesso server per evitare overhead aumentato e, più importante, controllo di congestione concorrente.

Come in altri usi di Diffserv, quando un pacchetto entra in un segmento di rete che non supporta il valore DSCP, ciò potrebbe risultare nella connessione che non riceve il trattamento di rete che si aspetta. Il valore DSCP in questo pacchetto potrebbe anche essere rimarcato man mano che il pacchetto viaggia lungo il percorso di rete, cambiando il trattamento richiesto.

13. Uso delle versioni e dell'handshake crittografico (Use of Versions and Cryptographic Handshake)​

Il versioning in QUIC può cambiare completamente il comportamento del protocollo, eccetto per il significato di alcuni campi di header che sono stati dichiarati invarianti [QUIC-INVARIANTS]. Una versione di QUIC con un numero di versione più alto non fornirà necessariamente un servizio migliore ma potrebbe semplicemente fornire un insieme di funzionalità diverso. In quanto tale, un'applicazione deve essere in grado di selezionare quali versioni di QUIC vuole usare.

Una nuova versione potrebbe usare uno schema di cifratura diverso da TLS 1.3 o superiore. [QUIC] specifica i requisiti per l'handshake crittografico come attualmente realizzato da TLS 1.3 e descritto in una specifica separata [QUIC-TLS]. Questa suddivisione è eseguita per abilitare un versioning leggero con handshake crittografici diversi.

Il registro "QUIC Versions" stabilito in [QUIC] consente registrazioni provvisorie per la sperimentazione. La registrazione, anche di versioni sperimentali, è importante per evitare collisioni. Le versioni sperimentali non dovrebbero essere usate a lungo termine né registrate come permanenti per minimizzare il rischio di fingerprinting basato sul numero di versione.

14. Abilitare il dispiegamento di nuove versioni (Enabling Deployment of New Versions)​

QUIC versione 1 non specifica un meccanismo di negoziazione della versione nella specifica di base, ma [QUIC-VERSION-NEGOTIATION] propone un'estensione che fornisce negoziazione di versione compatibile.

Questo approccio usa un meccanismo di dispiegamento a tre stadi, abilitando il rollout progressivo e la sperimentazione con più versioni attraverso un grande dispiegamento di server. In questo approccio, tutti i server nel dispiegamento devono accettare connessioni usando una nuova versione (stadio 1) prima che qualsiasi server la annunci (stadio 2), e l'autenticazione della nuova versione (stadio 3) procede solo dopo che l'annuncio di quella versione è completamente dispiegato.

Vedere la Sezione 5 di [QUIC-VERSION-NEGOTIATION] per i dettagli.

15. Servizio di datagrammi non affidabili su QUIC (Unreliable Datagram Service over QUIC)​

[RFC9221] specifica un'estensione QUIC per abilitare l'invio e la ricezione di datagrammi non affidabili su QUIC. A differenza dell'operare direttamente su UDP, le applicazioni che usano il servizio di datagrammi QUIC non devono implementare il proprio controllo di congestione, secondo [RFC8085], poiché i datagrammi QUIC sono controllati per congestione.

I datagrammi QUIC non sono controllati per flusso e in quanto tali pezzi di dati possono essere scartati se il ricevitore è sovraccarico. Mentre il servizio di trasmissione affidabile di QUIC fornisce un'interfaccia basata su flussi per inviare e ricevere dati in ordine su più flussi QUIC, il servizio di datagrammi ha un'interfaccia basata su messaggi non ordinata. Se necessario, un framing a livello applicativo può essere usato sopra per consentire a flussi separati di datagrammi non affidabili di essere multiplexati su una connessione QUIC.

16. Considerazioni IANA (IANA Considerations)​

Il presente documento non ha azioni per IANA; tuttavia, si noti che la Sezione 8 raccomanda che un'applicazione che ha già registrato una porta TCP ma vuole specificare QUIC come trasporto dovrebbe registrare una porta UDP analoga alla propria registrazione TCP esistente.

17. Considerazioni sulla sicurezza (Security Considerations)​

Vedere le considerazioni sulla sicurezza in [QUIC] e [QUIC-TLS]; le considerazioni sulla sicurezza per il protocollo di trasporto sottostante sono rilevanti per le applicazioni che usano QUIC. Le considerazioni su linkability, attacchi di replay e casualità discusse in [QUIC-TLS] dovrebbero essere prese in considerazione quando si dispiega e si usa QUIC.

Inoltre, la migrazione a un nuovo indirizzo espone un collegamento tra indirizzi del client al server e può esporre questo collegamento anche al percorso se il connection ID non può essere cambiato o se i flussi possono altrimenti essere correlati. Quando la migrazione è supportata, ciò deve essere considerato rispetto alla privacy dell'utente.

Gli sviluppatori di applicazioni dovrebbero notare che qualsiasi fallback usano quando QUIC non può essere usato a causa del blocco di rete di UDP dovrebbe garantire le stesse proprietà di sicurezza di QUIC. Se ciò non è possibile, la connessione dovrebbe fallire per consentire all'applicazione di gestire esplicitamente il fallback a un'alternativa meno sicura. Vedere la Sezione 2.

Inoltre, [QUIC-HTTP] fornisce considerazioni sulla sicurezza specifiche per HTTP. Tuttavia, discussioni come sugli attacchi cross-protocol, l'analisi del traffico e il padding, o la migrazione potrebbero essere rilevanti anche per altre applicazioni che usano QUIC.

18. Riferimenti (References)​

18.1. Riferimenti normativi (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.

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

18.2. Riferimenti informativi (Informative References)​

[Edeline16] Edeline, K., Kühlewind, M., Trammell, B., Aben, E., and B. Donnet, "Using UDP for Internet Transport Evolution", DOI 10.48550/arXiv.1612.07816, 22 December 2016, https://arxiv.org/abs/1612.07816.

[Hatonen10] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, "An Experimental Study of Home Gateway Characteristics", Proc. ACM IMC 2010, November 2010, <https://conferences.sigcomm.org/imc/2010/papers/ p260.pdf>.

[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, https://www.rfc-editor.org/info/rfc8470.

[PaaschNanog] Paasch, C., "Network support for TCP Fast Open", NANOG 67 Presentation, 13 June 2016, <https://www.nanog.org/sites/default/files/ Paasch_Network_Support.pdf>.

[QUIC-ACK-FREQUENCY] Iyengar, J. and I. Swett, "QUIC Acknowledgement Frequency", Work in Progress, Internet-Draft, draft-ietf- quic-ack-frequency-02, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic- ack-frequency-02>.

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

[QUIC-LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating Routable QUIC Connection IDs", Work in Progress, Internet- Draft, draft-ietf-quic-load-balancers-14, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic- load-balancers-14>.

[QUIC-MANAGEABILITY] Kühlewind, M. and B. Trammell, "Manageability of the QUIC Transport Protocol", RFC 9312, DOI 10.17487/RFC9312, September 2022, https://www.rfc-editor.org/info/rfc9312.

[QUIC-RETRY] Duke, M. and N. Banks, "QUIC Retry Offload", Work in Progress, Internet-Draft, draft-ietf-quic-retry-offload- 00, 25 May 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-quic-retry-offload-00>.

[QUIC-VERSION-NEGOTIATION] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-version-negotiation-10, 27 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic- version-negotiation-10>.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, https://www.rfc-editor.org/info/rfc1034.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, https://www.rfc-editor.org/info/rfc2475.

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, https://www.rfc-editor.org/info/rfc5077.

[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, https://www.rfc-editor.org/info/rfc5382.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, https://www.rfc-editor.org/info/rfc5905.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, https://www.rfc-editor.org/info/rfc6335.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, https://www.rfc-editor.org/info/rfc6762.

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

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, https://www.rfc-editor.org/info/rfc7413.

[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, https://www.rfc-editor.org/info/rfc7657.

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

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, https://www.rfc-editor.org/info/rfc8085.

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, https://www.rfc-editor.org/info/rfc8981.

[RFC9218] Oku, K. and L. Pardue, "Extensible Prioritization Scheme for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022, https://www.rfc-editor.org/info/rfc9218.

[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, https://www.rfc-editor.org/info/rfc9221.

[SSDP] Donoho, A., Roe, B., Bodlaender, M., Gildred, J., Messer, A., Kim, Y., Fairman, B., and J. Tourzan, "UPnP Device Architecture 2.0", 17 April 2020, <https://openconnectivity.org/upnp-specs/UPnP-arch- DeviceArchitecture-v2.0-20200417.pdf>.

[Swett16] Swett, I., "QUIC Deployment Experience @Google", IETF96 QUIC BoF Presentation, 20 July 2016, <https://www.ietf.org/proceedings/96/slides/slides-96- quic-3.pdf>.

[TAPS-ARCH] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and C. Perkins, "An Architecture for Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-arch-14, 27 September 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-taps-arch-14>.

[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, https://www.rfc-editor.org/info/rfc8446.

[Trammell16] Trammell, B. and M. Kühlewind, "Internet Path Transparency Measurements using RIPE Atlas", RIPE 72 MAT Presentation, 25 May 2016, <https://ripe72.ripe.net/wp-content/uploads/ presentations/86-atlas-udpdiff.pdf>.

Ringraziamenti (Acknowledgments)​

Un ringraziamento speciale ai revisori Last Call Chris Lonvick e Ines Robles.

Questo lavoro è stato parzialmente supportato dalla Commissione europea nell'ambito dell'accordo di sovvenzione Horizon 2020 n. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI) e dalla Segreteria di Stato svizzera per la formazione, la ricerca e l'innovazione con contratto n. 15.0268. Questo supporto non implica approvazione.

Collaboratori (Contributors)​

Le seguenti persone hanno contribuito testo significativo o feedback su questo documento:

Gorry Fairhurst, Ian Swett, Igor Lubashev, Lucas Pardue, Mike Bishop, Mark Nottingham, Martin Duke, Martin Thomson, Sean Turner, Tommy Pauly

Indirizzi degli autori (Authors' Addresses)​

Mirja Kühlewind
Ericsson
Email: [email protected]

Brian Trammell
Google Switzerland GmbH
Gustav-Gull-Platz 1
CH-8004 Zurich
Switzerland
Email: [email protected]