12. Summary of changes required in IP and TCP (Riepilogo delle modifiche richieste in IP e TCP)

12. Summary of changes required in IP and TCP (Riepilogo delle modifiche richieste in IP e TCP)

Questo documento specifica i due bit nell'intestazione IP per ECN. Il codepoint not-ECT indica che il protocollo di trasporto ignorerà il codepoint CE. Questo è il valore predefinito del codepoint ECN. Il codepoint ECT indica che il protocollo di trasporto è disposto e in grado di partecipare a ECN.

I router impostano il codepoint CE per indicare congestione ai nodi finali. Il codepoint CE nell'intestazione del pacchetto NON DEVE mai essere resettato da un router.

TCP richiede tre modifiche per ECN: una fase di setup e due nuovi flag nell'intestazione TCP. Il flag ECN-Echo viene utilizzato dal ricevitore di dati per informare il mittente di dati della ricezione di un pacchetto CE. Il flag Congestion Window Reduced (CWR, finestra di congestione ridotta) viene utilizzato dal mittente di dati per informare il ricevitore di dati che la finestra di congestione è stata ridotta.

Quando si utilizza ECN (Explicit Congestion Notification, notifica di congestione esplicita), è richiesto che le indicazioni di congestione generate all'interno di un tunnel IP non vengano perse all'uscita del tunnel. Specifichiamo modifiche lievi al trattamento del campo ECN da parte del protocollo IP durante l'incapsulamento e la decapsulazione per consentire ai flussi che subiscono il transito di un tunnel IP di utilizzare ECN.

Sono specificate due opzioni per ECN nei tunnel:

1. Un'opzione a funzionalità limitata (limited-functionality option), che non utilizza ECN all'interno del tunnel IP, impostando il campo ECN su not-ECT nell'intestazione esterna, e non modificando l'intestazione interna durante la decapsulazione.

2. Un'opzione a funzionalità completa (full-functionality option), impostando il campo ECN nell'intestazione esterna su not-ECT o su uno dei codepoint ECT, a seconda del campo ECN nell'intestazione interna. Durante la decapsulazione, se il codepoint CE è impostato nell'intestazione esterna e l'intestazione interna è impostata su uno dei codepoint ECT, il codepoint CE viene copiato nell'intestazione interna.

Per i tunnel IPsec, questo documento definisce anche un attributo opzionale della Security Association (SA, associazione di sicurezza) IPsec che consente la negoziazione dell'uso di ECN all'interno dei tunnel IPsec, così come un campo opzionale nel Security Association Database (database delle associazioni di sicurezza) per indicare se ECN è consentito in modalità tunnel su un SA. Le modifiche richieste per i tunnel IPsec che utilizzano ECN modificano RFC 2401 [RFC2401], che definisce l'architettura IPsec e specifica alcuni aspetti della sua implementazione. Il nuovo attributo SA IPsec è un'aggiunta agli attributi già definiti nella Sezione 4.5 di [RFC2407].

Questo documento rende obsoleto RFC 2481 "A Proposal to add Explicit Congestion Notification (ECN) to IP", che definiva ECN come protocollo sperimentale per la comunità Internet. Il resto di questa sezione descrive la relazione tra questo documento e il suo predecessore.

RFC 2481 includeva una breve discussione sull'uso di ECN con pacchetti incapsulati, notando che per le specifiche IPsec del tempo (gennaio 1999), i flussi non avrebbero potuto utilizzare ECN in modo sicuro se dovessero attraversare tunnel IPsec. RFC 2481 descriveva anche le modifiche che avrebbero potuto essere apportate alle specifiche dei tunnel IPsec per renderli compatibili con ECN.

Questo documento integra anche il lavoro completato dopo RFC 2481. Il primo è la descrizione dettagliata delle modifiche ai tunnel IPsec, insieme a un'ampia discussione sulle implicazioni di sicurezza di ECN (ora inclusa come Sezioni 18 e 19 di questo documento). Il secondo è l'estensione della discussione dai tunnel IPsec a tutti i tunnel IP. Poiché i tunnel IP più vecchi sono incompatibili con l'uso di ECN da parte dei flussi, il dispiegamento di ECN in Internet creerà una forte pressione affinché i tunnel IP più vecchi vengano aggiornati a versioni compatibili con ECN, utilizzando l'opzione a funzionalità limitata o completa.

Questo documento non affronta la questione dell'inclusione di ECN nei tunnel non-IP come MPLS, GRE, L2TP o PPTP. Un documento iniziale preliminare sull'aggiunta del supporto ECN a MPLS non è stato portato avanti.

Il terzo nuovo lavoro dopo RFC 2481 è la descrizione delle procedure ECN per i pacchetti ritrasmessi, ovvero che il codepoint ECT NON DOVREBBE essere impostato sui pacchetti ritrasmessi. La motivazione per questa specifica aggiuntiva è stata quella di eliminare una possibile via di attacchi denial-of-service contro connessioni TCP esistenti. Alcune implementazioni TCP con capacità ECN distribuite in precedenza potrebbero non conformarsi al (nuovo) requisito di non impostare il codepoint ECT sui pacchetti ritrasmessi; riteniamo che questo non causerà problemi significativi in pratica.

Questo documento estende anche leggermente la specifica della negoziazione ECN utilizzando i pacchetti SYN. Sebbene alcune implementazioni TCP con capacità ECN distribuite in precedenza potrebbero non conformarsi ai requisiti specificati in questo documento, riteniamo che ciò non causerà alcun problema di prestazioni o compatibilità per le connessioni TCP con endpoint che hanno una combinazione di implementazioni TCP.

Questo documento include anche la specifica del codepoint ECT(1), che può essere utilizzato da TCP come parte dell'implementazione del nonce ECN.