1. Introduction (Introduzione)

1. Introduction

Questo documento presuppone che il lettore abbia familiarità con i termini e i concetti descritti nella "Security Architecture for the Internet Protocol" [Ken-Arch], di seguito denominato documento di architettura di sicurezza. In particolare, il lettore dovrebbe avere familiarità con le definizioni dei servizi di sicurezza offerti dall'Encapsulating Security Payload (ESP) e dall'IP Authentication Header (AH), il concetto di Security Associations, i modi in cui ESP può essere utilizzato in combinazione con 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 nella RFC 2119 [Bra97].

L'header Encapsulating Security Payload (ESP) è progettato per fornire un insieme di servizi di sicurezza in IPv4 e IPv6 [DH98]. ESP può essere applicato da solo, in combinazione con AH [Ken-AH], o in modo annidato (vedere il documento di architettura di sicurezza [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. Per maggiori dettagli su come utilizzare ESP e AH in vari ambienti di rete, vedere il documento di architettura di sicurezza [Ken-Arch].

L'header ESP viene inserito dopo l'header IP e prima dell'header del protocollo del livello successivo (modalità trasporto) o prima di un header IP incapsulato (modalità tunnel). Queste modalità sono descritte più dettagliatamente di seguito.

ESP può essere utilizzato per fornire riservatezza, autenticazione dell'origine dei dati, integrità senza connessione, un servizio anti-replay (una forma di integrità parziale della sequenza), e (limitata) riservatezza del flusso di traffico. L'insieme dei servizi forniti dipende dalle opzioni selezionate al momento della creazione della Security Association (SA) e dalla posizione dell'implementazione in una topologia di rete.

L'utilizzo della sola crittografia per la riservatezza è consentito da ESP. Tuttavia, va notato che in generale, questo fornirà difesa solo contro attaccanti passivi. L'utilizzo della crittografia senza un forte meccanismo di integrità sopra di essa (sia in ESP che separatamente tramite AH) può rendere il servizio di riservatezza insicuro contro alcune forme di attacchi attivi [Bel96, Kra01]. Inoltre, un servizio di integrità sottostante, come AH, applicato prima della crittografia non protegge necessariamente la riservatezza solo crittografica contro attaccanti attivi [Kra01]. ESP consente SA con sola crittografia perché questo può offrire prestazioni considerevolmente migliori e fornire comunque una sicurezza adeguata, ad esempio, quando la protezione di autenticazione/integrità di livello superiore è offerta indipendentemente. Tuttavia, questo standard non richiede che le implementazioni ESP offrano un servizio di sola crittografia.

L'autenticazione dell'origine dei dati e l'integrità senza connessione sono servizi congiunti, di seguito denominati congiuntamente "integrity" (integrità). (Questo termine viene utilizzato perché, su base per pacchetto, il calcolo eseguito fornisce direttamente l'integrità senza connessione; l'autenticazione dell'origine dei dati viene fornita indirettamente come risultato del legame della chiave utilizzata per verificare l'integrità con l'identità del peer IPsec. Tipicamente, questo legame viene effettuato attraverso l'uso di una chiave simmetrica condivisa.) L'ESP con sola integrità DEVE essere offerto come opzione di selezione del servizio, ad esempio, deve essere negoziabile nei protocolli di gestione SA e DEVE essere configurabile tramite interfacce di gestione. L'ESP con sola integrità è un'alternativa attraente ad AH in molti contesti, ad esempio, perché è più veloce da elaborare e più adatto al pipelining in molte implementazioni.

Sebbene riservatezza e integrità possano essere offerte indipendentemente, ESP tipicamente impiegherà entrambi i servizi, cioè, i pacchetti saranno protetti per quanto riguarda riservatezza e integrità. Pertanto, ci sono tre possibili combinazioni di servizi di sicurezza ESP che coinvolgono questi servizi:

• confidentiality-only (sola riservatezza) (PUÒ essere supportato)
• integrity only (sola integrità) (DEVE essere supportato)
• confidentiality and integrity (riservatezza e integrità) (DEVE essere supportato)

Il servizio anti-replay può essere selezionato per una SA solo se il servizio di integrità è selezionato per quella SA. La selezione di questo servizio è esclusivamente a discrezione del ricevitore e quindi non necessita di essere negoziata. Tuttavia, per utilizzare la funzionalità del numero di sequenza esteso in modo interoperabile, ESP impone un requisito ai protocolli di gestione SA di poter negoziare questa funzionalità (vedere la sezione 2.2.1 di seguito).

Il servizio di riservatezza del flusso di traffico (TFC) è generalmente efficace solo se ESP è impiegato in modo da nascondere gli indirizzi di origine e destinazione finali dei corrispondenti, ad esempio, in modalità tunnel tra gateway di sicurezza, e solo se un traffico sufficiente fluisce tra i peer IPsec (sia naturalmente che come risultato della generazione di traffico di mascheramento) per nascondere le caratteristiche di flussi di traffico specifici di singoli abbonati. (ESP può essere impiegato come parte di un sistema TFC di livello superiore, ad esempio, Onion Routing [Syverson], ma tali sistemi sono al di fuori dello scopo di questo standard.) Le nuove funzionalità TFC presenti in ESP facilitano la generazione efficiente e l'eliminazione del traffico fittizio e un migliore riempimento del traffico reale, in modo retrocompatibile.

La sezione 7 fornisce una breve revisione delle differenze tra questo documento e la RFC 2406.