2.1. Uso dei timer di ritrasmissione
2.1. Uso dei timer di ritrasmissione
Tutti i messaggi in IKE esistono in coppie: una richiesta e una risposta. La creazione di un'IKE SA normalmente consiste in due scambi. Una volta creata l'IKE SA, entrambe le estremità della Security Association possono avviare richieste in qualsiasi momento, e in un dato momento possono esserci molte richieste e risposte "in volo". Ma ogni messaggio è etichettato come richiesta o risposta, e per ogni scambio, un'estremità della Security Association è l'iniziatore e l'altra è il risponditore.
Per ogni coppia di messaggi IKE, l'iniziatore è responsabile della ritrasmissione in caso di timeout. Il risponditore NON DEVE mai ritrasmettere una risposta a meno che non riceva una ritrasmissione della richiesta. In tal caso, il risponditore NON DEVE tenere conto della richiesta ritrasmessa se non nella misura in cui essa provoca una ritrasmissione della risposta. L'iniziatore DEVE ricordare ogni richiesta finché non riceve la corrispondente risposta. Il risponditore DEVE ricordare ogni risposta finché non riceve una richiesta il cui numero di sequenza è maggiore o uguale al numero di sequenza nella risposta più la sua dimensione della finestra (vedi Sezione 2.3). Per consentire di risparmiare memoria, ai risponditori è permesso di dimenticare la risposta dopo un timeout di alcuni minuti. Se il risponditore riceve una richiesta ritrasmessa per la quale ha già dimenticato la risposta, DEVE ignorare la richiesta (e non, per esempio, tentare di costruire una nuova risposta).
IKE è un protocollo affidabile: l'iniziatore DEVE ritrasmettere una richiesta finché non riceve una risposta corrispondente o non ritiene che l'IKE SA sia fallita. In quest'ultimo caso, l'iniziatore scarta tutto lo stato associato all'IKE SA e a qualsiasi Child SA negoziata utilizzando quell'IKE SA. Una ritrasmissione da parte dell'iniziatore DEVE essere bit-identica alla richiesta originale. Cioè, tutto ciò che inizia dall'header IKE (l'SPI dell'iniziatore dell'IKE SA in poi) deve essere bit-identico; gli elementi che lo precedono (come gli header IP e UDP) non devono essere identici.
Le ritrasmissioni della richiesta IKE_SA_INIT richiedono una gestione speciale. Quando un risponditore riceve una richiesta IKE_SA_INIT, deve determinare se il pacchetto è una ritrasmissione appartenente a un'IKE SA esistente "semi-aperta" (in tal caso il risponditore ritrasmette la stessa risposta), o una nuova richiesta (in tal caso il risponditore crea una nuova IKE SA e invia una nuova risposta), oppure appartiene a un'IKE SA esistente in cui la richiesta IKE_AUTH è già stata ricevuta (in tal caso il risponditore la ignora).
Non è sufficiente usare l'SPI dell'iniziatore e/o l'indirizzo IP per distinguere tra questi tre casi perché due peer diversi dietro un singolo NAT potrebbero scegliere lo stesso SPI dell'iniziatore. Invece, un risponditore robusto eseguirà la ricerca dell'IKE SA utilizzando l'intero pacchetto, il suo hash o il payload Ni.
La politica di ritrasmissione per i messaggi unidirezionali è in qualche modo diversa da quella per i messaggi regolari. Poiché non viene mai inviato alcun acknowledgement, non c'è motivo di ritrasmettere gratuitamente i messaggi unidirezionali. Dato che tutti questi messaggi sono errori, ha senso inviarli solo una volta per ogni pacchetto "incriminato", e ritrasmetterli solo se vengono ricevuti ulteriori pacchetti incriminati. Tuttavia, ha anche senso limitare le ritrasmissioni di tali messaggi di errore.