1.3.1. Creazione di nuove Child SA con lo scambio CREATE_CHILD_SA

1.3.1. Creazione di nuove Child SA con lo scambio CREATE_CHILD_SA

Una Child SA può essere creata inviando una richiesta CREATE_CHILD_SA. La richiesta CREATE_CHILD_SA per creare una nuova Child SA è:

Initiator Responder

HDR, SK {SA, Ni, [KEi], TSi, TSr} -->

L'iniziatore invia le offerte SA nel payload SA, un nonce nel payload Ni, facoltativamente un valore Diffie-Hellman nel payload KEi e i Traffic Selector proposti per la Child SA proposta nei payload TSi e TSr.

La risposta CREATE_CHILD_SA per creare una nuova Child SA è:

                         <--  HDR, SK {SA, Nr, [KEr],
                                  TSi, TSr}

Il risponditore risponde (utilizzando lo stesso Message ID per rispondere) con l'offerta accettata in un payload SA e un valore Diffie-Hellman nel payload KEr se KEi era incluso nella richiesta e la suite crittografica selezionata include quel gruppo.

I Traffic Selector per il traffico da inviare su quella SA sono specificati nei payload TS nella risposta, che possono essere un sottoinsieme di ciò che l'iniziatore della Child SA ha proposto.

La notifica USE_TRANSPORT_MODE PUÒ essere inclusa in un messaggio di richiesta che include anche un payload SA che richiede una Child SA. Richiede che la Child SA utilizzi la modalità trasporto anziché la modalità tunnel per la SA creata. Se la richiesta viene accettata, la risposta DEVE includere anche una notifica di tipo USE_TRANSPORT_MODE. Se il risponditore declina la richiesta, la Child SA verrà stabilita in modalità tunnel. Se questo è inaccettabile per l'iniziatore, l'iniziatore DEVE eliminare la SA. Nota: ad eccezione dell'uso di questa opzione per negoziare la modalità trasporto, tutte le Child SA utilizzeranno la modalità tunnel.

La notifica ESP_TFC_PADDING_NOT_SUPPORTED asserisce che l'estremità di invio non accetterà pacchetti che contengono padding per la Riservatezza del Flusso di Traffico (Traffic Flow Confidentiality, TFC) sulla Child SA in fase di negoziazione. Se nessuna delle due estremità accetta il padding TFC, questa notifica è inclusa sia nella richiesta sia nella risposta. Se questa notifica è inclusa solo in uno dei messaggi, il padding TFC può comunque essere inviato nell'altra direzione.

La notifica NON_FIRST_FRAGMENTS_ALSO viene utilizzata per il controllo della frammentazione. Vedere [IPSECARCH] per una spiegazione più completa. Entrambe le parti devono accettare l'invio di frammenti non-iniziali prima che una delle due lo faccia. È abilitata solo se la notifica NON_FIRST_FRAGMENTS_ALSO è inclusa sia nella richiesta che propone una SA sia nella risposta che la accetta. Se il risponditore non vuole inviare o ricevere frammenti non-iniziali, omette soltanto la notifica NON_FIRST_FRAGMENTS_ALSO dalla sua risposta, ma non rifiuta l'intera creazione della Child SA.

Una notifica IPCOMP_SUPPORTED, trattata nella Sezione 2.22, può essere inclusa anche nello scambio.

Un tentativo fallito di creare una Child SA NON DOVREBBE abbattere la IKE SA: non c'è motivo di perdere il lavoro svolto per impostare la IKE SA. Vedere la Sezione 2.21 per un elenco dei messaggi di errore che potrebbero verificarsi se la creazione di una Child SA fallisce.