3.3. Outbound Packet Processing (Elaborazione dei pacchetti in uscita)

In modalità trasporto, il mittente incapsula le informazioni del protocollo di livello successivo tra i campi dell'intestazione ESP e del trailer ESP, e conserva l'intestazione IP specificata (e tutte le intestazioni di estensione IP nel contesto IPv6). In modalità tunnel, le intestazioni/estensioni IP esterne e interne possono essere correlate in vari modi. La costruzione dell'intestazione/delle estensioni IP esterne durante il processo di incapsulamento è descritta nel documento Security Architecture.

3.3.1. Security Association Lookup (Ricerca dell'associazione di sicurezza)

ESP viene applicato a un pacchetto in uscita solo dopo che un'implementazione IPsec determina che il pacchetto è associato a una SA che richiede l'elaborazione ESP. Il processo di determinazione di quale elaborazione IPsec, se presente, viene applicata al traffico in uscita è descritto nel documento Security Architecture.

3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation (Cifratura del pacchetto e calcolo ICV)

In questa sezione, parliamo in termini di cifratura sempre applicata a causa delle implicazioni di formattazione. Questo viene fatto con la comprensione che "nessuna riservatezza" è offerta utilizzando l'algoritmo di cifratura NULL (RFC 2410). Ci sono diverse opzioni algoritmiche.

3.3.2.1. Separate Confidentiality and Integrity Algorithms (Algoritmi di riservatezza e integrità separati)

Se vengono impiegati algoritmi di riservatezza e integrità separati, il mittente procede come segue:

Incapsulare (nel campo ESP Payload):
- per la modalità trasporto -- solo le informazioni del protocollo di livello successivo originale.
- per la modalità tunnel -- l'intero datagramma IP originale.
Aggiungere qualsiasi padding necessario -- Padding TFC opzionale e padding (di cifratura)
Cifrare il risultato utilizzando la chiave, l'algoritmo di cifratura e la modalità algoritmo specificati per la SA e utilizzando tutti i dati di sincronizzazione crittografica richiesti.
- Se sono indicati dati di sincronizzazione crittografica espliciti, ad esempio un IV, vengono inseriti nell'algoritmo di cifratura secondo la specifica dell'algoritmo e posizionati nel campo Payload.
- Se vengono impiegati dati di sincronizzazione crittografica impliciti, vengono costruiti e inseriti nell'algoritmo di cifratura secondo la specifica dell'algoritmo.
- Se viene selezionata l'integrità, la cifratura viene eseguita per prima, prima che l'algoritmo di integrità venga applicato, e la cifratura non comprende il campo ICV. Questo ordine di elaborazione facilita il rilevamento rapido e il rifiuto di pacchetti riprodotti o falsi da parte del ricevitore, prima di decifrare il pacchetto, riducendo potenzialmente l'impatto degli attacchi denial of service (DoS). Consente anche la possibilità di elaborazione parallela dei pacchetti al ricevitore, cioè la decifratura può avvenire in parallelo con il controllo dell'integrità. Si noti che poiché l'ICV non è protetto dalla cifratura, un algoritmo di integrità con chiave deve essere impiegato per calcolare l'ICV.
Calcolare l'ICV sul pacchetto ESP meno il campo ICV. Quindi, il calcolo dell'ICV comprende lo SPI, il numero di sequenza, i dati del payload, il padding (se presente), la lunghezza del padding e l'intestazione successiva. (Si noti che gli ultimi 4 campi saranno in forma di testo cifrato, perché la cifratura viene eseguita per prima.) Se l'opzione ESN è abilitata per la SA, i 32 bit di ordine superiore del numero di sequenza vengono aggiunti dopo il campo Next Header ai fini di questo calcolo, ma non vengono trasmessi.

Per alcuni algoritmi di integrità, la stringa di byte su cui viene eseguito il calcolo dell'ICV deve essere un multiplo di una dimensione di blocco specificata dall'algoritmo. Se la lunghezza del pacchetto ESP (come descritto sopra) non corrisponde ai requisiti di dimensione del blocco per l'algoritmo, il padding implicito DEVE essere aggiunto alla fine del pacchetto ESP. (Questo padding viene aggiunto dopo il campo Next Header, o dopo i 32 bit di ordine superiore del numero di sequenza, se ESN è selezionato.) La dimensione del blocco (e quindi la lunghezza del padding) è specificata dalla specifica dell'algoritmo di integrità. Questo padding non viene trasmesso con il pacchetto. Il documento che definisce un algoritmo di integrità DEVE essere consultato per determinare se il padding implicito è richiesto come descritto sopra. Se il documento non specifica una risposta a questa domanda, allora il default è assumere che il padding implicito sia richiesto (come necessario per far corrispondere la lunghezza del pacchetto alla dimensione del blocco dell'algoritmo.) Se sono necessari byte di padding ma l'algoritmo non specifica il contenuto del padding, allora gli ottetti di padding DEVONO avere un valore di zero.

3.3.2.2. Combined Confidentiality and Integrity Algorithms (Algoritmi di riservatezza e integrità combinati)

Se viene impiegato un algoritmo di riservatezza/integrità combinato, il mittente procede come segue:

Incapsulare nel campo ESP Payload Data:
- per la modalità trasporto -- solo le informazioni del protocollo di livello successivo originale.
- per la modalità tunnel -- l'intero datagramma IP originale.
Aggiungere qualsiasi padding necessario -- include il padding TFC opzionale e il padding (di cifratura).
Cifrare e proteggere l'integrità del risultato utilizzando la chiave e l'algoritmo in modalità combinata specificati per la SA e utilizzando tutti i dati di sincronizzazione crittografica richiesti.
- Se sono indicati dati di sincronizzazione crittografica espliciti, ad esempio un IV, vengono inseriti nell'algoritmo in modalità combinata secondo la specifica dell'algoritmo e posizionati nel campo Payload.
- Se vengono impiegati dati di sincronizzazione crittografica impliciti, vengono costruiti e inseriti nell'algoritmo di cifratura secondo la specifica dell'algoritmo.
- Il numero di sequenza (o numero di sequenza esteso, a seconda dei casi) e lo SPI sono input per l'algoritmo, poiché devono essere inclusi nel calcolo del controllo di integrità. I mezzi con cui questi valori sono inclusi in questo calcolo sono una funzione dell'algoritmo in modalità combinata impiegato e quindi non specificati in questo standard.
- Il campo ICV (esplicito) PUÒ essere parte del formato del pacchetto ESP quando viene impiegato un algoritmo in modalità combinata. Se non viene utilizzato, un campo analogo di solito farà parte del payload di testo cifrato. La posizione di tutti i campi di integrità e i mezzi con cui il numero di sequenza e lo SPI sono inclusi nel calcolo dell'integrità DEVONO essere definiti in un RFC che definisce l'uso dell'algoritmo in modalità combinata con ESP.

3.3.3. Sequence Number Generation (Generazione del numero di sequenza)

Il contatore del mittente viene inizializzato a 0 quando viene stabilita una SA. Il mittente incrementa il contatore del numero di sequenza (o ESN) per questa SA e inserisce i 32 bit di ordine inferiore del valore nel campo Sequence Number. Quindi, il primo pacchetto inviato utilizzando una data SA conterrà un numero di sequenza di 1.

Se l'anti-replay è abilitato (l'impostazione predefinita), il mittente verifica che il contatore non sia ciclato prima di inserire il nuovo valore nel campo Sequence Number. In altre parole, il mittente NON DEVE inviare un pacchetto su una SA se ciò causerebbe il ciclo del numero di sequenza. Un tentativo di trasmettere un pacchetto che comporterebbe un overflow del numero di sequenza è un evento verificabile. La voce del registro di audit per questo evento DOVREBBE includere il valore SPI, la data/ora corrente, l'indirizzo sorgente, l'indirizzo di destinazione e (in IPv6) l'ID di flusso in chiaro.

Il mittente presume che l'anti-replay sia abilitato per impostazione predefinita, a meno che non venga notificato diversamente dal ricevitore (vedere sezione 3.4.3). Quindi, il comportamento tipico di un'implementazione ESP richiede che il mittente stabilisca una nuova SA quando il numero di sequenza (o ESN) cicla, o in previsione di questo valore che cicla.

Se la chiave utilizzata per calcolare un ICV è distribuita manualmente, un'implementazione conforme NON DOVREBBE fornire il servizio anti-replay. Se un utente sceglie di impiegare l'anti-replay in combinazione con SA con chiave manuale, il contatore del numero di sequenza al mittente DEVE essere correttamente mantenuto attraverso riavvii locali, ecc., fino a quando la chiave non viene sostituita. (Vedere sezione 5.)

Se l'anti-replay è disabilitato (come indicato sopra), il mittente non ha bisogno di monitorare o resettare il contatore. Tuttavia, il mittente incrementa comunque il contatore e quando raggiunge il valore massimo, il contatore ritorna a zero. (Questo comportamento è raccomandato per le SA multicast multi-mittente, a meno che meccanismi anti-replay al di fuori dell'ambito di questo standard non siano negoziati tra il mittente e il ricevitore.)

Se ESN (vedere Appendice) è selezionato, solo i 32 bit di ordine inferiore del numero di sequenza vengono trasmessi nel campo Sequence Number, sebbene sia il mittente che il ricevitore mantengano contatori ESN completi a 64 bit. I 32 bit di ordine superiore sono inclusi nel controllo di integrità in modo specifico per algoritmo/modalità, ad esempio i 32 bit di ordine superiore possono essere aggiunti dopo il campo Next Header quando viene impiegato un algoritmo di integrità separato.

Nota: Se un ricevitore sceglie di non abilitare l'anti-replay per una SA, allora il ricevitore NON DOVREBBE negoziare ESN in un protocollo di gestione SA. L'uso di ESN crea una necessità per il ricevitore di gestire la finestra anti-replay (al fine di determinare il valore corretto per i bit di ordine superiore dell'ESN, che sono impiegati nel calcolo dell'ICV), che è generalmente contrario alla nozione di disabilitare l'anti-replay per una SA.

3.3.4. Fragmentation (Frammentazione)

Se necessario, la frammentazione viene eseguita dopo l'elaborazione ESP all'interno di un'implementazione IPsec. Quindi, ESP in modalità trasporto viene applicato solo a datagrammi IP completi (non a frammenti IP). Un pacchetto IP a cui è stato applicato ESP può essere frammentato dai router lungo il percorso, e tali frammenti devono essere riassemblati prima dell'elaborazione ESP al ricevitore. In modalità tunnel, ESP viene applicato a un pacchetto IP, che può essere un frammento di un datagramma IP. Ad esempio, un gateway di sicurezza o un'implementazione IPsec "bump-in-the-stack" o "bump-in-the-wire" (come definito nel documento Security Architecture) può applicare ESP in modalità tunnel a tali frammenti.

NOTA: Per la modalità trasporto -- Come menzionato alla fine della sezione 3.1.1, le implementazioni bump-in-the-stack e bump-in-the-wire potrebbero dover prima riassemblare un pacchetto frammentato dal livello IP locale, quindi applicare IPsec e quindi frammentare il pacchetto risultante.

NOTA: Per IPv6 -- Per le implementazioni bump-in-the-stack e bump-in-the-wire, sarà necessario esaminare tutte le intestazioni di estensione per determinare se esiste un'intestazione di frammentazione e quindi che il pacchetto necessita di riassemblaggio prima dell'elaborazione IPsec.

La frammentazione, sia eseguita da un'implementazione IPsec che da router lungo il percorso tra peer IPsec, riduce significativamente le prestazioni. Inoltre, il requisito per un ricevitore ESP di accettare frammenti per il riassemblaggio crea vulnerabilità di denial of service. Quindi, un'implementazione ESP PUÒ scegliere di non supportare la frammentazione e può contrassegnare i pacchetti trasmessi con il bit DF, per facilitare la scoperta del Path MTU (PMTU). In ogni caso, un'implementazione ESP DEVE supportare la generazione di messaggi ICMP PMTU (o segnalazione interna equivalente per implementazioni host native) per minimizzare la probabilità di frammentazione. I dettagli del supporto richiesto per la gestione MTU sono contenuti nel documento Security Architecture.