Resumen

  • Sustituir una IKE SA renueva el contexto protegido de control: SPI, claves y contadores de mensajes. La sucesora hereda las Child SA existentes, que conservan sus propios SPI, selectores, algoritmos, claves y tiempos de vida.
  • Sustituir una Child SA es otra operación. En una colisión simultánea, la SA creada por el intercambio que contiene el nonce más bajo es la candidata redundante que se cierra; no es la ganadora.
  • Un resultado verificable requiere tres recibos enlazados: linaje de control, inventario bajo custodia y evidencia en ejecución. Un único indicador de “rekey” no prueba rotación de claves de tráfico ni continuidad del servicio.

Imaginemos el minuto posterior a un mantenimiento. El nuevo canal IKE responde, el anterior está a punto de borrarse y el flujo ESP nunca se detuvo. Un informe puede celebrar que la VPN cambió sus claves. Sin embargo, los paquetes pueden seguir protegidos por las mismas Child SA que existían antes del relevo.

La arquitectura permite precisamente esa continuidad. La IKE SA no es el túnel de datos; es el contexto que autentica a los pares y protege los intercambios con los que administran asociaciones. Las Child SA realizan el trabajo de AH o ESP. Cuando cambia el padre de control, los hijos pueden cambiar de custodia sin cambiar de identidad criptográfica.

Tero Kivinen aparece junto a Charlie Kaufman, Paul Hoffman, Yoav Nir y Pasi Eronen como autor de RFC 7296. La atribución importa porque hace rastreable una contribución. No convierte la norma colectiva del IETF en una decisión individual ni demuestra cómo se comporta un producto concreto.

La palabra rekey esconde tres solicitudes

Después de los intercambios iniciales, cualquiera de los extremos puede enviar CREATE_CHILD_SA. El nombre no agota su función: el mensaje crea una Child nueva, sustituye una Child existente o sustituye la propia IKE SA. La clasificación depende de propuestas, notificaciones e identificadores.

Una Child nueva lleva una propuesta SA, un nonce, quizá material adicional de intercambio de claves y TSi/TSr. El respondedor puede estrechar los selectores. Al sustituir una Child, REKEY_SA señala el protocolo y el SPI entrante de la asociación anterior. La sucesora no debería alterar de forma encubierta algoritmos o selectores.

Cuando el objetivo es la IKE SA, aparecen nuevos SPI de iniciador y respondedor, nuevas claves de control y un espacio nuevo de Message ID. La antigua IKE conserva sus contadores mientras termina las solicitudes pendientes. El mismo sobre de intercambio no convierte esas tres operaciones en un solo estado.

Además, un extremo puede rechazar CREATE_CHILD_SA posteriores. Capacidad y política siguen siendo locales. Los registros IANA evitan colisiones en nombres y números; no obligan a implementar una función ni acreditan que un intercambio terminó.

Control sin tráfico también es un estado válido

IKE_AUTH suele establecer la IKE SA y la primera Child SA en una secuencia próxima. Ese nacimiento conjunto invita a representarlas como una sola fila. RFC 7296 conserva su independencia: puede completarse la autenticación y fallar la Child; una creación posterior fallida no debe derribar necesariamente el control.

RFC 6023 describe incluso una iniciación sin Child. El par autenticado puede mantener liveness, detectar NAT, recibir avisos protegidos y crear la asociación de tráfico cuando haga falta. Sus autores son Yoav Nir, Hannes Tschofenig, Hui Deng y Raj Singh, no Kivinen. La referencia sirve para delimitar estados, no para ampliar su autoría.

Esa independencia obliga a registrar qué existe. Una IKE SA válida no prueba que haya tráfico. Una Child activa no prueba que el padre anterior pueda borrarse. Un flujo útil no demuestra que la próxima solicitud de mantenimiento esté protegida por el sucesor correcto.

La primera decisión de un panel debería ser separar objetos. Si todo se llama “túnel”, una asociación de control, dos direcciones de Child y varios candidatos de colisión quedan fundidos en un icono verde.

El relevo crea primero y elimina después

Rekey no modifica una SA en el sitio. RFC 7296 crea una nueva y elimina la anterior cuando la sucesión está lista. Esta secuencia make-before-break conserva una ventana de recuperación y explica por qué durante unos instantes hay más asociaciones de las que habrá al final.

La nueva IKE SA que sobrevive hereda todas las Child SA del original. A partir de entonces protege sus futuros mensajes de gestión. El último pedido de la IKE antigua es su propia eliminación. Si desaparece antes de que la custodia sea común en ambos extremos, el tráfico puede seguir vivo y aun así quedar huérfano para el siguiente rekey o delete.

Conviene registrar cuatro hitos distintos: creación del sucesor, aceptación por el otro extremo, inventario Child adjuntado y eliminación del predecesor. También el primer intercambio protegido por el nuevo IKE. La duración entre crear y usar no es la misma que entre crear y borrar.

No existe una vida útil única negociada para ambas partes. Cada implementación aplica su reloj local; la más corta suele disparar el relevo. Tiempo, volumen, actividad y política pertenecen al extremo que toma la decisión. La norma hace interoperable el procedimiento, no centraliza el criterio.

Custodia Child no equivale a clave Child nueva

Una Child heredada conserva su pareja de SPI, selectores, modo, algoritmos, época de clave, estado de secuencia y anti-replay, contadores y caducidad. Cambiar el IKE padre solo cambia quién protege las próximas órdenes sobre ella.

Por eso una evidencia con SPI IKE nuevos sustenta únicamente la rotación de control. Para afirmar que rotaron las claves de tráfico hacen falta los SPI Child anteriores y nuevos, la propuesta, los algoritmos seleccionados, la época de clave, la activación y el cierre de la pareja reemplazada.

RFC 8247 trata requisitos algorítmicos de IKEv2 y declara que no actualiza el cifrado ESP. RFC 8221 cubre por separado ESP y AH. Kivinen figura en ambos grupos de autores, pero los documentos no son intercambiables. El cumplimiento criptográfico necesita al menos dos inventarios.

La separación también evita una falsa fecha de migración. Puede modernizarse el control y mantener asociaciones de datos más antiguas hasta su propio vencimiento. O puede sustituirse una Child sin tocar la IKE SA. Los relojes deben verse, no promediarse.

Identidad autenticada y selectores autorizados

La IKE SA protege la negociación y aporta evidencia de identidad del par. No autoriza por sí sola cualquier prefijo que ese par proponga. RFC 4301 exige que la Peer Authorization Database limite los selectores permitidos después de la autenticación.

El respondedor puede estrechar TSi y TSr. Ese resultado y la versión de política deben acompañar a la Child cuando pasa a un nuevo padre. Heredar la asociación no justifica ampliar redes de origen o destino.

“Par autenticado”, “Child instalada” y “selectores autorizados” responden a preguntas distintas. Si el registro guarda solo la primera, una credencial válida parece una autorización total. Si guarda solo la segunda, no explica por qué ese alcance era legítimo.

Aquí encaja la Especificación Inicial Mínima de Heng Lu. El estándar fija mensajes suficientes para coordinar sistemas independientes. La decisión futura —aceptar, estrechar, mantener o sustituir— queda localizada donde también cae el riesgo.

El tráfico nuevo comienza de manera asimétrica

El respondedor debe poder recibir por la SA nueva antes de emitir la respuesta de creación. El iniciador puede transmitir cuando procesa esa respuesta. El respondedor no sabe de inmediato si la respuesta llegó y si la mitad saliente del iniciador está lista.

Durante un rekey de Child, sigue enviando por la asociación antigua hasta recibir tráfico válido en la nueva mitad o una solicitud IKE para cerrar la vieja. Si el iniciador no tiene datos, puede enviar un paquete ESP vacío o ficticio como señal de preparación.

Esa señal prueba disponibilidad criptográfica mínima, no una transacción de aplicación. Tampoco una respuesta positiva prueba ruta de retorno, anti-replay, MTU o servicio útil. El resultado en ejecución necesita medidas independientes.

Iguales pares y selectores no identifican una Child de forma única. IKEv2 permite asociaciones paralelas, también para tratamiento diferenciado. Sin SPI y linaje, la observación puede sumar tráfico de un predecesor, un sucesor y una candidata redundante.

Cuando ambos extremos renuevan a la vez

Políticas de vida parecidas hacen posible que los dos lados inicien un rekey de Child casi al mismo tiempo. El jitter reduce la frecuencia, pero no elimina la carrera. Temporalmente quedan la pareja anterior y dos parejas nuevas.

Los receptores deben aceptar paquetes por cualquier candidata aún válida. Después se comparan octeto a octeto los cuatro nonces de los dos intercambios. La redacción exacta evita el error habitual: se cierra la SA creada por el intercambio que contiene el nonce más bajo. La más baja pierde.

Quien creó la pareja superviviente elimina la anterior sustituida. Quien creó la redundante elimina esa redundante. El historial debe retener las tres parejas y sus responsables para explicar por qué hubo dos deletes distintos.

Con pérdida de paquetes, un pedido tardío puede apuntar a una Child ya reemplazada. CHILD_SA_NOT_FOUND puede ser un desenlace no fatal de la carrera. Solo el SPI objetivo, el orden temporal y el árbol de sucesión permiten clasificarlo.

La carrera IKE añade un problema de herencia

Los dos extremos también pueden sustituir la IKE SA simultáneamente. Quedan el padre antiguo y dos candidatos nuevos. La IKE nueva asociada al nonce más bajo se cierra; la superviviente debe heredar todas las Child.

Resolver la comparación no basta. Ambos pares tienen que concordar en la identidad del sucesor y en el conjunto completo de hijos antes de borrar el control viejo. Una discrepancia de inventario es un fallo de custodia aunque las claves del sucesor se hayan derivado correctamente.

Si una solicitud llega cuando el otro lado ya cierra el IKE antiguo, RFC 7296 prevé TEMPORARY_FAILURE. Tras recibir el delete del padre viejo, el par puede abandonar su intento concurrente. La notificación temporal puede documentar una resolución correcta, no una caída.

RFC 9370 añade intercambios de claves múltiples e IKE_FOLLOWUP_KE, y conserva la obligación de resolver la colisión antes de continuar. Tiene siete autores distintos y no debe atribuirse a Kivinen. Su lección es que una cadena más larga exige un recibo más preciso, no un éxito más genérico.

La firma de Kivinen no es una autoridad operativa

La ficha del IETF revisada el 31 de agosto de 2026 presenta a Tero Kivinen como chair de IPsecme, miembro del Tools Team, revisor y secretario de la Security Area Directorate. Cuenta 16 RFC y ningún Internet-Draft activo. Es una instantánea, no una garantía de producto.

RFC 7296 tiene cinco autores. RFC 8247 y RFC 8221 tienen grupos propios. RFC 6023 y RFC 9370 pertenecen a otros equipos. Preservar estas fronteras mantiene trazabilidad sin fabricar un dueño del protocolo.

En términos del problema de agencia de Heng Lu, el IETF y los autores ofrecen un instrumento de coordinación acotado. Los operadores siguen decidiendo temporizadores, autorizaciones, algoritmos y despliegue. También son quienes deben aportar evidencia de lo que su código ejecutó.

IANA registra vocabulario de intercambios, payloads, transformaciones y notificaciones. Su autoridad termina en hacer los códigos legibles y no conflictivos. Implementación, aceptación y entrega de tráfico se comprueban en otro lugar.

Tres libros que pueden unirse sin fusionarse

El libro de control guarda identidad del par, SPI IKE viejos y nuevos, algoritmos, nonces, Message ID, disparador local, carrera, elección del sucesor, primer mensaje protegido y cierre anterior.

El libro de custodia enumera cada pareja Child, SPI, selectores, decisión PAD/SPD, modo, algoritmos, época de clave, vida local, padre anterior y nuevo, si fue heredada o sustituida y cuándo se borró.

El libro de ejecución observa aceptación de paquetes, secuencias, anti-replay, causas de descarte, señal ficticia, primer tráfico útil bidireccional y continuidad de aplicación. La Primacía del Código en Ejecución exige este tercer libro: una especificación explica el resultado esperado; los paquetes muestran el resultado alcanzado.

Solo la unión por SPI, tiempo y linaje permite concluir. Un IKE rekey correcto no prueba nuevas claves Child. Un flujo Child vivo no prueba que el padre correcto controle su próximo ciclo. Un contador no debe responder a tres preguntas.

Fuentes