3.4. Elaborazione dei pacchetti in ingresso

Questa sezione descrive l'elaborazione dei pacchetti ESP in ingresso.

3.4.1. Reassembly

Se necessario, il riassemblaggio viene eseguito prima dell'elaborazione ESP. Se un pacchetto presentato a ESP sembra essere un frammento IP, ossia il campo OFFSET è diverso da zero oppure è impostato il flag MORE FRAGMENTS, il receiver DEVE scartarlo; si tratta di un evento sottoponibile ad audit. La voce di audit DOVREBBE includere il valore SPI, data e ora di ricezione, Source Address, Destination Address, Sequence Number e, per IPv6, Flow ID.

Nota: per il riassemblaggio dei pacchetti, l'attuale specifica IPv4 NON richiede né l'azzeramento del campo OFFSET né la cancellazione del flag MORE FRAGMENTS. Affinché un pacchetto riassemblato possa essere elaborato da IPsec, anziché venire scartato come frammento apparente, il codice IP deve compiere entrambe queste operazioni dopo il riassemblaggio.

3.4.2. Security Association Lookup

Alla ricezione di un pacchetto contenente un ESP Header, il receiver determina la SA unidirezionale appropriata mediante una ricerca nella SAD. Per una SA unicast, la determinazione si basa sullo SPI oppure su SPI e campo protocollo, come descritto nella sezione 2.1. Se un'implementazione supporta traffico multicast, nella ricerca viene usato anche l'indirizzo di destinazione, oltre allo SPI, e può essere usato anche l'indirizzo del mittente, come descritto nella sezione 2.1. Questo processo è illustrato più dettagliatamente nel documento Security Architecture. La voce SAD della SA indica inoltre se il campo Sequence Number debba essere controllato, se per la SA siano usati numeri di sequenza a 32 o 64 bit e se debba essere presente il campo ICV esplicito, nonché la sua dimensione. La voce SAD specifica anche gli algoritmi e le chiavi da utilizzare per decrittazione e calcolo ICV, se applicabile.

Se non esiste una Security Association valida per il pacchetto, il receiver DEVE scartarlo; si tratta di un evento sottoponibile ad audit. La voce di audit DOVREBBE includere SPI, data e ora di ricezione, Source Address, Destination Address, Sequence Number e, in IPv6, Flow ID in chiaro.

Si noti che il traffico di gestione SA, ad esempio i pacchetti IKE, non richiede l'elaborazione basata su SPI: può essere demultiplexato separatamente in base, per esempio, ai campi Next Protocol e Port.

3.4.3. Sequence Number Verification

Tutte le implementazioni ESP DEVONO supportare il servizio anti-replay, sebbene il receiver possa abilitarlo o disabilitarlo per singola SA. Questo servizio NON DEVE essere abilitato a meno che per la SA non sia abilitato anche il servizio di integrità ESP, perché altrimenti il campo Sequence Number non sarebbe protetto dall'integrità. L'anti-replay si applica sia alle SA unicast sia a quelle multicast. Tuttavia, questo standard non definisce meccanismi anti-replay per una SA con più mittenti, unicast o multicast. In assenza di negoziazione, o configurazione manuale, di un meccanismo anti-replay per tale SA, è raccomandato disabilitare, tramite negoziazione o configurazione manuale, il controllo del numero di sequenza della SA sia sul mittente sia sul receiver, come indicato di seguito.

Se il receiver non abilita l'anti-replay per una SA, non esegue controlli in ingresso sul Sequence Number. Dal punto di vista del mittente, tuttavia, il comportamento predefinito è presumere che il receiver abbia abilitato l'anti-replay. Per evitare che il mittente esegua monitoraggio non necessario dei numeri di sequenza e predisposizione della SA, vedere sezione 3.3.3, il receiver DOVREBBE avvisare il mittente, durante l'istituzione della SA e quando viene usato un protocollo di istituzione della SA, se non fornirà protezione anti-replay.

Se il receiver ha abilitato il servizio anti-replay per questa SA, il contatore dei pacchetti ricevuti della SA DEVE essere inizializzato a zero all'istituzione della SA. Per ogni pacchetto ricevuto, il receiver DEVE verificare che il pacchetto contenga un Sequence Number non duplicato rispetto a quello di qualunque altro pacchetto ricevuto durante la vita della SA. Questo DOVREBBE essere il primo controllo ESP applicato a un pacchetto dopo il suo abbinamento a una SA, per accelerare il rifiuto dei pacchetti duplicati.

ESP consente una verifica in due fasi dei numeri di sequenza dei pacchetti. Questa capacità è importante quando un'implementazione ESP, tipicamente la sua componente di modulo crittografico, non riesce a eseguire decrittazione e/o verifica dell'integrità alla stessa velocità delle interfacce verso reti non protette. Se l'implementazione può operare a velocità di linea, non è necessario eseguire la fase di verifica preliminare descritta di seguito.

Il controllo preliminare del Sequence Number usa il valore Sequence Number nell'ESP Header ed è eseguito prima della verifica dell'integrità e della decrittazione. Se questo controllo preliminare fallisce, il pacchetto viene scartato, evitando al receiver qualunque operazione crittografica. Se ha successo, il receiver non può ancora modificare il proprio contatore locale, poiché a questo punto l'integrità del Sequence Number non è stata verificata.

I duplicati vengono rifiutati mediante una finestra di ricezione scorrevole. L'implementazione della finestra è una scelta locale, ma deve presentare le funzionalità descritte di seguito.

Il margine "destro" della finestra rappresenta il più alto valore Sequence Number convalidato ricevuto su questa SA. I pacchetti con numero di sequenza inferiore al margine "sinistro" della finestra vengono rifiutati. I pacchetti all'interno della finestra vengono controllati rispetto a un elenco dei pacchetti ricevuti nella finestra. Se per una SA è selezionata l'opzione ESN, vengono trasmessi esplicitamente solo i 32 bit meno significativi del numero di sequenza; nel confronto con la finestra di ricezione, il receiver usa tuttavia il numero di sequenza completo, calcolato con i 32 bit più significativi della SA indicata e ricavati dal proprio contatore locale. Per costruire il numero di sequenza completo, se i 32 bit meno significativi contenuti nel pacchetto sono inferiori ai 32 bit meno significativi del numero di sequenza del receiver, il receiver presume che i 32 bit più significativi siano stati incrementati e passa a un nuovo sottospazio di numeri di sequenza. Questo algoritmo gestisce, per una singola SA, lacune di ricezione fino a 2**32-1 pacchetti. Se si verifica una lacuna maggiore, POSSONO essere usati ulteriori controlli euristici per risincronizzare il contatore del numero di sequenza del receiver, come descritto nell'Appendice.

Se il pacchetto ricevuto rientra nella finestra e non è un duplicato, oppure si trova a destra della finestra, il receiver procede alla verifica dell'integrità quando è impiegato un algoritmo di integrità separato. Se è impiegato un algoritmo in modalità combinata, il controllo di integrità viene eseguito insieme alla decrittazione. In entrambi i casi, se il controllo di integrità fallisce, il receiver DEVE scartare il datagramma IP ricevuto perché non valido; si tratta di un evento sottoponibile ad audit. La voce del registro di audit DOVREBBE includere SPI, data e ora di ricezione, Source Address, Destination Address, Sequence Number e, per IPv6, Flow ID. La finestra di ricezione viene aggiornata solo se la verifica dell'integrità ha successo. Quando si usa un algoritmo in modalità combinata, il Sequence Number protetto dall'integrità deve corrispondere anche al Sequence Number usato per la protezione anti-replay.

Con numeri di sequenza a 32 bit DEVE essere supportata una finestra di almeno 32 pacchetti; è preferibile una finestra di 64 pacchetti, che DOVREBBE essere il valore predefinito. Il receiver PUÒ scegliere un'altra dimensione, purché maggiore del minimo; non comunica la dimensione della finestra al mittente. La dimensione della finestra di ricezione dovrebbe essere aumentata negli ambienti a velocità superiore, indipendentemente da considerazioni di assurance. Questo standard non specifica valori minimi o raccomandati per finestre di ricezione di dispositivi a velocità molto elevata, ad esempio multi-gigabit al secondo.

3.4.4. Integrity Check Value Verification

Come per l'elaborazione in uscita, esistono diverse opzioni per l'elaborazione in ingresso, determinate dalle caratteristiche degli algoritmi impiegati.

3.4.4.1. Separate Confidentiality and Integrity Algorithms

Se sono impiegati algoritmi separati di riservatezza e integrità, l'elaborazione procede come segue:

Se è stata selezionata l'integrità, il receiver calcola l'ICV sul pacchetto ESP escluso l'ICV, usando l'algoritmo di integrità specificato, e verifica che coincida con l'ICV trasportato nel pacchetto. I dettagli del calcolo sono riportati di seguito.

Se gli ICV calcolato e ricevuto coincidono, il datagramma è valido e viene accettato. Se il controllo fallisce, il receiver DEVE scartare il datagramma IP ricevuto perché non valido; si tratta di un evento sottoponibile ad audit. Il registro DOVREBBE includere SPI, data e ora di ricezione, Source Address, Destination Address, Sequence Number e, per IPv6, Flow ID in chiaro.

Nota di implementazione:

Le implementazioni possono usare qualunque sequenza di passi che produca lo stesso risultato della seguente. Per prima cosa rimuovono e salvano il campo ICV. Quindi controllano la lunghezza complessiva del pacchetto ESP senza il campo ICV. Se è necessario il padding implicito in base alla dimensione del blocco dell'algoritmo di integrità, aggiungono byte a zero alla fine del pacchetto ESP, subito dopo il campo Next Header oppure, se è selezionato ESN, dopo i 32 bit più significativi del numero di sequenza. Eseguono il calcolo dell'ICV e confrontano il risultato con il valore salvato applicando le regole di confronto definite dalla specifica dell'algoritmo.
Il receiver decritta ESP Payload Data, Padding, Pad Length e Next Header usando la chiave, l'algoritmo di cifratura, la modalità dell'algoritmo e gli eventuali dati di sincronizzazione crittografica indicati dalla SA. Come nella sezione 3.3.2, si parla qui di cifratura come se fosse sempre applicata, per le implicazioni di formato. Resta inteso che la "nessuna riservatezza" è ottenuta mediante l'algoritmo di cifratura NULL, RFC 2410.
- Se sono indicati dati espliciti di sincronizzazione crittografica, ad esempio un IV, essi vengono prelevati dal campo Payload e forniti all'algoritmo di decrittazione secondo la specifica dell'algoritmo.
- Se sono indicati dati impliciti di sincronizzazione crittografica, viene costruita una versione locale dell'IV e fornita all'algoritmo di decrittazione secondo la specifica dell'algoritmo.
Il receiver elabora l'eventuale Padding come specificato dalla definizione dell'algoritmo di cifratura. Se è stato impiegato lo schema di padding predefinito, vedere sezione 2.4, il receiver DOVREBBE ispezionare il campo Padding prima di rimuovere il padding e passare i dati decrittati al livello successivo.
Il receiver controlla il campo Next Header. Se il valore è "59" (nessun header successivo), il pacchetto fittizio viene scartato senza ulteriore elaborazione.
Il receiver ricostruisce il datagramma IP originario da:
- modalità trasporto: header IP esterno più le informazioni del protocollo del livello successivo originario nel campo ESP Payload;
- modalità tunnel: l'intero datagramma IP nel campo ESP Payload.
I passi esatti per ricostruire il datagramma originario dipendono dalla modalità, trasporto o tunnel, e sono descritti nel documento Security Architecture. Come requisito minimo, nel contesto IPv6 il receiver DOVREBBE assicurare che i dati decrittati siano allineati a 8 byte, per facilitare l'elaborazione da parte del protocollo identificato dal campo Next Header. Questa elaborazione "scarta" l'eventuale padding TFC aggiunto per la riservatezza del flusso di traffico. Se presente, esso è stato inserito dopo il datagramma IP, o frame del livello di trasporto, e prima del campo Padding, vedere sezione 2.4.

Se il controllo di integrità e la cifratura sono eseguiti in parallelo, il controllo di integrità DEVE terminare prima che il pacchetto decrittato sia passato a ulteriori elaborazioni. Questo ordine facilita l'individuazione e il rifiuto rapidi, da parte del receiver, dei pacchetti riprodotti o falsi prima della loro decrittazione e può quindi ridurre l'impatto di attacchi denial-of-service.

Nota: se il receiver esegue la decrittazione in parallelo al controllo di integrità, occorre evitare possibili race condition nell'accesso al pacchetto e nell'estrazione del pacchetto decrittato.

3.4.4.2. Combined Confidentiality and Integrity Algorithms

Se è impiegato un algoritmo combinato di riservatezza e integrità, il receiver procede come segue:

Decritta e controlla l'integrità di ESP Payload Data, Padding, Pad Length e Next Header, usando la chiave, l'algoritmo, la modalità dell'algoritmo e gli eventuali dati di sincronizzazione crittografica indicati dalla SA. Lo SPI dell'ESP header e il valore del contatore dei pacchetti del receiver, adeguato secondo l'elaborazione descritta nella sezione 3.4.3, sono ingressi di questo algoritmo perché necessari al controllo di integrità.
- Se sono indicati dati espliciti di sincronizzazione crittografica, ad esempio un IV, essi vengono prelevati dal campo Payload e forniti all'algoritmo di decrittazione secondo la specifica dell'algoritmo.
- Se sono indicati dati impliciti di sincronizzazione crittografica, ad esempio un IV, viene costruita una versione locale dell'IV e fornita all'algoritmo di decrittazione secondo la specifica dell'algoritmo.
Se il controllo di integrità eseguito dall'algoritmo in modalità combinata fallisce, il receiver DEVE scartare il datagramma IP ricevuto perché non valido; si tratta di un evento sottoponibile ad audit. Il registro DOVREBBE includere SPI, data e ora di ricezione, Source Address, Destination Address, Sequence Number e, per IPv6, Flow ID in chiaro.
Elabora l'eventuale Padding come indicato dalla specifica dell'algoritmo di cifratura, se l'algoritmo non lo ha già fatto.
Il receiver controlla il campo Next Header. Se il valore è "59" (nessun header successivo), il pacchetto fittizio viene scartato senza ulteriore elaborazione.
Estrae dal campo ESP Payload Data il datagramma IP originario, in modalità tunnel, oppure il frame del livello di trasporto, in modalità trasporto. In questo modo viene implicitamente scartato l'eventuale padding aggiunto per la riservatezza del flusso di traffico. Se presente, il padding TFC è stato inserito dopo il payload IP e prima del campo Padding, vedere sezione 2.4.