IKEv2 ha il concetto di una modalità COOKIE , per tentare di prevenire l'esaurimento dello stato da alluvioni di iniziazione richieste da indirizzi IP inesistenti:
Two expected attacks against IKE are state and CPU exhaustion, where the target is flooded with session initiation requests from forged IP addresses. These attacks can be made less effective if a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which it claims to be sending them.
Un iniziatore invia una richiesta a un risponditore; il risponditore costruisce un cookie utilizzando un segreto l'iniziatore non ha più dettagli dalla richiesta e lo invia di nuovo all'iniziatore. L'iniziatore quindi ripete la richiesta ma questa volta con il cookie allegato, dimostrando così che possono ricevere pacchetti inviati all'indirizzo IP di origine della richiesta.
La RFC raccomanda come si può costruire il cookie:
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
Dove Ni , IPi e SPIi sono valori non segreti che definiscono in modo univoco le richieste da un indirizzo IP.
La RFC prosegue dicendo che
The responder should change the value of
<secret>frequently, especially if under attack.
Perché la RFC formula questa raccomandazione?
Strongswan implementa questo limitando il numero di utilizzi di un segreto a 10000 . Windows incorpora un valore temporale con una risoluzione di 150 secondi (vedere paragrafo 28) nel cookie.
Se il segreto è mai modificato, una volta che un utente malintenzionato ha visto una risposta per un determinato IP sorgente e parametri di richiesta, può quindi inviare spam al risponditore con richieste insieme a un cookie corretto. Quindi c'è sicuramente una buona ragione per cambiarlo ad un certo punto.
Ma (assumendo una buona funzione di hash) il cookie non fa trapelare informazioni utili sul segreto per l'attacker inondazione. Quindi, senza cambiare il segreto più spesso di, per esempio, ogni giorno al massimo, questo schema sembra fornire protezione contro l'obiettivo dichiarato (esaurimento dello stato da alluvioni di richieste da indirizzi IP al di fuori del controllo dell'attaccante). Un utente malintenzionato deve osservare una risposta dal risponditore a una richiesta da ciascun indirizzo IP da cui desidera inviare richieste prima che il risponditore mantenga uno stato per quella richiesta.
Quindi perché "frequentemente"?
(Una risposta legittima potrebbe essere "perché no?" - Mi sto solo chiedendo se c'è dell'altro.)