2.4. State Synchronization and Connection Timeouts (Sincronizzazione dello stato e timeout)
2.4. State Synchronization and Connection Timeouts (Sincronizzazione dello stato e timeout)
Un endpoint IKE PUÒ dimenticare in qualsiasi momento tutto lo stato associato a una IKE SA e ai Child SA corrispondenti (ad es. dopo crash e riavvio). È importante che l'altro endpoint rilevi il fallimento e non continui a sprecare banda su SA scartate.
La notifica INITIAL_CONTACT afferma che questa IKE SA è l'unica attiva tra le identità autenticate. PUÒ essere inviata dopo un crash; il destinatario PUÒ eliminare altre IKE SA verso la stessa identità senza attendere un timeout. NON DEVE essere inviata da entità replicabili. Se inviata, DEVE essere nella prima richiesta o risposta IKE_AUTH, non in uno scambio separato dopo; i destinatari POSSONO ignorarla altrove.
Poiché IKE resiste ai DoS sulla rete, un endpoint NON DEVE concludere che l'altro è fallito solo in base a informazioni di routing (ICMP) o messaggi IKE non protetti (Notify su SPI sconosciuti). DEVE concludere il fallimento solo dopo tentativi ripetuti senza risposta entro un timeout o su ricezione di INITIAL_CONTACT protetto su un'altra IKE SA verso la stessa identità. Può sospettare un fallimento dal routing e avviare un controllo di vitalità. IKE specifica una richiesta INFORMATIONAL vuota che richiede acknowledgement (in una IKE SA, « vuoto » significa intestazione IKE seguita da payload criptato senza payload interni). Se è stato ricevuto di recente un messaggio protetto fresco, i Notify non protetti POSSONO essere ignorati. Le implementazioni DEVONO limitare la frequenza delle azioni basate su messaggi non protetti.
Numero di tentativi e durata dei timeout non sono specificati; si suggeriscono almeno una dozzina di ritrasmissioni su diversi minuti; i tempi di ritrasmissione DEVONO crescere in modo esponenziale. Se c'è stato solo traffico in uscita su tutte le SA associate a una IKE SA, è essenziale confermare la vitalità dell'altro endpoint. Senza messaggi protetti recenti su IKE SA o Child SA, serve un controllo di vitalità (« DPD », in realtà rilevamento di peer vivi). Un messaggio protetto fresco su IKE SA o Child SA garantisce la vitalità dell'IKE SA e di tutti i Child SA. Un'implementazione DEVE smettere di inviare su qualsiasi SA se un guasto impedisce la ricezione su tutte le SA associate. Se i Child SA possono fallire indipendentemente senza che l'IKE SA possa inviare delete, tali Child SA DEVONO essere negoziati con IKE SA separate.
Un tipo di DoS sull'iniziatore delle prime due fasi non protette può essere evitato se l'iniziatore PUÒ accettare più risposte al primo messaggio, rispondere a ciascuna e scartare le connessioni semi-aperte non valide quando arriva una risposta protetta valida a una richiesta; dopo, ignorare tutte le risposte successive.
Con queste regole non serve negoziare una durata di vita della SA: se IKE presume il partner morto per mancanza ripetuta di acknowledgement, elimina IKE SA e Child SA.
Un endpoint PUÒ eliminare Child SA inattivi; in tal caso DEVE inviare payload Delete. PUÒ anche far scadere la IKE SA. Chiudere la IKE SA chiude implicitamente i Child SA; in tal caso DOVREBBE inviare Delete per la IKE SA salvo che l'altro endpoint non risponda più.