3.3.3. Integrity Check Value Calculation

L'ICV di AH viene calcolato su:

• campi dell'intestazione IP o di estensione prima dell'intestazione AH che sono immutabili in transito o che sono prevedibili nel valore all'arrivo all'endpoint per la SA AH
• l'intestazione AH (Next Header, Payload Len, Reserved, SPI, Sequence Number (32 bit di ordine inferiore), e l'ICV (che viene impostato a zero per questo calcolo), e byte di padding espliciti (se presenti))
• tutto ciò che è dopo AH si presume sia immutabile in transito
• i bit di ordine superiore dell'ESN (se impiegati), e qualsiasi padding implicito richiesto dall'algoritmo di integrità

3.3.3.1. Handling Mutable Fields

Se un campo può essere modificato durante il transito, il valore del campo viene impostato a zero ai fini del calcolo dell'ICV. Se un campo è mutabile, ma il suo valore al ricevitore (IPsec) è prevedibile, allora quel valore viene inserito nel campo ai fini del calcolo dell'ICV. Anche il campo Integrity Check Value viene impostato a zero in preparazione a questo calcolo. Si noti che sostituendo il valore di ciascun campo con zero, anziché omettere il campo, l'allineamento viene preservato per il calcolo dell'ICV. Inoltre, l'approccio di riempimento con zeri garantisce che la lunghezza dei campi così gestiti non possa essere modificata durante il transito, anche se i loro contenuti non sono esplicitamente coperti dall'ICV.

Quando viene creata una nuova intestazione di estensione o opzione IPv4, verrà definita nel proprio RFC e DOVREBBE includere (nella sezione Security Considerations) indicazioni su come dovrebbe essere gestita quando si calcola l'ICV di AH. Se l'implementazione IP (v4 o v6) incontra un'intestazione di estensione che non riconosce, scarterà il pacchetto e invierà un messaggio ICMP. IPsec non vedrà mai il pacchetto. Se l'implementazione IPsec incontra un'opzione IPv4 che non riconosce, dovrebbe azzerare l'intera opzione, utilizzando il secondo byte dell'opzione come lunghezza. Le opzioni IPv6 (nelle intestazioni di estensione di destinazione o nell'intestazione di estensione Hop-by-Hop) contengono un flag che indica la mutabilità, che determina l'elaborazione appropriata per tali opzioni.

3.3.3.1.1. ICV Computation for IPv4

3.3.3.1.1.1. Base Header Fields

I campi dell'intestazione base IPv4 sono classificati come segue:

Immutable:

• Version
• Internet Header Length
• Total Length
• Identification
• Protocol (Questo dovrebbe essere il valore per AH.)
• Source Address
• Destination Address (senza routing sorgente lasco o rigoroso)

Mutable but predictable:

• Destination Address (con routing sorgente lasco o rigoroso)

Mutable (azzerati prima del calcolo ICV):

• Differentiated Services Code Point (DSCP) (6 bit, vedere RFC 2474 [NBBB98])
• Explicit Congestion Notification (ECN) (2 bit, vedere RFC 3168 [RFB01])
• Flags
• Fragment Offset
• Time to Live (TTL)
• Header Checksum

DSCP - I router possono riscrivere il campo DS secondo necessità per fornire un servizio locale o end-to-end desiderato, quindi il suo valore alla ricezione non può essere previsto dal mittente.

ECN - Questo cambierà se un router lungo il percorso sperimenta congestione, e quindi il suo valore alla ricezione non può essere previsto dal mittente.

Flags - Questo campo è escluso perché un router intermedio potrebbe impostare il bit DF, anche se la sorgente non lo ha selezionato.

Fragment Offset - Poiché AH viene applicato solo a pacchetti IP non frammentati, il campo Offset deve sempre essere zero, e quindi è escluso (anche se è prevedibile).

TTL - Questo viene modificato in rotta come normale corso di elaborazione da parte dei router, e quindi il suo valore al ricevitore non è prevedibile dal mittente.

Header Checksum - Questo cambierà se uno qualsiasi di questi altri campi cambia, e quindi il suo valore alla ricezione non può essere previsto dal mittente.

3.3.3.1.1.2. Options

Per IPv4 (a differenza di IPv6), non esiste alcun meccanismo per contrassegnare le opzioni come mutabili in transito. Quindi le opzioni IPv4 sono esplicitamente elencate nell'Appendice A e classificate come immutabili, mutabili ma prevedibili, o mutabili. Per IPv4, l'intera opzione è vista come un'unità; quindi anche se i campi di tipo e lunghezza all'interno della maggior parte delle opzioni sono immutabili in transito, se un'opzione è classificata come mutabile, l'intera opzione viene azzerata ai fini del calcolo dell'ICV.

3.3.3.1.2. ICV Computation for IPv6

3.3.3.1.2.1. Base Header Fields

I campi dell'intestazione base IPv6 sono classificati come segue:

Immutable:

• Version
• Payload Length
• Next Header
• Source Address
• Destination Address (senza intestazione di estensione Routing)

Mutable but predictable:

• Destination Address (con intestazione di estensione Routing)

Mutable (azzerati prima del calcolo ICV):

• DSCP (6 bit, vedere RFC2474 [NBBB98])
• ECN (2 bit, vedere RFC3168 [RFB01])
• Flow Label (*)
• Hop Limit

(*) L'etichetta di flusso descritta in AHv1 era mutabile, e in RFC 2460 [DH98] era potenzialmente mutabile. Per mantenere la compatibilità con le implementazioni AH esistenti, l'etichetta di flusso non è inclusa nell'ICV in AHv2.

3.3.3.1.2.2. Extension Headers Containing Options

Le opzioni IPv6 nelle intestazioni di estensione Hop-by-Hop e Destination contengono un bit che indica se l'opzione potrebbe cambiare (in modo imprevedibile) durante il transito. Per qualsiasi opzione per la quale i contenuti possono cambiare in transito, l'intero campo "Option Data" deve essere trattato come ottetti con valore zero quando si calcola o verifica l'ICV. L'Option Type e Opt Data Len sono inclusi nel calcolo dell'ICV. Tutte le opzioni per le quali il bit indica immutabilità sono incluse nel calcolo dell'ICV. Vedere la specifica IPv6 [DH98] per ulteriori informazioni.

3.3.3.1.2.3. Extension Headers Not Containing Options

Le intestazioni di estensione IPv6 che non contengono opzioni sono esplicitamente elencate nell'Appendice A e classificate come immutabili, mutabili ma prevedibili, o mutabili.

3.3.3.2. Padding and Extended Sequence Numbers

3.3.3.2.1. ICV Padding

Come menzionato nella Sezione 2.6, il campo ICV può includere padding esplicito se richiesto per garantire che l'intestazione AH sia un multiplo di 32 bit (IPv4) o 64 bit (IPv6). Se è richiesto il padding, la sua lunghezza è determinata da due fattori:

• la lunghezza dell'ICV
• la versione del protocollo IP (v4 o v6)

Ad esempio, se l'output dell'algoritmo selezionato è 96 bit, non è richiesto padding per IPv4 o IPv6. Tuttavia, se viene generato un ICV di lunghezza diversa, a causa dell'uso di un algoritmo diverso, potrebbe essere richiesto il padding a seconda della lunghezza e della versione del protocollo IP. Il contenuto del campo di padding è selezionato arbitrariamente dal mittente. (Il padding è arbitrario, ma non è necessario che sia casuale per ottenere sicurezza.) Questi byte di padding sono inclusi nel calcolo dell'ICV, contati come parte della Payload Length, e trasmessi alla fine del campo ICV per consentire al ricevitore di eseguire il calcolo dell'ICV. È vietata l'inclusione di padding in eccesso rispetto alla quantità minima richiesta per soddisfare i requisiti di allineamento IPv4/IPv6.

3.3.3.2.2. Implicit Packet Padding and ESN

Se l'opzione ESN è eletta per una SA, allora i 32 bit di ordine superiore dell'ESN devono essere inclusi nel calcolo dell'ICV. Ai fini del calcolo dell'ICV, questi bit vengono aggiunti (implicitamente) immediatamente dopo la fine del payload, e prima di qualsiasi padding di pacchetto implicito.

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 IP (incluso AH e i 32 bit di ordine superiore dell'ESN, se abilitato) non corrisponde ai requisiti di dimensione del blocco per l'algoritmo, il padding implicito DEVE essere aggiunto alla fine del pacchetto, prima del calcolo dell'ICV. Gli ottetti di padding DEVONO avere un valore di zero. La dimensione del blocco (e quindi la lunghezza del padding) è specificata dalla specifica dell'algoritmo. 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 questo, allora l'impostazione predefinita è presumere 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 i contenuti del padding, allora gli ottetti di padding DEVONO avere un valore di zero.