Resumen

  • RFC 7474 combina 32 bits de contador de arranques con 32 bits de contador de paquetes. La primera mitad persiste fuera de la memoria volátil; la segunda aumenta por cada envío, y el receptor descarta toda secuencia que no supere la última aceptada para ese tipo de paquete.
  • Acee Lindem editó la norma colectiva firmada con Manav Bhatia, Sam Hartman y Dacheng Zhang. El mecanismo tiene una condición operativa severa: si una reparación o sustitución pierde la historia persistente, las claves anteriores también deben retirarse.

La captura que esperó a que el vecino olvidara

Supongamos que alguien registra un paquete OSPF Database Description protegido con la clave correcta. No puede modificarlo ni fabricar otro. Mientras el receptor recuerda valores posteriores, la copia no sirve. Después cae la adyacencia, el proceso vuelve a empezar y la secuencia ligada al vecino se reinicializa. La grabación no se ha vuelto más legítima; ha encontrado un verificador sin memoria.

Ese es el problema específico que corrige RFC 7474, publicada en abril de 2015 en el Standards Track. El diseño previo almacenaba los números de secuencia como parte del estado de la adyacencia. Al desaparecer esa relación, desaparecía también una parte de la defensa contra repeticiones entre sesiones.

La autoría completa es Manav Bhatia, Sam Hartman, Dacheng Zhang y Acee Lindem, que figura como editor. El registro público de la IETF acredita la participación de Lindem y una trayectoria más amplia en routing. No acredita invención individual, control del protocolo ni calidad de una implementación. Aquí interesa una contribución comprobable dentro de un resultado común: hacer que la identidad temporal del emisor sobreviva al fallo que antes la borraba.

Una firma correcta puede llegar tarde

RFC 5709 incorporó HMAC-SHA a la autenticación OSPFv2. Sus autores son Manav Bhatia, Vishwas Manral, Michael Fanto, Russ White, Michael Barnes, Tony Li y Randall Atkinson; Lindem no está en ese grupo. Un algoritmo más fuerte dificulta la falsificación, pero no convierte en reciente un mensaje producido correctamente en el pasado.

RFC 6039, de Vishwas Manral, Manav Bhatia, Joel Jaeggli y Russ White, expone problemas generales de la protección criptográfica con claves manuales: secretos largos, rotación costosa, repetición y contexto insuficiente. Se usa como antecedente técnico, no para trasladar su autoría a Lindem.

La distinción cambia la lectura de las alarmas. Integridad responde si los bytes protegidos cambiaron. Autenticidad vincula el mensaje con quien conoce el secreto. Frescura pregunta si pertenece a esta vida del protocolo. Ninguna de las dos primeras respuestas resuelve automáticamente la tercera.

Dos contadores forman una época

RFC 7474 amplía la secuencia criptográfica a 64 bits. Los 32 bits superiores contienen un boot count; los inferiores, un contador de paquetes estrictamente creciente. El primero nombra la época del proceso y el segundo ordena los mensajes dentro de ella.

El boot count debe conservarse en almacenamiento no volátil durante toda la vida desplegada del router OSPFv2. Cada vez que se pierde el estado previo de secuencia, incluido un cold restart, el valor aumenta. Puede reutilizarse snmpEngineBoots, aunque el documento recomienda un contador específico de OSPF para no ligar su seguridad a reinicios distintos de SNMP.

La parte inferior aumenta con cada paquete. Al recibirlo, el vecino exige una secuencia mayor que la del último paquete aceptado del mismo tipo. Una cifra igual o menor se trata como repetición y se descarta. La separación por tipo permite que la priorización cambie el orden de llegada entre Hello, Database Description o Link State Update sin crear falsos positivos.

Cuando el contador bajo se agota, el alto puede avanzar para preservar la monotonía agregada. El reinicio deja de ser un agujero en la cronología: se transforma en un cambio de época que un paquete grabado antes no puede adelantar.

Los ocho octetos se colocan después del paquete OSPF y entran en el digest. El nuevo AuType 3 identifica la forma y el Key ID se extiende a 32 bits. Proteger el contador dentro del cálculo es imprescindible; de otro modo, el atacante podría alterar precisamente el dato que demuestra la antigüedad.

El origen IP deja de ser una etiqueta suelta

El cálculo anterior no protegía la cabecera IPv4. Sin embargo, en redes broadcast y NBMA, OSPF usa la dirección de origen para decidir qué vecino envió el paquete. Una copia con el origen cambiado podía afectar al estado de secuencia de otro vecino sin romper el digest original.

RFC 7474 coloca la dirección IPv4 de origen en los primeros cuatro octetos del padding de autenticación. El emisor incluye la dirección que utilizará y el receptor la que realmente recibió. Cambiarla provoca un fallo. Así se acotan ataques reflejados capaces de aparentar comunicación unidireccional o perturbar el intercambio de Database Description.

La norma no intenta inmovilizar cada campo de IP. Protege el dato del que depende la identidad de vecino en OSPF. Esa precisión importa: una especificación mínima es fuerte cuando comparte el hecho necesario y explica su efecto, no cuando acumula autoridad sobre todo lo que rodea al paquete.

La clave también debe saber para qué protocolo habla

Las bases de claves duraderas pueden compartir un secreto entre protocolos. Para impedir que una construcción válida en otro contexto se reutilice como OSPFv2, RFC 7474 añade un identificador criptográfico de protocolo de dos octetos antes de derivar la clave efectiva.

Es separación de dominios. No elimina la conveniencia de usar secretos diferentes; una filtración sigue afectando al material común. Pero evita que la igualdad de bytes en la base de claves borre la frontera semántica entre protocolos.

Girar una clave exige solapar aceptación

La clave de envío solo es válida dentro de SendLifetime; la de recepción, dentro de AcceptLifetime. Pueden no coincidir exactamente. La nueva clave se acepta antes de convertirse en preferida para transmitir y la antigua puede seguir aceptándose durante un intervalo acotado después del cambio. Ese solapamiento evita que la seguridad se convierta en una caída de adyacencia.

La elección también debe corresponder al algoritmo, peer o área, interfaz y dirección. Una coincidencia explícita vence a all. Entre varias claves transmisoras válidas se escoge la que tenga el inicio de envío más reciente. El Key ID de 32 bits permite que el receptor localice la clave simétrica, pero aún debe comprobar ámbito y ventana de aceptación.

Por tanto, una rotación no ocurre a medianoche en un solo equipo. Se distribuye la clave nueva, se abre recepción, se mueve transmisión, se observan ambos extremos y solo entonces se cierra la clave antigua. Dos secretos presentes en la configuración no demuestran solapamiento correcto, relojes sanos ni elección simétrica.

La incompatibilidad se muestra como rechazo

AuType 3 no degrada en silencio. Si el tipo recibido no coincide con el configurado en la interfaz, OSPF descarta el paquete. Durante una implantación parcial eso puede impedir una adyacencia, pero evita una relación aparentemente correcta que atribuya significados distintos a la misma secuencia.

La unidad de cambio debe incluir los dos extremos. Código compatible, tipo, algoritmo, Key ID, material secreto, ventanas y época tienen que coincidir. El éxito no es que una API acepte la configuración; es que ambos vecinos acepten el tráfico nuevo, rechacen la captura antigua, mantengan la adyacencia y conserven forwarding.

Sin historia persistente no existe continuidad de clave

La advertencia decisiva de RFC 7474 aparece en la reparación y sustitución. Si se pierde el boot count no volátil, deben cambiarse las claves. Restaurar el mismo Router ID, las mismas áreas y el mismo archivo de secretos reconstruye la apariencia del router, no la historia que impedía el replay.

Con la clave antigua y una época reiniciada, una captura previa vuelve a competir dentro del nuevo espacio bajo. De ahí que reemplazar hardware sea también una operación criptográfica, no solo de configuración.

La especificación reconoce límites adicionales. Repetir el establecimiento completo e idéntico de una sesión para un router totalmente retirado sigue siendo una posibilidad muy remota; cambiar las claves también la corta. Si dos enlaces punto a punto sin numerar usan el mismo origen y una secuencia común bajo una amenaza de escucha, se recomiendan claves distintas. La gestión automática queda fuera de alcance.

Regla común pequeña, responsabilidad local grande

El texto posterior de Lu Heng Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption sirve a Sofia Ren como marco. La forma de la secuencia, el origen protegido, el identificador de protocolo, el Key ID y el rechazo pueden ser comunes. Generación, custodia, ámbito, calendario, despliegue y recuperación quedan en manos de cada operador.

Running-Code Primacy obliga a unir intención y prueba: estado persistente, secuencia emitida, clave elegida, digest ligado al origen, decisión receptora, contadores de replay, adyacencia y forwarding. Esta comparación es análisis posterior de Sofia Ren, no evidencia de la intención privada de Lindem ni de una intención IETF fuera de los RFC.

Un atacante puede conservar el pasado mejor que el router. RFC 7474 exige que el router recupere esa ventaja. Si ya no puede demostrar qué época vivió, la clave que pertenecía a ella tampoco debe inaugurar la siguiente.

Fuentes