Passa al contenuto principale

9. Migrazione della connessione

9. Migrazione della connessione

L'uso di un ID di connessione consente alle connessioni di sopravvivere ai cambiamenti degli indirizzi degli endpoint (indirizzo IP e porta), come quelli causati da un endpoint che migra a una nuova rete. Questa sezione descrive il processo mediante il quale un endpoint migra a un nuovo indirizzo.

Il design di QUIC si basa sul fatto che gli endpoint mantengano un indirizzo stabile per la durata dell'handshake. Un endpoint NON DEVE avviare la migrazione della connessione prima che l'handshake sia confermato, come definito nella Sezione 4.1.2 di [QUIC-TLS].

Un client è responsabile dell'avvio di tutte le migrazioni. I server non inviano pacchetti non-probing (vedere Sezione 9.1) verso un indirizzo client finché non vedono un pacchetto non-probing da quell'indirizzo.

9.1 Sondaggio di un nuovo percorso

Un endpoint PUÒ sondare la raggiungibilità del peer da un nuovo indirizzo locale utilizzando la validazione del percorso (Sezione 8.2) prima di migrare la connessione al nuovo indirizzo locale.

9.2 Avvio della migrazione della connessione

Un endpoint può migrare una connessione a un nuovo indirizzo locale inviando pacchetti contenenti frame non-probing da quell'indirizzo.

9.3 Risposta alla migrazione della connessione

La ricezione di un pacchetto da un nuovo indirizzo peer contenente un frame non-probing indica che il peer è migrato a quell'indirizzo.

9.3.1 Spoofing dell'indirizzo del peer

È possibile che un peer stia falsificando il suo indirizzo sorgente per far sì che un endpoint invii quantità eccessive di dati a un host non consenziente.

9.3.2 Spoofing dell'indirizzo on-path

Un attaccante on-path potrebbe causare una migrazione di connessione spuria copiando e inoltrando un pacchetto con informazioni di indirizzo falsificate.

9.3.3 Inoltro di pacchetti off-path

Un attaccante off-path che può osservare i pacchetti potrebbe inoltrare copie di pacchetti genuini agli endpoint.

9.4 Rilevamento della perdita e controllo della congestione

La capacità disponibile su un nuovo percorso potrebbe non essere la stessa del vecchio percorso. I pacchetti inviati sul vecchio percorso NON DEVONO contribuire al controllo della congestione o alla stima dell'RTT per il nuovo percorso.

9.5 Implicazioni sulla privacy della migrazione della connessione

L'uso di un ID di connessione stabile su più percorsi di rete consente a un osservatore passivo di correlare l'attività tra quei percorsi.

9.6 Indirizzo preferito del server

QUIC consente ai server di accettare connessioni su un indirizzo IP e trasferire queste connessioni a un indirizzo più preferito poco dopo l'handshake.

9.6.1 Comunicazione di un indirizzo preferito

Un server comunica un indirizzo preferito includendo il parametro di trasporto preferred_address nell'handshake TLS.

9.6.2 Migrazione a un indirizzo preferito

Un client che migra a un indirizzo preferito DEVE validare il nuovo percorso prima di inviare dati a quell'indirizzo.

9.6.3 Interazione tra migrazione del client e indirizzo preferito

Un client potrebbe aver bisogno di eseguire una migrazione della connessione prima di essere migrato all'indirizzo preferito del server.

9.7 Uso dell'etichetta di flusso IPv6 e migrazione

Gli endpoint che inviano dati utilizzando IPv6 DOVREBBERO applicare un'etichetta di flusso IPv6 in conformità con [RFC6437], a meno che l'API locale non consenta l'impostazione di etichette di flusso IPv6.