Resumen

  • Cuando todas las asociaciones RSVP aplicables han caducado, el borrador recomienda avisar al gestor y tratar la última como si tuviera vida infinita hasta que sea ampliada, eliminada o sustituida.
  • La excepción mantiene una relación autenticada conocida: no autoriza una degradación sin autenticación y evita que el reloj derribe reservas cuyo corte podría propagar una avería.
  • El cierre verificable de la excepción exige algo más que cargar una clave nueva: asociación sucesora activa, solapamiento suficiente, relojes fiables y handshake completado por cada receptor.

Una política puede decir que una clave termina a las 00:00. El router, sin embargo, todavía debe decidir qué hacer con el siguiente paquete a las 00:00:01.

Ese segundo es el centro de RSVP Cryptographic Authentication Version 2, revisión 02. Publicada el 27 de septiembre de 2026, la propuesta está en la última llamada del grupo de trabajo TEAS. Sigue siendo un Internet-Draft con aspiración a Proposed Standard: no es un RFC ni demuestra despliegues. Si progresa, sustituiría las reglas de RFC 2747 y RFC 3097.

El texto llama “caso patológico” a la situación en que todas las asociaciones de seguridad válidas para el intercambio han expirado. Volver a RSVP sin autenticación resulta inaceptable. Pero interrumpir reservas en curso también puede convertirse en un fallo de red mayor. Por eso recomienda notificar al responsable de red y, simultáneamente, tratar la última asociación como si su duración fuera infinita hasta que la gestión prolongue su vida, la borre o instale otra.

La regla ya estaba en la revisión 01. La -02 no la acaba de inventar. El hecho noticioso es que el compromiso continúa en el documento que ha llegado a la revisión actual del grupo: la caducidad señala un fallo de transición, pero no ordena automáticamente la caída.

RSVP, definido por RFC 2205 y ampliado para ingeniería de tráfico por RFC 3209, señaliza reservas de recursos. La autenticación v2 protege cada salto mediante un objeto INTEGRITY. Emisor y receptor significan aquí vecinos RSVP del salto, no necesariamente los extremos de una aplicación.

El objeto incorpora un Key Identifier de 48 bits, un número de secuencia de 64 bits y datos de autenticación. El receptor combina el identificador con la dirección de origen para escoger una asociación precisa. En ella constan además la transformación criptográfica, la clave, las interfaces o pares afectados y el intervalo de validez. Cada asociación protege un solo sentido.

Lo que prueba es acotado. El par que poseía la clave produjo un mensaje que ese receptor acepta como reciente. No cifra el contenido. Tampoco demuestra que una aplicación tuviera autoridad para reservar recursos, que la política de admisión aprobó la solicitud o que el plano de datos entregó el servicio. La autenticidad del mensaje y la realidad operativa no son sinónimos.

El número de secuencia introduce una dificultad después de un reinicio. Tiene que ser único y crecer durante toda la vida de la clave. Si el receptor pierde su referencia, un mensaje viejo puede parecer nuevo. El borrador obliga a implementar Integrity Handshake y aconseja activarlo por defecto. El receptor envía una cookie impredecible; el emisor devuelve esa cookie y su secuencia actual en una respuesta protegida.

Cada sesión RSVP debe apoyarse en ese handshake o conservar la secuencia en almacenamiento estable. RFC 4086 y RFC 8937 ayudan a producir el desafío aleatorio, pero no aportan el recibo operacional de que todos los receptores terminaron el intercambio.

La rotación tampoco ocurre en un punto único. La implementación debe admitir al menos dos asociaciones a la vez. La nueva empieza antes de que termine la anterior y ambas se solapan por un intervalo al menos dos veces superior a la incertidumbre de los relojes; el borrador señala que cinco minutos suelen bastar. Cada receptor debe ejecutar el handshake con la sucesora.

De ahí que “clave configurada” sea una descripción incompleta. La asociación nueva debe cubrir el mismo ámbito, estar activa según un reloj fiable, ser usada por el emisor, resultar seleccionable para el receptor y partir de una secuencia segura. Hasta que esos hechos se alineen, el relevo no existe aunque el inventario muestre dos claves.

La hora pasa a formar parte del control. El documento requiere sincronización suficiente y aconseja autenticar el mecanismo que distribuye el tiempo. RFC 5905 especifica NTPv4; una referencia a NTP en la configuración no acredita el desfase real ni la salud de su fuente.

Cuando hay una alternativa válida, la conducta con la clave antigua es inequívoca: un paquete que indique la asociación caducada debe descartarse antes del cálculo criptográfico. Conviene registrar el error con limitación de frecuencia. Así se impide que un par elija la credencial vieja después de que el relevo sea realmente utilizable.

Sin alternativa, el mismo paquete se valida como si la asociación no hubiese expirado. No es una bendición eterna para la criptografía antigua. Es una preferencia operativa: conservar el último vínculo autenticado conocido antes que aceptar mensajes desnudos o desorganizar reservas porque cambió el día del calendario.

La continuidad oculta su propio problema. El servicio sigue funcionando y, por tanto, la reparación pierde prioridad. Una alerta puede llegar a una cola sin dueño. La palabra “infinita” elimina cualquier segundo vencimiento automático: solo una acción administrativa saca al sistema de la excepción.

El borrador no define cómo distribuir claves. Exige que se admita la carga manual, permite —aunque desaconseja— una vida manual sin fin y deja la agilidad de algoritmos a un registro de transformaciones de IANA. La compatibilidad de formato con HMAC-MD5 sigue presente; RFC 6151 explica por qué esa herencia debe leerse con cautela. Ningún registro de algoritmos lleva el nuevo secreto hasta cada vecino.

La evidencia mínima debe describir el relevo: identificador y dirección del emisor, ámbito de par e interfaz, transformación, fechas configuradas, asociación sucesora, ventana de solapamiento, error de reloj, receptores esperados, handshake individual, primer mensaje aceptado tras la caducidad, entrega y reconocimiento del aviso, y acción que cerró la excepción. No hace falta guardar el secreto; sí la procedencia del estado.

Esa trazabilidad separa cuatro acontecimientos: crear la clave, activar la asociación, inicializar de forma segura cada receptor y conseguir que la antigua deje de ser la única utilizable. Solo el cuarto acredita la rotación completa.

La idea de Heng Lu sobre la primacía del código en ejecución obliga a mirar el estado que procesa paquetes y no el rótulo del inventario. La especificación inicial mínima permite que el protocolo compartido exponga el punto de decisión sin apropiarse de la política local. Las capas de realidad recuerdan que “caducada” es una categoría simbólica, no la constatación de que la confianza dejó de operar.

Cuando vence la última clave, RSVP conserva el camino, genera la señal y deja al descubierto la verdadera pregunta: quién puede decidir cuánto tiempo seguirá siendo aceptable.

Fuentes