Resumen

  • TCP-AO puede autenticar un reset mientras ambos extremos conservan el estado de la conexión y las claves de tráfico.
  • Tras un reinicio, el reset que no puede verificarse se descarta; el estado antiguo debe desaparecer mediante mecanismos de actividad o recuperación de la aplicación.

El reinicio rompe la simetría

Antes del fallo, los dos extremos conocen la conexión TCP, sus números de secuencia iniciales y las claves derivadas para esa conexión. Un reset que llega dentro de ese contexto puede autenticarse.

Un router reiniciado puede conservar la configuración de TCP-AO y, aun así, haber perdido la conexión concreta. RFC 5925 señala que, si se desconoce el par de números de secuencia iniciales, como ocurre al enviar un reset después de un reinicio, este debe enviarse sin autenticación. El otro extremo, si exige TCP-AO, no puede validar el segmento y lo descarta.

Así aparecen dos versiones de la situación: el extremo reiniciado afirma que la conexión ya no existe, mientras el superviviente todavía conserva una conexión para la que no ha recibido una prueba creíble.

Por qué no vale una excepción de confianza

Aceptar el reset no autenticado permitiría a un atacante falsificar el mismo mensaje y cerrar una sesión protegida. El receptor no puede inferir la intención del emisor a partir del paquete; solo puede comprobar si encaja en el contexto de seguridad conservado.

La consecuencia es una limpieza más lenta. El extremo superviviente puede retener estado obsoleto hasta que un mecanismo de actividad determine que la conexión no progresa. RFC 5925 recomienda keepalives de TCP o de la aplicación y exige que las implementaciones detecten y eliminen el estado excesivo de conexiones para proteger la memoria.

Fuentes