6.1.5 Retransmitted TCP packets (Pacchetti TCP ritrasmessi)
6.1.5 Retransmitted TCP packets (Pacchetti TCP ritrasmessi)
Questo documento specifica che un'implementazione TCP con capacità ECN NON DEVE impostare nessuno dei due codepoint ECT (ECT(0) o ECT(1)) nell'intestazione IP dei pacchetti ritrasmessi, e che un ricevitore di dati TCP DOVREBBE ignorare il campo ECN sui pacchetti in arrivo che arrivano fuori dalla finestra corrente del ricevitore. Questo per rafforzare la sicurezza contro gli attacchi denial-of-service, così come la robustezza contro le indicazioni di congestione ECN per i pacchetti successivamente scartati nella rete.
Innanzitutto, notiamo che se il mittente TCP imposta il codepoint ECT sui pacchetti ritrasmessi, allora se un pacchetto ritrasmesso inutilmente viene successivamente scartato nella rete, i nodi finali non riceverebbero mai l'indicazione di congestione dal router che imposta il codepoint CE. Pertanto, impostare il codepoint ECT sui pacchetti ritrasmessi è inconsistente con la consegna affidabile delle indicazioni di congestione, anche per i pacchetti successivamente scartati nella rete.
Inoltre, un attaccante in grado di falsificare l'indirizzo IP di origine del mittente TCP può inviare pacchetti con numeri di sequenza arbitrari, con il codepoint CE impostato nell'intestazione IP. Alla ricezione di questo pacchetto falsificato, il ricevitore di dati TCP determinerebbe che i dati non sono nella finestra di ricezione corrente e restituirebbe un riconoscimento duplicato. Definiamo un pacchetto out-of-window (fuori finestra) presso il ricevitore di dati TCP come un pacchetto che cade al di fuori della finestra corrente del ricevitore. Alla ricezione di un pacchetto fuori finestra, il ricevitore di dati TCP deve decidere se considerare il codepoint CE nell'intestazione del pacchetto come indicazione di congestione valida e quindi se restituire un'indicazione ECN-Echo al mittente di dati TCP. Se il ricevitore di dati TCP ignora il codepoint CE su un pacchetto fuori finestra, allora il mittente di dati TCP non riceverà questa indicazione di congestione, potenzialmente legittima, dalla rete, risultando in una violazione del controllo di congestione end-to-end. D'altra parte, se il ricevitore di dati TCP rispetta l'indicazione CE su un pacchetto fuori finestra e riporta l'indicazione di congestione al mittente di dati TCP, allora un nodo malevolo che crea pacchetti falsificati fuori finestra ha "attaccato" con successo la connessione TCP, costringendo il mittente di dati a ridurre (dimezzare) inutilmente la sua finestra di congestione. Per impedire questo attacco denial-of-service, specifichiamo che un mittente di dati TCP legittimo NON DEVE mai impostare il codepoint ECT sui pacchetti ritrasmessi, e che un ricevitore di dati TCP DOVREBBE ignorare il codepoint CE sui pacchetti fuori finestra.
Uno svantaggio di non impostare ECT(0) o ECT(1) sui pacchetti ritrasmessi è che nega la protezione ECN per i pacchetti ritrasmessi. Tuttavia, per una connessione TCP con capacità ECN in un ambiente completamente con capacità ECN con congestione lieve, l'istanza di pacchetti scartati a causa di congestione dovrebbe essere rara, e quindi le istanze di pacchetti ritrasmessi dovrebbero essere scarse. Se i pacchetti vengono ritrasmessi, allora esiste già una perdita di pacchetti che ECN non è riuscito a prevenire (da corruzione o da congestione).
Notiamo che se un router imposta il codepoint CE su un pacchetto con capacità ECN all'interno di una connessione TCP, allora la connessione TCP è garantita di ricevere quell'indicazione di congestione, o qualche altra indicazione di congestione all'interno della stessa finestra di dati, anche se quel pacchetto viene scartato o riordinato nella rete. Consideriamo due casi, quando il pacchetto viene successivamente ritrasmesso, e quando il pacchetto non viene successivamente ritrasmesso.
Nel primo caso, se il pacchetto viene scartato o ritardato, e viene ritrasmesso dal mittente di dati in un certo momento, allora la ritrasmissione è il risultato di una ritrasmissione veloce o un timeout di ritrasmissione per quel pacchetto o per qualche pacchetto precedente nella stessa finestra di dati. In questo caso, poiché il mittente di dati ha già ritrasmesso il pacchetto, sappiamo che il mittente di dati ha già risposto a un'indicazione di congestione per qualche pacchetto all'interno della stessa finestra di dati del pacchetto originale. Pertanto, anche se la prima trasmissione del pacchetto viene scartata o ritardata nella rete, con il codepoint CE impostato, e viene successivamente ignorata dal ricevitore di dati come pacchetto fuori finestra, questo non è un problema perché il mittente ha già risposto all'indicazione di congestione per quella finestra di dati.
Nel secondo caso, se il pacchetto non viene mai ritrasmesso dal mittente di dati, allora quel pacchetto è l'unica copia di quei dati ricevuta dal ricevitore di dati, e quindi arriva al ricevitore di dati come pacchetto in finestra, indipendentemente da quanto il pacchetto potrebbe essere stato ritardato o riordinato. In questo caso, se il codepoint CE era stato impostato sul pacchetto nella rete, questo sarebbe trattato come indicazione di congestione valida dal ricevitore di dati.