1. Introduction (Introduzione)

Questo documento presuppone che il lettore abbia familiarità con i termini e i concetti descritti nella "Security Architecture for the Internet Protocol" [Ken-Arch], d'ora in poi denominato documento Security Architecture. In particolare, il lettore dovrebbe avere familiarità con le definizioni dei servizi di sicurezza offerti dall'Encapsulating Security Payload (ESP) [Ken-ESP] e dall'IP Authentication Header (AH), il concetto di Security Associations, i modi in cui ESP può essere utilizzato in combinazione con l'Authentication Header (AH), e le diverse opzioni di gestione delle chiavi disponibili per ESP e AH.

Le parole chiave MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY e OPTIONAL, quando appaiono in questo documento, devono essere interpretate come descritto in RFC 2119 [Bra97].

L'IP Authentication Header (AH) viene utilizzato per fornire integrità senza connessione e autenticazione dell'origine dei dati per i datagrammi IP (d'ora in poi denominati semplicemente "integrità") e per fornire protezione contro le repliche. Quest'ultimo servizio opzionale può essere selezionato dal ricevitore quando viene stabilita una Security Association (SA). (Il protocollo di default richiede al mittente di incrementare il numero di sequenza utilizzato per l'anti-replay, ma il servizio è efficace solo se il ricevitore controlla il numero di sequenza.) Tuttavia, per utilizzare la funzionalità Extended Sequence Number in modo interoperabile, AH impone un requisito ai protocolli di gestione SA di essere in grado di negoziare questa nuova funzionalità (vedere la Sezione 2.5.1 di seguito).

AH fornisce autenticazione per quanto possibile dell'intestazione IP, così come per i dati del protocollo di livello successivo. Tuttavia, alcuni campi dell'intestazione IP possono cambiare durante il transito e il valore di questi campi, quando il pacchetto arriva al ricevitore, potrebbe non essere prevedibile dal mittente. I valori di tali campi non possono essere protetti da AH. Pertanto, la protezione fornita all'intestazione IP da AH è parziale. (Vedere Appendice A.)

AH può essere applicato da solo, in combinazione con l'IP Encapsulating Security Payload (ESP) [Ken-ESP], o in modo annidato (vedere il documento Security Architecture [Ken-Arch]). I servizi di sicurezza possono essere forniti tra una coppia di host comunicanti, tra una coppia di gateway di sicurezza comunicanti, o tra un gateway di sicurezza e un host. ESP può essere utilizzato per fornire gli stessi servizi di anti-replay e integrità simili, e fornisce anche un servizio di riservatezza (crittografia). La differenza principale tra l'integrità fornita da ESP e AH è l'estensione della copertura. In particolare, ESP non protegge alcun campo dell'intestazione IP a meno che tali campi non siano incapsulati da ESP (ad esempio, tramite l'uso della modalità tunnel). Per ulteriori dettagli su come utilizzare AH ed ESP in vari ambienti di rete, vedere il documento Security Architecture [Ken-Arch].

La Sezione 7 fornisce una breve rassegna delle differenze tra questo documento e RFC 2402 [RFC2402].