9.1 IP packets encapsulated in IP (Pacchetti IP incapsulati in IP)
9.1 IP packets encapsulated in IP (Pacchetti IP incapsulati in IP)
L'incapsulamento dell'intestazione del pacchetto IP nei tunnel è utilizzato in molti luoghi, inclusi IPsec e IP in IP [RFC2003]. Questa sezione considera le questioni relative all'interazione tra ECN e i tunnel IP e specifica due soluzioni alternative. Questa discussione è integrata dalla discussione di RFC 2983 sull'interazione tra i servizi differenziati e varie forme di tunnel IP [RFC 2983], poiché i servizi differenziati utilizzano i sei bit rimanenti del byte dell'intestazione IP utilizzati da ECN (si veda la Figura 2 nella Sezione 5).
Alcune modalità di tunnel IP si basano sull'aggiunta di una nuova intestazione IP "esterna" che incapsula l'intestazione IP "interna" o originale e il suo pacchetto associato. In molti casi, la nuova intestazione IP "esterna" può essere aggiunta e rimossa in punti intermedi lungo il percorso della connessione, consentendo alla rete di stabilire un tunnel senza richiedere la partecipazione degli endpoint. Ci riferiremo ai tunnel in cui l'intestazione esterna viene scartata all'uscita del tunnel come "simple tunnels" (tunnel semplici).
ECN utilizza il campo ECN nell'intestazione IP per la segnalazione tra i router e gli endpoint della connessione. Il trattamento del campo ECN nell'intestazione IP da parte di ECN interagisce con i tunnel IP. Nei tunnel IP semplici, il byte contenente il campo ECN viene copiato o mappato dall'intestazione IP interna all'intestazione IP esterna all'ingresso del tunnel IP, e la copia di quel campo dell'intestazione esterna viene scartata all'uscita del tunnel IP. Se l'intestazione esterna viene semplicemente scartata all'uscita senza attenzione al trattamento del campo ECN, e un router con capacità ECN imposta il codepoint CE (Congestion Experienced, congestione sperimentata) in un pacchetto in un tunnel IP semplice, questa indicazione verrebbe scartata all'uscita del tunnel, perdendo l'indicazione di congestione.
Pertanto, l'uso di ECN su tunnel IP semplici comporterebbe che i router tentano di inviare segnali di congestione agli endpoint utilizzando l'intestazione IP esterna, ma questi avvisi di congestione non arriverebbero mai perché l'intestazione esterna viene scartata nel punto di uscita del tunnel. RFC 2481 ha incontrato questo problema di ECN e IPsec in modalità tunnel e ha raccomandato di non utilizzare ECN con i tunnel IPsec semplici più vecchi, per evitare questo comportamento e le sue conseguenze. Quando ECN viene ampiamente distribuito, i tunnel semplici che potrebbero trasportare traffico con capacità ECN dovranno essere modificati. Se il traffico con capacità ECN viene trasportato attraverso un tunnel semplice su un router congestionato con capacità ECN, questo potrebbe portare allo scarto dei pacchetti successivi di quel flusso all'aumentare della dimensione media della coda presso il router congestionato, come discusso nella Sezione 8 sopra.
Dal punto di vista della sicurezza, l'uso di ECN nell'intestazione esterna di un tunnel IP potrebbe sollevare preoccupazioni sulla sicurezza poiché un avversario potrebbe manomettere le informazioni ECN che si propagano oltre gli endpoint del tunnel. Sulla base dell'analisi di queste questioni e del rischio risultante nelle Sezioni 18 e 19, il nostro approccio generale è quello di rendere il supporto per ECN un'opzione per i tunnel IP, in modo che un tunnel IP possa essere specificato o configurato per utilizzare o non utilizzare ECN nell'intestazione esterna del tunnel. Pertanto, in ambienti o protocolli di tunneling in cui si ritiene che i rischi dell'uso di ECN superino i suoi benefici, il tunnel può semplicemente non utilizzare ECN nell'intestazione esterna. Quindi l'unica indicazione di congestione sperimentata presso i router all'interno del tunnel sarà tramite la perdita di pacchetti.
Il risultato è che ci sono due opzioni praticabili per il comportamento di una connessione con capacità ECN su un tunnel IP (inclusi i tunnel IPsec):
-
Un'opzione a funzionalità limitata (limited-functionality option), in cui ECN viene preservato nell'intestazione interna ma disabilitato nell'intestazione esterna. In questo caso, l'unico meccanismo per indicare la congestione che si verifica all'interno del tunnel è tramite pacchetti persi.
-
Un'opzione a funzionalità completa (full-functionality option), in cui ECN è supportato sia nelle intestazioni interne che esterne, e gli avvisi di congestione dai nodi all'interno del tunnel vengono propagati agli endpoint.
Il supporto di queste opzioni richiede diversi gradi di modifiche al trattamento delle intestazioni IP all'ingresso e all'uscita del tunnel. Un piccolo sottoinsieme di queste modifiche richieste solo per supportare l'opzione a funzionalità limitata è sufficiente per eliminare eventuali incompatibilità tra ECN e i tunnel IP.
Un obiettivo di questo documento è fornire indicazioni sui compromessi tra le opzioni a funzionalità limitata e completa. Le Sezioni 18 e 19 discutono in dettaglio i potenziali impatti di un avversario che modifica il campo ECN.