IKEv2 tiene el concepto de un modo COOKIE , para intentar evitar el agotamiento del estado por inundaciones de iniciación solicitudes de direcciones IP inexistentes:
Dos ataques esperados contra IKE son el estado y el agotamiento de la CPU, donde el destino se inunda con solicitudes de inicio de sesión de IP falsificada direcciones Estos ataques pueden hacerse menos efectivos si un respondedor utiliza una CPU mínima y no confirma ningún estado a una SA hasta que conozca la El iniciador puede recibir paquetes en la dirección desde la cual afirma estaré enviándolos.
Un iniciador envía una solicitud a un respondedor; el respondedor construye una cookie utilizando un secreto que el iniciador no tiene más detalles de la solicitud y la envía de vuelta al iniciador. El iniciador luego repite la solicitud, pero esta vez con la cookie adjunta, lo que demuestra que pueden recibir los paquetes enviados a la dirección IP de origen de la solicitud.
El RFC recomienda cómo se podría construir la cookie:
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
Donde Ni , IPi y SPIi son valores no secretos que definen de forma única las solicitudes de una dirección IP.
El RFC continúa diciendo que
El respondedor debe cambiar el valor de
<secret>con frecuencia, especialmente si está bajo ataque.
¿Por qué el RFC hace esta recomendación?
Strongswan implementa esto mediante limitando el número de usos de un secreto a 10000 . Windows incrusta un valor de tiempo con una resolución de 150 segundos (consulte el párrafo 28) en la cookie.
Si no se cambia el secreto nunca , una vez que un atacante haya visto una respuesta para un IP de origen y parámetros de solicitud determinados, puede enviar correo no deseado al respondedor junto con una cookie correcta. Así que ciertamente hay una buena razón para cambiarlo en algún momento.
Pero (asumiendo una buena función hash), la cookie no filtra información útil sobre el secreto del atacante de inundación. Entonces, sin cambiar el secreto más a menudo que, digamos, a lo sumo a diario, este esquema parece proporcionar protección contra el objetivo establecido (agotamiento por estado de las inundaciones de solicitudes de direcciones IP fuera del control del atacante). Un atacante debe observar una respuesta del respondedor a una solicitud de cada dirección IP desde la que desea enviar las solicitudes antes de que el respondedor mantenga cualquier estado para esa solicitud.
Entonces, ¿por qué "con frecuencia"?
(Una respuesta legítima podría ser "¿por qué no?". Me pregunto si hay algo más que hacer.)