2.4. Sincronizzazione dello stato e timeout di connessione
2.4. Sincronizzazione dello stato e timeout di connessione
A un endpoint IKE è permesso dimenticare tutto il suo stato associato a un'IKE SA e alla raccolta delle corrispondenti Child SA in qualsiasi momento. Questo è il comportamento previsto in caso di crash e riavvio di un endpoint. È importante che quando un endpoint fallisce o reinizializza il suo stato, l'altro endpoint rilevi queste condizioni e non continui a sprecare larghezza di banda di rete inviando pacchetti su SA scartate e facendoli cadere in un buco nero.
La notifica INITIAL_CONTACT asserisce che questa IKE SA è l'unica IKE SA attualmente attiva tra le identità autenticate. PUÒ essere inviata quando un'IKE SA viene stabilita dopo un crash, e il destinatario PUÒ usare queste informazioni per eliminare qualsiasi altra IKE SA che ha verso la stessa identità autenticata senza attendere un timeout. Questa notifica NON DEVE essere inviata da un'entità che può essere replicata (ad es., le credenziali di un utente in roaming dove all'utente è permesso connettersi al firewall aziendale da due sistemi remoti allo stesso tempo). La notifica INITIAL_CONTACT, se inviata, DEVE trovarsi nella prima richiesta o risposta IKE_AUTH, non come uno scambio separato successivo; le parti riceventi POSSONO ignorarla in altri messaggi.
Poiché IKE è progettato per operare nonostante gli attacchi DoS dalla rete, un endpoint NON DEVE concludere che l'altro endpoint è fallito basandosi su qualsiasi informazione di routing (ad es., messaggi ICMP) o messaggi IKE che arrivano senza protezione crittografica (ad es., messaggi Notify che lamentano SPI sconosciute). Un endpoint DEVE concludere che l'altro endpoint è fallito solo quando tentativi ripetuti di contattarlo sono rimasti senza risposta per un periodo di timeout o quando una notifica INITIAL_CONTACT protetta crittograficamente viene ricevuta su un'IKE SA diversa verso la stessa identità autenticata. Un endpoint dovrebbe sospettare che l'altro endpoint sia fallito basandosi sulle informazioni di routing e avviare una richiesta per vedere se l'altro endpoint è vivo. Per verificare se l'altra parte è viva, IKE specifica un messaggio INFORMATIONAL vuoto che (come tutte le richieste IKE) richiede un acknowledgement (si noti che nel contesto di un'IKE SA, un messaggio "vuoto" consiste in un header IKE seguito da un payload Encrypted che non contiene alcun payload). Se di recente è stato ricevuto dall'altra parte un messaggio protetto crittograficamente (fresco, cioè non ritrasmesso), i messaggi Notify non protetti POSSONO essere ignorati. Le implementazioni DEVONO limitare la frequenza con cui intraprendono azioni basate su messaggi non protetti.
Il numero di nuovi tentativi e la durata dei timeout non sono coperti da questa specifica perché non influenzano l'interoperabilità. Si suggerisce che i messaggi vengano ritrasmessi almeno una dozzina di volte su un periodo di almeno alcuni minuti prima di rinunciare a un'SA, ma ambienti diversi possono richiedere regole diverse. Per essere un buon cittadino di rete, i tempi di ritrasmissione DEVONO aumentare esponenzialmente per evitare di inondare la rete e peggiorare una situazione di congestione esistente. Se c'è stato solo traffico in uscita su tutte le SA associate a un'IKE SA, è essenziale confermare la vivacità dell'altro endpoint per evitare buchi neri. Se di recente non sono stati ricevuti messaggi protetti crittograficamente su un'IKE SA o su una qualsiasi delle sue Child SA, il sistema deve eseguire un controllo di vivacità per evitare di inviare messaggi a un peer morto.
(Questo è talvolta chiamato "dead peer detection" o "DPD", sebbene in realtà rilevi i peer vivi, non quelli morti.) La ricezione di un messaggio fresco protetto crittograficamente su un'IKE SA o su una qualsiasi delle sue Child SA garantisce la vivacità dell'IKE SA e di tutte le sue Child SA. Si noti che questo pone requisiti sui modi di guasto di un endpoint IKE. Un'implementazione deve smettere di inviare su qualsiasi SA se qualche guasto gli impedisce di ricevere su tutte le SA associate. Se un sistema crea Child SA che possono fallire indipendentemente l'una dall'altra senza che l'IKE SA associata possa inviare un messaggio di eliminazione, allora il sistema DEVE negoziare tali Child SA utilizzando IKE SA separate.
C'è un attacco DoS contro l'iniziatore di un'IKE SA che può essere evitato se l'iniziatore prende le dovute precauzioni. Poiché i primi due messaggi di una creazione di SA non sono protetti crittograficamente, un attaccante potrebbe rispondere al messaggio dell'iniziatore prima del vero risponditore e avvelenare il tentativo di stabilire la connessione. Per prevenire questo, l'iniziatore PUÒ essere disposto ad accettare più risposte al suo primo messaggio, trattare ciascuna come potenzialmente legittima, rispondere ad essa, e poi scartare tutte le connessioni semi-aperte non valide quando riceve una risposta valida protetta crittograficamente a una qualsiasi delle sue richieste. Una volta ricevuta una risposta crittograficamente valida, tutte le risposte successive dovrebbero essere ignorate siano o meno crittograficamente valide.
Si noti che con queste regole, non c'è motivo di negoziare e concordare una durata di vita dell'SA. Se IKE presume che il partner sia morto, basandosi sulla mancanza ripetuta di acknowledgement a un messaggio IKE, allora l'IKE SA e tutte le Child SA create tramite quell'IKE SA vengono eliminate.
Un endpoint IKE può in qualsiasi momento eliminare Child SA inattive per recuperare le risorse utilizzate per mantenere il loro stato. Se un endpoint IKE sceglie di eliminare Child SA, DEVE inviare payload Delete all'altra estremità notificandole l'eliminazione. PUÒ similmente far scadere l'IKE SA. La chiusura dell'IKE SA chiude implicitamente tutte le Child SA associate. In questo caso, un endpoint IKE DOVREBBE inviare un payload Delete indicando che ha chiuso l'IKE SA a meno che l'altro endpoint non stia più rispondendo.