Resumen

  • RFC 2385 permitía cambiar la clave si ambos extremos sincronizaban la operación, pero no definía negociación ni identificadores para coordinarla.
  • RFC 5925 añadió a TCP-AO un KeyID para el MKT del segmento enviado y un RNextKeyID para anunciar el MKT que el emisor ya puede usar en los futuros segmentos que reciba.

El caso difícil comienza después del establecimiento. Dos equipos mantienen una sesión autenticada y valiosa; luego llega el turno de renovar la clave. Una hora pactada no detiene los paquetes que ya están en tránsito. Si un extremo cambia antes, los segmentos válidos del otro pueden parecer falsos. Derribar y reconstruir la conexión evita la ambigüedad, pero también elimina el estado que se quería conservar.

RFC 2385, publicada en 1998 para proteger sesiones BGP, incorporó a cada segmento un resumen MD5 de 16 bytes calculado con una clave configurada por separado. Admitía un cambio de clave durante la conexión siempre que ambos lados lo sincronizaran. Sin embargo, la opción no llevaba un identificador de clave y el protocolo no negociaba ni anunciaba el cambio siguiente.

TCP-AO, definido por RFC 5925 en 2010, hizo explícita la estructura. Un Master Key Tuple, o MKT, reúne selectores de conexión, identificadores, material secreto, algoritmos y parámetros. A partir del MKT se derivan claves de tráfico para cada conexión y dirección. Los componentes de un MKT ya instanciado permanecen fijos, pero el conjunto de MKT disponibles puede variar y la conexión puede pasar a utilizar otro.

Dos campos de un byte coordinan ese paso. KeyID identifica el MKT que autentica el segmento enviado. RNextKeyID anuncia el MKT de entrada que ese emisor ya puede usar para los futuros segmentos que reciba; el par utiliza esa señal y las reglas de relevo para decidir cuándo cambiar su propio MKT de salida y su KeyID. No son secretos ni nombres universales, sino índices con sentido dentro de la configuración de los dos extremos. Como las claves de tráfico son unidireccionales, el estado de envío y el de recepción avanzan por separado.

El relevo deja así de depender de una simultaneidad perfecta. Un extremo instala el próximo MKT de recepción y anuncia mediante RNextKeyID que está listo para usarlo. El par observa esa señal y decide conforme a las reglas de RFC 5925 cuándo cambiar el KeyID de sus propios envíos; el anuncio no ordena hacerlo en el segmento siguiente. Durante la superposición todavía puede validar segmentos antiguos que seguían en vuelo. La red muestra el avance en lugar de obligar a deducirlo solo por el reloj o por fallos de autenticación.

El límite institucional es deliberado. TCP-AO no negocia la clave maestra ni decide quién puede proporcionarla. Los MKT llegan por configuración estática o por un sistema externo fuera de banda. El protocolo coordina material ya autorizado, pero no crea la autoridad que lo entrega.

Tampoco convierte sobre la marcha una conexión TCP MD5. TCP-AO usa otra opción y no puede coexistir con TCP MD5 en la misma conexión. El mecanismo antiguo carecía de una vía para cambiar el algoritmo de seguridad tras el establecimiento. Migrar exige una nueva conexión; una vez dentro de TCP-AO, los relevos posteriores sí pueden preservar el estado de transporte.

RFC 5926 cierra el problema de interoperabilidad al fijar perfiles obligatorios de MAC y derivación. No impone una clave ni una periodicidad de rotación. TCP-AO protege autenticidad e integridad y ofrece defensa frente a la repetición en conexiones largas y repetidas, pero no cifra los datos de la aplicación.

Fuentes primarias