Resumen

  • KeyID identifica el Master Key Tuple que autenticó el segmento enviado. RNextKeyID expresa qué MKT de recepción prefiere el emisor; no transporta el secreto, no acusa recibo y no demuestra que el par cambió su clave saliente.
  • El estado es direccional: cada extremo conserva una clave saliente actual y otra entrante preferida. Una vista de «clave activa» única elimina cuatro hechos independientes y convierte una etiqueta local en una certeza falsa.
  • Retirar la clave anterior requiere observar tráfico válido bajo la nueva época en ambos sentidos, estabilidad BGP, una reconexión controlada, dependencia antigua nula y un rollback completo.

La causa del incidente no es necesariamente una mala custodia. Los dos equipos pueden haber recibido exactamente los mismos bytes por un canal seguro. El fallo puede estar en el espacio de nombres. A instala el nuevo MKT con SendID y RecvID 42. B asigna SendID y RecvID 43 conforme a su convención local. En las reuniones ambos lo llaman «la clave 42». TCP-AO no trabaja con el nombre del ticket; trabaja con la dirección y el identificador efectivos.

A configura el nuevo MKT como preferido para recibir. Sus segmentos siguen autenticados con KeyID=17, pero anuncian RNextKeyID=42. B valida esos segmentos con la clave antigua y busca localmente un MKT saliente, para esa pareja de sockets, cuyo SendID sea 42. Si el objeto no existe o no está listo, RFC 5925 no exige que ocurra nada. El intento fallido corresponde a B→A: B sigue enviando con 17. Si B anuncia después RNextKeyID=43, A tampoco puede cambiar A→B sin un MKT saliente listo con SendID 43.

Ese silencio es seguro. Impide que un número remoto obligue al router a usar una clave no provisionada. Se vuelve peligroso solo cuando la observabilidad traduce «no hubo error» por «la rotación terminó».

KeyID y RNextKeyID no son sinónimos

TCP-AO ocupa la opción TCP Kind 29. Incluye longitud, KeyID, RNextKeyID y un código de autenticación. Su formato pequeño refleja una función acotada: coordinar el uso de material que ya está en los extremos.

KeyID explica el segmento presente. El emisor inserta el SendID de su MKT saliente actual. El receptor combina la pareja de direcciones y puertos con ese byte para buscar un MKT cuyo RecvID corresponda y verificar el MAC.

RNextKeyID prepara la dirección contraria. El emisor publica el RecvID del MKT que desea emplear para autenticar futuros segmentos entrantes. El receptor de ese anuncio puede cambiar su MKT saliente si encuentra uno compatible con el número solicitado.

Los bytes no son huellas ni versiones. Carecen de propiedades criptográficas, valores reservados y orden monotónico. Pueden diferir por dirección. La igualdad numérica no demuestra igualdad del secreto, algoritmo, longitud del MAC, vigencia o ámbito de sockets.

La lectura exacta de RNextKeyID es condicional: «estoy listo para recibir bajo este RecvID si tú ya dispones del MKT saliente correspondiente». No significa «te he entregado la próxima clave» ni «he confirmado tu instalación».

El MKT es el objeto operativo real

Un Master Key Tuple reúne el secreto con la conexión a la que puede aplicarse. RFC 5925 incluye un identificador TCP formado por direcciones y puertos locales y remotos, con posibles rangos o comodines según la implementación. Añade SendID, RecvID, algoritmo de derivación, algoritmo MAC y una regla sobre la inclusión de otras opciones TCP. La gestión puede aportar fechas de validez.

Un segmento entrante debe coincidir exactamente con un MKT mediante la pareja de sockets y KeyID. El mismo secreto en otro VRF, otra familia, otro par o bajo otro RecvID no es la misma capacidad efectiva. Tampoco basta con compartir bytes si un extremo incluye opciones TCP en el MAC y el otro no, o si difieren el algoritmo y la longitud.

Por eso el inventario debe registrar direcciones, puertos, instancia, SendID, RecvID, algoritmo, longitud, política de opciones, vigencia, rol current/rnext y época TCP. «Clave 42 presente» es una descripción demasiado pobre para autorizar una retirada.

Las claves de tráfico pertenecen a la conexión

El secreto maestro no firma directamente cada segmento. TCP-AO deriva claves de tráfico usando el MKT, las direcciones, los puertos y, en una conexión establecida, los números iniciales de secuencia de ambos sentidos. Distingue envío y recepción, además de SYN y tráfico posterior.

Así, un mismo MKT produce claves distintas para pares, direcciones y épocas diferentes. Reiniciar la conexión cambia el contexto aunque reaparezcan las mismas direcciones y puertos. Una prueba sobre la sesión antigua no demuestra que un nuevo SYN elegirá y derivará el mismo estado útil.

Las Sequence Number Extensions mantienen información adicional cuando el espacio TCP de 32 bits da la vuelta y refuerzan la protección frente a replay en conexiones largas. Cada dirección sostiene su propio SNE desde el establecimiento. Un MAC fallido debe investigarse con el contexto de esa época, no con una captura aislada.

Esto explica por qué comparar una huella del secreto es necesario pero insuficiente. La divergencia puede vivir en el identificador, el ámbito, la dirección, la política de opciones, el algoritmo, la longitud o la conexión.

Una sesión contiene dos rotaciones acopladas

Cada extremo mantiene como máximo un current_key para transmitir y un rnext_key preferido para recibir. Entre A y B existen cuatro punteros relevantes. La rotación no es un botón simétrico.

Primero se instala el nuevo MKT en ambos extremos mientras el antiguo continúa válido. La verificación debe leer el estado efectivo asociado al socket; guardar configuración no prueba que el proceso en ejecución lo haya aplicado.

Después A anuncia su preferencia de recepción. B resuelve el RNextKeyID contra su base local y, si encuentra el MKT, cambia su current_key. El primer segmento de B con el nuevo KeyID, correctamente validado por A, prueba solo B hacia A.

Luego B anuncia su propia preferencia y A hace la misma transición de forma independiente. Durante un intervalo, un sentido puede utilizar la nueva época y el otro la anterior. No es necesariamente un error; es el estado que debe ver la herramienta.

Finalmente se mantiene un solapamiento delimitado y se retira el MKT viejo cuando no queda dependencia. Una interfaz que dibuja una sola clave activa oculta las transiciones, y no puede ser la autoridad para borrar nada.

La señal común conserva la decisión local

Cuando llega un RNextKeyID distinto del KeyID saliente actual, el receptor busca un MKT preparado. Si no lo hay, no cambia. La solicitud remota no crea una clave local ni amplía su vigencia.

La especificación común define el lenguaje mínimo; cada sistema decide con su propio estado verificable. La adopción ocurre cuando el MKT existe y el tráfico cambia, no cuando una declaración cruza el enlace.

La prueba debe seguir la consecuencia: ¿cambió el KeyID saliente del par? ¿Aumentaron los MAC válidos bajo el nuevo MKT? ¿Aparecieron eventos de key-not-found, RNext request o MAC incorrecto? Una sesión Established que sigue usando 17 es continuidad histórica, no evidencia sobre 42.

TCP-AO no administra la distribución

RFC 5925 presupone un protocolo externo o un proceso manual para provisionar las claves. No define la bóveda, el API, el responsable, el canal cifrado ni la aprobación. También deja fuera la coordinación de la eliminación.

RFC 6518 advierte que las claves deben tener vida limitada, pero los cambios manuales excesivos pueden aumentar errores y exposición. El transporte debe permitir la rotación sin derribar adyacencias; un sistema de gestión debe hacer viable la frescura. RFC 7211 recomienda instalar primero capacidad de recepción, validar la coherencia de la tabla, gestionar expiraciones y notificar fallos con anticipación.

El registro de cambio debe unir ambos planos: origen y custodia del secreto, canal de entrega, identificadores locales, inicio de validez para recibir y enviar, fin del MKT anterior, responsables y procedimiento de reversión.

El control operativo consiste en poder inspeccionar estos hechos, protegerlos y restaurarlos. No depende de proclamar dominio sobre el estándar, sino de conservar la capacidad técnica y probatoria sobre su extremo.

La retirada concentra el riesgo irreversible

Instalar agrega una opción. Borrar elimina el camino de regreso. Mientras el MKT antiguo permanece, puede cubrir una dirección retrasada o un rollback. Después de su eliminación, cualquier discrepancia nueva afecta a TCP y, por extensión, a BGP.

Mantenerlo para siempre tampoco es aceptable. Un secreto comprometido conserva utilidad mientras alguien lo admita; un solapamiento sin límite permite regresiones invisibles. La solución es una retirada respaldada por pruebas y por un plazo explícito.

El plazo debe cubrir propagación, retransmisión, demora de métricas, reconexión y rollback. En cada dirección hay que fechar el último KeyID antiguo y el primero nuevo, observar MAC válidos y ausencia de fallos, mantener BGP estable y comparar rutas. Una reconexión controlada es imprescindible porque la selección durante SYN puede diferir del estado heredado en un socket largo.

La implementación Linux ofrece contadores buenos, malos, key-not-found y AO-required, inspección de MKTs y eventos de traza. También documenta una eliminación forzada que puede nombrar otra clave current/rnext de forma atómica, con una advertencia: puede romper la conexión si el par todavía solicita la antigua. Es una herramienta de recuperación, no una excepción a la prueba bilateral.

Un rollback completo restaura ámbito, IDs, algoritmos, longitud, política de opciones, vigencias y procedencia del secreto. El número aislado no reconstruye una época.

Autenticidad del transporte no es autoridad de ruta

Un MAC correcto demuestra que el segmento encaja en el contexto criptográfico esperado. No demuestra que el prefijo pertenezca al AS, que el AS_PATH sea legítimo o que el router distante esté sano.

RFC 4272 distingue las inyecciones de terceros de la información falsa enviada por un par auténtico. RFC 7454 conserva controles separados: TCP-AO, GTSM, filtros del plano de control, filtros de prefijos, max-prefix y política de AS_PATH.

También deben separarse en telemetría. Un mal MAC se descarta antes de BGP. Una ruta no autorizada pero bien autenticada llega a la política de importación y allí falla. Un max-prefix puede cerrar intencionadamente un transporte válido. Una luz verde para TCP-AO nunca valida toda la fila.

El canario debe observar cuatro bordes

La prueba comienza identificando instancia, direcciones, puertos, par, época TCP y línea base de rutas. Se leen todos los MKT coincidentes en ambos routers con SendID, RecvID, algoritmo, longitud, política, vigencia y rol. El secreto se compara mediante una huella protegida o una prueba controlada, nunca copiándolo al ticket.

Primero se demuestra recepción preparada en A y B. A continuación A anuncia su preferencia; se captura el primer nuevo KeyID emitido por B y el primer MAC aceptado por A. Se repite en la dirección inversa, sin deducirla de la primera.

Con ambas direcciones nuevas, se envían KEEPALIVE y una operación BGP acotada. Se comparan Adj-RIB, prefijos seleccionados, retransmisiones y contadores. Tras el solapamiento, se prueba reconexión, se confirma uso antiguo cero y se elimina el MKT viejo en un par canario. Toda la evidencia queda unida por la época.

TCP-AO es fuerte porque su autoridad es estrecha. Coordina etiquetas locales sin fingir que el cable entrega secretos. La nueva época se vuelve real solo cuando los dos extremos pueden resolverla, ambos sentidos la usan y verifican, BGP sobrevive, la dependencia previa llega a cero y el retorno sigue disponible. Antes de eso, 42 es una propuesta.