Resumen

  • La pareja de cookies identificaba la SA de ISAKMP; el Message ID identificaba el estado de una negociación de fase 2; los SPI identificaban propuestas y luego estado de protocolo. Eran ámbitos distintos, no pruebas de identidad.
  • RFC 2408 exigía autenticación fuerte y dejaba las respuestas, las selecciones, la instalación y la limpieza a mecanismos y políticas separados. Un mensaje bien correlacionado podía todavía ser rechazado, no instalarse o no producir tráfico útil.

Dos negociaciones parten casi al mismo tiempo. Comparten los mismos dos cookies porque viven bajo la misma asociación ISAKMP. Sus Message ID son distintos. Cada respuesta vuelve al estado correcto. El mecanismo ha resuelto una carrera real sin resolver todavía la pregunta más importante: ¿quién estaba autorizado a pedir esas asociaciones?

RFC 2408 diseñó el Message ID para ese problema acotado. El iniciador de la fase 2 generaba un valor de cuatro octetos. Durante la fase 1 el campo debía ser cero, porque allí la pareja de cookies ya identificaba la asociación ISAKMP. En fase 2, el valor distinguía trabajo concurrente dentro del contexto padre.

La distinción ayuda a leer una captura. La pareja Initiator Cookie/Responder Cookie selecciona una SA de gestión. El Message ID sigue un intercambio subordinado. Los SPI incluidos en Proposal identifican las asociaciones de los protocolos que se están creando. Una vez terminada la negociación, el SPI del encabezado ESP o AH selecciona el estado que procesa el paquete.

No son cuatro formas de escribir el mismo identificador. Son cuatro llaves para cuatro almacenes o épocas. Si un sistema de observabilidad conserva sólo una etiqueta de “túnel”, pierde la posibilidad de demostrar en qué transición se produjo el error.

El cookie tenía otra historia antes de convertirse en parte de la pareja. RFC 2408 lo definió como token antiatasco. El servidor necesitaba responder a peticiones iniciales sin gastar primero el coste de una operación de clave pública. La función debía ser rápida, depender de las partes y usar un secreto local para que un tercero no pudiera fabricar un token aceptable.

La propuesta de construcción combinaba direcciones, puertos, secreto y tiempo. La singularidad por establecimiento ayudaba contra replay. Pero la dirección del paquete no se convirtió por eso en identidad. La capacidad de devolver un token emitido por el servidor no demostró la posesión de un certificado ni el derecho a una política.

El propio RFC negó una promesa absoluta contra denegación de servicio. Un atacante podía seguir provocando estado con direcciones falsas; por eso hacían falta recolección de basura y gestión agresiva de memoria. La prueba operativa debía incluir ocupación, expiración y coste, no sólo tasa de cookies válidos.

ISAKMP era un marco separado del intercambio de claves concreto. Definía procedimientos y formatos para establecer, negociar, modificar y borrar asociaciones. Transportaba datos de generación de claves y autenticación sin imponer una sola técnica, algoritmo o mecanismo. Esa neutralidad permitía reutilización y obligaba a conservar el origen de cada garantía.

El encabezado fijo mantenía el estado y guiaba el parser. Exchange Type seleccionaba la gramática. Next Payload nombraba la primera carga; cada carga indicaba la siguiente. Version, flags y Length limitaban la interpretación. La cadena podía incluir SA, Proposal, Transform, Key Exchange, ID, Certificate, Hash, Signature, Nonce, Notification, Delete o Vendor ID.

El procesamiento era secuencial. El receptor verificaba cookies, Next Payload, versión, tipo de intercambio, flags y Message ID. Un fallo provocaba descarte. Registrar el hecho o enviar una notificación era en muchos casos opcional y quedaba bajo la política local.

Por eso INVALID-MESSAGE-ID no era una verdad global. Era el diagnóstico de un receptor sobre un campo dentro de un contexto. Para convertirlo en evidencia de incidente había que conservar la pareja de cookies, la fase, el paquete, la regla que decidió notificar, el estado que se descartó y la recepción —si la hubo— del otro extremo.

La validación de cookies tampoco autenticaba al interlocutor. RFC 2408 exigía autenticación fuerte porque, sin ella, no podía confiarse en la identificación de la entidad. Certificados, hashes, firmas u otros mecanismos aportaban esa capa según el intercambio. El token antiatasco llegaba antes y contestaba otra pregunta.

Esta separación era importante en las dos fases. La primera establecía una SA ISAKMP que protegía actividades posteriores. La segunda creaba asociaciones para otros protocolos. El coste de la primera podía repartirse entre varias segundas fases.

También podía cambiar el sujeto. En la fase 1 podían autenticarse servidores u hosts; en la fase 2, usuarios o programas. Asociar automáticamente todos los hijos con el nombre mostrado para el padre podía asignar autoridad a la entidad equivocada. La bitácora necesitaba sujeto, credencial y fase.

La política local seguía decidiendo el contenido. Un iniciador podía ofrecer una propuesta y limitar la elección. Si enviaba varias en orden de preferencia, el respondedor elegía según su política. El Message ID preservaba la conversación; no daba legitimidad a una alternativa.

Después venía la instalación. El respondedor devolvía el mismo Message ID y sus SPI para la propuesta aceptada. Esto probaba una respuesta de negociación. No probaba que la interfaz entre el daemon y el kernel aceptara el estado, que los selectores coincidieran con el flujo o que un paquete fuera admitido por la aplicación.

El bit Commit intentaba cerrar una parte del hueco. Si una parte lo activaba, la otra esperaba un intercambio Informational protegido con CONNECTED. Ese aviso llevaba el Message ID original para asociarlo con la fase 2 correcta.

Incluso allí quedaba incertidumbre. El mensaje final podía perderse. RFC 2408 no normalizó una única recuperación: se podía aceptar tráfico protegido verificable como indicio o retransmitir el último mensaje. Una implementación podía retenerlo hasta tener suficiente certeza. La coordinación era explícita, pero no infalible.

Delete mostró todavía mejor la semántica limitada. El emisor anunciaba que había eliminado una SA de su propia base. No pedía al receptor que borrara la suya. No se esperaba acuse. El receptor normalmente debía limpiar su estado, pero la política local gobernaba la continuación.

Un analista no puede mirar un Delete y declarar “ambos lados borraron”. Necesita verificar la protección del aviso, la decisión del receptor, la mutación de su base, los SPI afectados, los paquetes posteriores y cualquier restablecimiento. El mensaje describía el estado del emisor y aconsejaba una reacción; no certificaba la reacción.

Las capas de realidad de Lu Heng ofrecen una taxonomía clara. El cookie es una realidad de correlación y coste. Message ID es una realidad de estado de protocolo. La cadena Next Payload es una realidad sintáctica. La autenticación es una realidad de vínculo. La política es una realidad de permiso. La SA instalada es una realidad ejecutable. El paquete y la aplicación son realidades de resultado.

El problema de agencia aparece cuando el daemon habla por todos. Puede afirmar que correlacionó, autenticó o negoció. No controla necesariamente el inventario de credenciales, la regla autorizadora, la instalación en el kernel ni la utilidad en la aplicación. Un único estado “up” borra a los propietarios restantes.

La primacía del código en ejecución no desprecia el protocolo; lo completa. Conserva cookies y Message ID, y los une a la huella de credencial, la regla versionada, la propuesta elegida, el recibo de instalación, el SPI de ejecución, los selectores, los contadores, la decisión del paquete y la observación del servicio.

RFC 2408 se publicó en noviembre de 1998. RFC 4306 sustituyó la familia separada 2407/2408/2409 en 2005 mediante IKEv2. En 2023 el IETF movió IKEv1 a Historic, y RFC 9395 cerró sus registros. RFC 7296 fue después el Internet Standard de IKEv2. La lección histórica no convierte sus algoritmos en recomendación actual.

El número encontró el estado correcto. Eso era esencial para una máquina con trabajo concurrente. La identidad, la autorización, la instalación y el resultado seguían necesitando sus propios recibos.

Fuentes