Resumen

  • RFC 2385 vinculó cada segmento protegido a un secreto compartido y ordenó descartar sin respuesta cualquier verificación fallida.
  • El formato ahorró espacio TCP omitiendo el algoritmo y la identidad de clave; un resumen válido probaba el segmento bajo una configuración local, no la autoridad de las rutas transportadas.

El ataque estaba en la conexión

BGP confiaba en TCP para mantener un flujo ordenado. Esa dependencia permitía que un segmento RST forjado cerrara la conexión si el atacante acertaba los datos suficientes. El daño podía amplificarse cuando el proceso de routing retiraba rutas o intentaba reconstruir la sesión.

La opción 19 añadió 16 octetos de MD5, además de tipo y longitud. El cálculo incluía el pseud encabezado IPv4, la cabecera TCP sin opciones y con checksum cero, los datos y una contraseña previamente conocida por ambos TCP. Si el valor no coincidía, el receptor eliminaba el segmento y no respondía.

La coincidencia era una evidencia útil y acotada. No identificaba jurídicamente al operador, no autorizaba a un AS a originar un prefijo y no demostraba que una UPDATE hubiera superado la política, llegado a la FIB o entregado tráfico. Autenticaba bytes dentro de una sesión configurada.

Una política invisible al cable

RFC 2385 no negociaba su empleo. Cada sitio decidía si lo exigía. La ausencia de la opción en un SYN/ACK no provocaba degradación: el lado protegido ignoraba la respuesta y la conexión no nacía. Así, un par remoto no podía desactivar unilateralmente la protección.

La otra cara era operativa. El secreto, su versión y el instante de activación vivían en las configuraciones. El segmento no llevaba KeyID. El RFC permitía cambiar la contraseña en una conexión si ambos extremos se coordinaban, pero advertía que las retransmisiones podían verificarse con la época equivocada. Un fallo silencioso no explicaba si faltaba la opción, si la contraseña era distinta o si había un ataque.

Por eso deben separarse los recibos: emisión, presencia de la opción, selección de secreto, validación, aceptación TCP, continuidad BGP, aceptación de UPDATE, instalación y entrega. El primer éxito no contiene a los demás.

Cuarenta octetos y un selector ausente

TCP deja 40 octetos para todas sus opciones. La opción MD5 consumía 18. En el SYN ejemplificado por el documento, MSS, escalado de ventana, timestamp, MD5 y relleno ocupaban todo el presupuesto.

MD5 ya generaba dudas, pero el formato desplegado carecía de tipo de algoritmo. Añadir un octeto habría llevado la opción a 19 y probablemente a 20 por alineación. El ahorro era comprensible en un encabezado tan estrecho. También convirtió el algoritmo en una constante no expresada en el propio intercambio.

Sin selector, una alternativa no podía usar el mismo contrato. Hacía falta otro número de opción y otra migración. La Errata 4432 corrigió “palabras de 32 octetos” por “32 bits”. RFC 6691 corrigió la indicación sobre MSS: el emisor resta las opciones al tamaño de datos. Ninguno de esos ajustes añadió agilidad criptográfica.

El secreto tenía vida aunque el formato no la mostrara

RFC 3562 recomendó claves de 12 a 24 octetos, no compartirlas entre múltiples peerings y cambiarlas al menos cada 90 días. La seguridad dependía de decisiones que Kind 19 no podía atestiguar. Una clave reutilizada aumentaba el impacto de una filtración; una rotación no simultánea podía cortar BGP.

TCP-AO, definido en RFC 5925, sustituyó el mecanismo con algoritmos extensibles, KeyID, una indicación de la siguiente clave, derivación por conexión y protección de replay. Aun así, no distribuyó secretos ni convirtió la autenticación del transporte en autorización de routing.

La lista BTW ya conserva un artículo distinto sobre la época de clave de TCP-AO. Aquí la cuestión es anterior: el ahorro de estado hizo posible una defensa inmediata, pero obligó a construir una nueva superficie protocolaria para reemplazarla.

La lección no es «MD5 era malo»

Reducir esta historia a la debilidad posterior de MD5 perdería el diseño. RFC 2385 describió desde el principio un mecanismo débil pero practicado. Su logro fue impedir que cualquier segmento plausible modificara una conexión protegida. Su límite fue no ofrecer una identidad portable para el algoritmo y la clave.

Una especificación común mínima no debe crecer hasta gobernarlo todo. Tampoco puede ocultar la información necesaria para que implementaciones independientes sepan qué validan y cómo migrar. El segmento autenticado era una verdad de la capa de transporte. La sesión, la ruta y el resultado seguían siendo verdades distintas.

Fuentes