2. Encapsulating Security Payload Packet Format (Formato del pacchetto ESP)
L'header di protocollo (esterno) (IPv4, IPv6 o Extension) che precede immediatamente l'header ESP DEVE contenere il valore 50 nel suo campo Protocol (IPv4) o Next Header (IPv6, Extension) (vedere la pagina web IANA su http://www.iana.org/assignments/protocol-numbers). La figura 1 illustra il formato di livello superiore di un pacchetto ESP. Il pacchetto inizia con due campi da 4 byte (Security Parameters Index (SPI) e Sequence Number). Questi campi sono seguiti dai Payload Data, che hanno una sottostruttura che dipende dalla scelta dell'algoritmo di crittografia e della modalità, e dall'uso del padding TFC, che verrà esaminato più dettagliatamente in seguito. I Payload Data sono seguiti dai campi Padding e Pad Length, e dal campo Next Header. Il campo opzionale Integrity Check Value (ICV) completa il pacchetto.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 1. Formato di livello superiore di un pacchetto ESP
* Se nel campo Payload sono inclusi dati di sincronizzazione crittografica, ad esempio un vettore di inizializzazione (IV, vedere sezione 2.3), solitamente non vengono crittografati di per sé, sebbene siano spesso indicati come parte del testo cifrato.
Il trailer ESP (trasmesso) consiste nei campi Padding, Pad Length e Next Header. Dati aggiuntivi del trailer ESP impliciti (che non vengono trasmessi) sono inclusi nel calcolo dell'integrità, come descritto di seguito.
Se il servizio di integrità è selezionato, il calcolo dell'integrità comprende il SPI, il Sequence Number, i Payload Data e il trailer ESP (esplicito e implicito).
Se il servizio di riservatezza è selezionato, il testo cifrato consiste nei Payload Data (ad eccezione di eventuali dati di sincronizzazione crittografica che possono essere inclusi) e nel trailer ESP (esplicito).
Come notato sopra, i Payload Data possono avere una sottostruttura. Un algoritmo di crittografia che richiede un vettore di inizializzazione (IV) esplicito, ad esempio la modalità Cipher Block Chaining (CBC), spesso antepone ai Payload Data da proteggere tale valore. Alcune modalità di algoritmo combinano crittografia e integrità in un'unica operazione; questo documento si riferisce a tali modalità di algoritmo come "algoritmi in modalità combinata". L'adattamento degli algoritmi in modalità combinata richiede che l'algoritmo descriva esplicitamente la sottostruttura del payload utilizzata per trasmettere i dati di integrità.
Alcuni algoritmi in modalità combinata forniscono integrità solo per i dati crittografati, mentre altri possono fornire integrità per alcuni dati aggiuntivi che non sono crittografati per la trasmissione. Poiché i campi SPI e Sequence Number richiedono integrità come parte del servizio di integrità e non sono crittografati, è necessario garantire che sia loro fornita integrità ogni volta che il servizio è selezionato, indipendentemente dallo stile di modalità algoritmica combinata impiegata.
Quando viene impiegato un algoritmo in modalità combinata, l'algoritmo stesso dovrebbe restituire sia il testo in chiaro decrittografato sia un'indicazione di superamento/fallimento per il controllo di integrità. Per gli algoritmi in modalità combinata, l'ICV che normalmente appare alla fine del pacchetto ESP (quando l'integrità è selezionata) può essere omesso. Quando l'ICV è omesso e l'integrità è selezionata, è responsabilità dell'algoritmo in modalità combinata codificare nei Payload Data un mezzo equivalente all'ICV per verificare l'integrità del pacchetto.
Se un algoritmo in modalità combinata offre integrità solo ai dati crittografati, sarà necessario replicare il SPI e il Sequence Number come parte dei Payload Data.
Infine, viene introdotta una nuova disposizione per inserire il padding per la riservatezza del flusso di traffico dopo i Payload Data e prima del trailer ESP. La figura 2 illustra questa sottostruttura per i Payload Data. (Nota: questo diagramma mostra i bit sul filo. Quindi anche se vengono utilizzati numeri di sequenza estesi, verranno trasmessi solo 32 bit del Sequence Number (vedere sezione 2.2.1).)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 2. Sottostruttura dei Payload Data
* Se viene utilizzata la modalità tunnel, l'implementazione IPsec può aggiungere padding Traffic Flow Confidentiality (TFC) (vedere sezione 2.4) dopo i Payload Data e prima del campo Padding (0-255 byte).
Se viene impiegata una modalità di algoritmo combinato, l'ICV esplicito mostrato nelle figure 1 e 2 può essere omesso (vedere sezione 3.3.2.2 di seguito). Poiché algoritmi e modalità sono fissati quando viene stabilita una SA, il formato dettagliato dei pacchetti ESP per una data SA (inclusa la sottostruttura dei Payload Data) è fissato per tutto il traffico sulla SA.
Le tabelle seguenti si riferiscono ai campi nelle figure precedenti e illustrano come diverse categorie di opzioni algoritmiche, ciascuna con un diverso modello di elaborazione, influenzano i campi sopra indicati. I dettagli di elaborazione sono descritti nelle sezioni successive.
Tabella 1. Algoritmi di crittografia e integrità separati
| Campo | Numero di byte | Richiesto [1] | Copertura crittografia | Copertura integrità | Trasmesso |
|---|---|---|---|---|---|
| SPI | 4 | M | Y | plain | |
| Seq# (bit bassi) | 4 | M | Y | plain | |
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher[3] |
| TFC padding [4] | variable | O | Y | Y | cipher[3] |
| Padding | 0-255 | M | Y | Y | cipher[3] |
| Pad Length | 1 | M | Y | Y | cipher[3] |
| Next Header | 1 | M | Y | Y | cipher[3] |
| Seq# (bit alti) | 4 | if ESN [5] | Y | not xmtd | |
| ICV Padding | variable | if need | Y | not xmtd | |
| ICV | variable | M [6] | plain |
[1] M = obbligatorio; O = opzionale; D = fittizio
[2] Se modalità tunnel -> datagramma IP; Se modalità trasporto -> header successivo e dati
[3] testo cifrato se la crittografia è stata selezionata
[4] Può essere utilizzato solo se il payload specifica la sua lunghezza "reale"
[5] Vedere sezione 2.2.1
[6] obbligatorio se viene utilizzato un algoritmo di integrità separato
Tabella 2. Algoritmi in modalità combinata
| Campo | Numero di byte | Richiesto [1] | Copertura crittografia | Copertura integrità | Trasmesso |
|---|---|---|---|---|---|
| SPI | 4 | M | plain | ||
| Seq# (bit bassi) | 4 | M | plain | ||
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher |
| TFC padding [3] | variable | O | Y | Y | cipher |
| Padding | 0-255 | M | Y | Y | cipher |
| Pad Length | 1 | M | Y | Y | cipher |
| Next Header | 1 | M | Y | Y | cipher |
| Seq# (bit alti) | 4 | if ESN [4] | Y | [5] | |
| ICV Padding | variable | if need | Y | [5] | |
| ICV | variable | O [6] | plain |
[1] M = obbligatorio; O = opzionale; D = fittizio
[2] Se modalità tunnel -> datagramma IP; Se modalità trasporto -> header successivo e dati
[3] Può essere utilizzato solo se il payload specifica la sua lunghezza "reale"
[4] Vedere sezione 2.2.1
[5] La scelta dell'algoritmo determina se questi vengono trasmessi, ma in entrambi i casi il risultato è invisibile a ESP
[6] La specifica dell'algoritmo determina se questo campo è presente
Le sottosezioni seguenti descrivono i campi nel formato dell'header. "Opzionale" significa che il campo viene omesso se l'opzione non è selezionata, cioè non è presente né nel pacchetto così come trasmesso né come formattato per il calcolo di un ICV (vedere sezione 2.7). Se un'opzione è selezionata o meno è determinato come parte dell'istituzione dell'associazione di sicurezza (SA). Quindi, il formato dei pacchetti ESP per una data SA è fisso per la durata della SA. Al contrario, i campi "obbligatori" sono sempre presenti nel formato del pacchetto ESP, per tutte le SA.
Nota: tutti gli algoritmi crittografici utilizzati in IPsec si aspettano il loro input nell'ordine dei byte di rete canonico (vedere l'appendice di RFC 791 [Pos81]) e generano il loro output nell'ordine dei byte di rete canonico. Anche i pacchetti IP vengono trasmessi nell'ordine dei byte di rete.
ESP non contiene un numero di versione, pertanto se ci sono preoccupazioni sulla compatibilità all'indietro, DEVONO essere affrontate utilizzando un meccanismo di segnalazione tra i due peer IPsec per garantire versioni compatibili di ESP (ad esempio, Internet Key Exchange (IKEv2) [Kau05]) o un meccanismo di configurazione fuori banda.