Consideriamo la figura sopra.
R1 mantiene delle informazioni di stato sulla SA che includono:

• un identificatore a 32 bit della SA, chiamato Security Parameter Index (SPI)
• l'interfaccia della SA (in questo caso 200.168.1.100) e l'interfaccia di destinazione della SA (in questo caso 193.68.2.23)
• il tipo di cifratura da usare (per esempio 3DES con CBC)
• la chiave di cifratura
• il tipo di controllo di integrità (per esempio HMAC con MD5)
• la chiave di autenticazione
  Quando il router R1 ha bisogno di costruire un datagramma IPsec per inoltrarlo nella SA in figura, il router accede a queste informazioni di stato per determinare come dovrebbe autenticare e cifrare il datagramma. Allo stesso modo il router R2 mantiene le stesse informazioni di stato per questa SA e userà tali informazioni per autenticare e decifrare qualsiasi datagramma IPsec che arriva da essa.
  Un'entità IPsec (router o host) spesso mantiene informazioni di stato per diverse SA. Per esempio nella figura ce abbiamo visto prima, in cui vi sono n impiegati, la sede centrale deve mantenere SA. Un'entità IPsec salva le informazioni riguardo le SA in un database interno, una struttura dati all'interno del kernel del sistema operativo, chiamato Security Association Database.

Avendo fatto una panoramica sulle SA, possiamo adesso descrivere il datagramma IPsec.
IPsec ha due formati di pacchetto, uno chiamato tunnel mode e l'altro chiamato transport mode. La modalità tunnel è più appropriata della modalità trasporto per la creazione di VPN.
Partiamo dal descrivere il formato dei pacchetti di IPsec, potrebbe risultare un tantino noioso, ma vedremo tra poco che i datagrammi IPsec assomigliano ad una nota specialità messicana: l'enchilada.

Di seguito il formato di un pacchetto IPsec.
Supponiamo che il router R1 riceve un normale datagramma IPv4 dall'host 172.16.1.17 (all'interno della sede centrale) che è destinato all'host 172.16.2.48 (all'interno della filiale). R1 usa i seguenti passi per convertire il datagramma IPv4 vanilla in un datagramma IPsec:

• Aggiunge all'estremità di destra del datagramma IP originale (che ha include i suoi header originali) un campo ESP trailer
• Cifra il risultato usando l'algoritmo e la chiave specificata dalla SA
• Aggiunge davanti (all'estremità di sinistra) di ciò che è stato cifrato al passo precedente un ESP header; il pacchetto risultante è proprio un'enchilada
• Crea un authentication MAC sull'intera enchilada usando l'algoritmo e la chiave specificata nella SA
• Aggiunge il MAC alla fine dell'enchilada formando un payload
• Alla fine crea un nuovo header IP classico (con tutte le informazioni dei campi necessari per IP classico) e lo aggiunge davanti (alla sinistra) del payload
  Ciò che viene fuori dalla conversione è proprio un datagramma IP classico, seguito da un payload che contiene: un ESP header, il datagramma IP originale cifrato, un trailer ESP e un capo ESP di autenticazione.
  L'indirizzo originale del datagramma ha 172.16.1.17 come indirizzo sorgente e 172.16.2.48 come indirizzo di destinazione. Poiché il datagramma IPsec include il payload il datagramma IP originale, questi indirizzi sono inclusi (e cifrati) come parte del payload del pacchetto IPsec.

Quando viene inviato il datagramma, vengono attraversati diversi router della internet pubblica prima di giungere a R2. Ciascun router processerà il datagramma come se si trattasse di un normale pacchetto IPv4.

Il trailer ESP contiene tre campi:

• padding: una sequenza di byte senza senso che vengono aggiunti al datagramma affinché abbia una dimensione coerente con la dimensione del blocco utilizzato da un qualche algoritmo che sfrutta cifratura a blocchi;
• pad-length: indica al destinatario il numero di byte di padding che sono stati aggiunti (e che devono essere rimossi);
• next-header indica il tipo di dati contenuti nel payload IP originario (per esempio UDP, TCP, ..)

Davanti al payload cifrato vi è un header ESP che contiene due campi:

• SPI: che indica all'entità ricevente la SA a cui il datagramma appartiene; in tal modo l'entità destinatario può ricercare nel suo SAD la SA appropriata in cui sono contenute le informazioni di stato per quella SA (come l'algoritmo usato per cifrare/decifrare e le chiavi);
• il campo numero di sequenza: è utilizzato per difendersi dagli attacchi di duplicazione (replay-attack).

Come abbiamo visto l'entità che invia il datagramma aggiunge un MAC di autenticazione. Come abbiamo detto prima, l'entità mittente calcola un MAC su tutta l'enchilada (formata dall'ESP header, il datagramma IP originale e il trailer ESP, in cui il datagramma e il trailer sono stati cifrati).
Ricorda che per calcolare un MAC, il mittente aggiunge una chiave MAC segreta all'enchilada e poi calcola una hash di lunghezza fissa del risultato. Quando R2 riceve il datagramma IPsec, vede che il pacchetto è diretto proprio a sé stesso. R2 allora processa il datagramma. Poiché il campo protocollo (nell'header IP a sinistra) è 50, R2 vede che si tratta di un datagramma IPsec con ESP per processare il datagramma. Prima di vedere come interagisce con l'enchilada, R2 usa SPI per determinare a quale SA il datagramma appartiene. In secondo luogo, calcola il MAC dell'enchilada e verifica ce il MAC sia consistente con il valore nel campo ESP MAC. Se è così, R2 sa per certo che il datagramma arriva da R1 e non è stato manomesso. Fatto ciò, R2 controlla che il numero di sequenza per verificare che il datagramma sia fresco e non duplicato. Dopo di ché R2 decifra il datagramma originale (cifrato con ESP) utilizzando le informazioni salvate nella SA corrispondente. Rimuove il padding in eccesso ed estrae il datagramma originale IP vanilla. Infine, inoltra il datagramma all'ufficio della filiale.

Questa modalità è utilizzata per mettere in sicurezza la comunicazione tra due host fissati. Un tunnel ESP in transport mode connette due host.

In transport mode, ESP è usato per mettere in sicurezza i protocolli del livello superiore a IP, questo vuol dire TCP oppure UDP, ma anche altri come ICMP e altri protocolli validi.
Si noti che l'header ESP è inserito dopo l'header IP, ma prima del segmento del livello superiore.

Come vediamo in figura, il payload, fatto dall'header TCP e dei dati, e l'ESP trailer sono cifrati. L'header ESP non è cifrato, altrimenti, il destinatario non sarebbe in grado di trovare la l'SPI e non avrebbe modo di sapere come decifrare il pacchetto, ma è comunque autenticato. Questo vuol dire che un attaccante, per esempio, non può sostituire l'SPI corrente con un altro, o un altro numero di sequenza.

La figura sotto mostra il formato di un header AH, come abbiamo specificato la sua precisa locazione varia in base alla modalità con cui viene utilizzato.

• Il campo next header è il numero di protocollo del payload trasportato da AH. Se AH sta proteggendo un datagramma IP che trasporta un segmento TCP allora il numero di protocollo sarà quello di TCP (6). AH potrebbe essere seguito da ESP.
• Il campo payload length è confusionario per due ragioni. La prima è che, nonostante il nome, si tratta della lunghezza dell'header AH, non la lunghezza del payload che AH sta proteggendo. Secondo, la lunghezza è espressa con il numero di word di 32 bit meno 2, il motivo è che AH un protocollo concepito per IPv6 in cui la lunghezza dell'header è espressa in questo modo (non sbatterci troppo la testa).
• Il campo security parameter index (SPI), che abbiamo già incontrato nella trattazione di ESP designa la SA cui appartiene il pacchetto AH.
• Il campo sequence number, anche questo incontrato in ESP è utile per evitare attacchi di duplicazione.
• Il campo authentication data, contiene il risultato del calcolo della ICV.

Quando un SA per AH viene stabilita, di solito attraverso negoziazioni IKE, l'algoritmo di autenticazione e le chiavi vengono registrate, il contatore per i numeri di sequenza è posto a 0. Quando IPsec determina che ad un pacchetto in uscita dovrebbe essere applicato AH, allora localizza la SA di appartenenza ed esegue il seguente processo:

1. Un template per un header AH viene posto tra IP e header del livello superiore.
2. Il numero di sequenza viene incrementato e salvato nell'header. Se il numero di sequenza ha raggiunto il limite allora viene creata un nuova SA e inizializza il numero di sequenza 0.
3. Il resto dei campi AH, con l'eccezione del campo ICV, vengono riempiti.
4. Se richiesto, viene aggiunto del padding all'header AH (per lo stesso motivo discusso in ESP)
5. I campi mutabili dell'header IP e il campo ICV nell'header vengono posti a zero, l'ICV viene calcolato su tutto il datagramma IP. Se è presente un'opzione di routing alla sorgente (preferenze di routing del mittente) nell'header IP, l'indirizzo di destinazione deve essere settato alla destinazione finale prima di calcolare l'ICV.
6. I campi mutabili vengono riempiti, e l'ICV viene salvato nell'header AH. Se sono presenti opzioni di routing alla sorgente, il campo destination address deve essere nuovamente settato alla prossima destinazione (e ICV viene ricalcolato).
7. Il datagramma IP viene piazzato nella coda d'uscita per la trasmissione verso la sua destinazione.

I pacchetti autenticati con AH potrebbero essere frammentati, ovviamente, prima che AH possa agire su di essi, il datagramma deve essere interamente ricomposto. Dopo di che AH esegue le seguenti operazioni:

1. Basandosi sullo SPI nell'header AH e l'indirizzo di destinazione dell'header IP, viene rilevata la SA opportuna. Se non viene rilevata, il pacchetto viene rifiutato.
2. Se il controllo per il numero di sequenza è abilitato, AH verifica se il numero di sequenza è accettabile (come abbiamo descritto sopra). Se è troppo vecchio o duplicati il datagramma viene rifiutato.
3. AH copia gli header IP e AH, azzera i campi mutabili dell'header IP e l'ICV di AH.
4. Tramite l'algoritmo di autenticazione e la chiave specificati nella SA viene calcolato il nuovo ICV per tutto il pacchetto e il risultato viene comparato con quello originale nell'header AH salvato. Se i valori corrispondono, il pacchetto viene accettato, altrimenti no.
5. L'intestazione AH viene rimossa dal datgramma, i campi originale dell'header IP vengono ripristinati. E il pacchetto viene inserito nella coda di input per essere processato come un normale pacchetto IP.

Questa modalità è usata per mettere in sicurezza la comunicazione tra due host fissati. Gli estremi sono specifici host invece che due router o un host e un router.

Nella modalità trasporto, l'header AH è inserito nel datagramma IP subito dopo l'header IP.

Facciamo notare che vi è una riga che mostra che l'autenticazione va da metà header IP fino al payload (data), questo rappresenta il fatto che non tutti i campi dell'header IP vengono autenticati (quelli mutabili vengono esclusi).

La modalità tunnel è usata per connettere due router attraverso un insieme di security gateway (router) oppure un host e un security gateway.

In figura per esempio, poiché i security gateway devono proteggere i datagrammi tra un paio qualsiasi di host nelle due reti, l'incapsulamento è diverso.
Ed è simili a quello che abbiamo trattato per ESP.
Ovvero, invece di inserire un header AH tra l'header IP e il protocollo di livello superiore, l'intero datagramma viene incapsulato piazzandogli davanti un header IP e un header AH.

Anche qui, l'header IP esterno è autenticato solo per i campi non mutabili, ma notiamo anche che l'header IP interno è completamente autenticato. Quando i pacchetti passeranno nei router intermedi, vedranno un semplice pacchetto IP (con numero di protocollo che indica AH).

I due estremi della comunicazione utilizzano Diffie-Hellman per creare una connessione IKE SA (che è diversa dall'SA discussa nel contesto di IPsec) tra i router. IKE SA fornisce un canale di autenticazione e cifrato tra i due router. Durante questa fase vengono stabilite le chiavi per la cifratura e l'autenticazione per l'IKE SA. Ciò che viene stabilito è un segreto su cui si basano le chiavi della SA di IPsec. Durante questa fase non sono usate chiavi pubbliche e private RSA.

Nella seconda fase, entrami gli estremi rivelano la propria identità all'altro firmando i loro messaggi. In ogni caso, le identità non sono rivelate ad un passive sniffer, dal momento che sono inviate in un canale IKE SA sicuro. Inoltre durante questa fase, i due estremi negoziano la cifratura IPsec e gli algoritmi di autenticazione che devono essere usati dalle SA di IPsec.

Alla fine delle fase due, gli estremi della comunicazione possono cominciare ad usare IPsec.