Passa al contenuto principale

1.3.3. Rinnovo (rekey) delle Child SA con lo scambio CREATE_CHILD_SA

1.3.3. Rinnovo (rekey) delle Child SA con lo scambio CREATE_CHILD_SA​

La richiesta CREATE_CHILD_SA per rinnovare una Child SA è:

Initiator Responder​

HDR, SK {N(REKEY_SA), 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.

Le notifiche descritte nella Sezione 1.3.1 possono essere inviate anche in uno scambio di rekey. Di solito, queste saranno le stesse notifiche utilizzate nello scambio originale; ad esempio, quando si rinnova una SA in modalità trasporto, verrà utilizzata la notifica USE_TRANSPORT_MODE.

La notifica REKEY_SA DEVE essere inclusa in uno scambio CREATE_CHILD_SA se lo scopo dello scambio è sostituire una SA ESP o AH esistente. La SA in fase di rinnovo è identificata dal campo SPI nel payload Notify; questo è lo SPI che l'iniziatore dello scambio si aspetterebbe nei pacchetti ESP o AH in ingresso. Non ci sono dati associati a questo tipo di messaggio Notify. Il campo Protocol ID della notifica REKEY_SA è impostato per corrispondere al protocollo della SA che stiamo rinnovando, ad esempio 3 per ESP e 2 per AH.

La risposta CREATE_CHILD_SA per rinnovare una 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.