Resumen

  • GTSM obliga a originar el tráfico protegido con TTL o Hop Limit 255 y permite al receptor rechazar valores incompatibles con la distancia aprobada.
  • Superar el umbral sólo demuestra proximidad topológica acotada. No autentica al vecino, no protege la integridad del segmento y no autoriza el contenido BGP.
  • La verificación debe recorrer ambos sentidos y todas las capas: 255 en origen, valor de llegada, umbral, primer contador de descarte, TCP, BGP y política de rutas.

Cambiar hops 2 por hops 3 restablecería el servicio. También ampliaría en un salto el conjunto de posiciones desde las que un paquete falsificado puede parecer cercano. Esa doble consecuencia explica por qué el número no pertenece únicamente al equipo de disponibilidad: es, a la vez, tolerancia topológica y presupuesto de confianza.

La aritmética útil y su límite

TTL en IPv4 y Hop Limit en IPv6 comparten una propiedad decisiva para GTSM: un router que reenvía reduce el valor. Como el campo tiene ocho bits, 255 es el máximo. El par protegido transmite desde ese máximo y el receptor compara el residuo con la distancia que espera.

En una conexión directa, el valor esperado es 255. En una sesión multihop, cada salto enrutado consume una unidad. La guía Cisco citada formula la aceptación como un valor igual o superior a 255 menos el conteo configurado. FRRouting ofrece la orden ttl-security hops. No conviene trasladar a ciegas la semántica exacta de un fabricante a otro: se deriva el mínimo de la plataforma concreta y se comprueba capturando paquetes.

El resultado es evidencia negativa. Si un paquete llega demasiado bajo, no pudo seguir el trayecto cercano autorizado bajo las hipótesis normales. Si llega alto, sólo sabemos que no gastó más saltos de los admitidos. No sabemos quién lo creó. Un atacante remoto tiene el techo de 255 en su contra; un atacante en el mismo enlace que el vecino legítimo puede presentar exactamente el mismo residuo.

«Trusted» no significa verdadero

RFC 5082 clasifica como Trusted el paquete asociado a una sesión GTSM cuyo valor cae en el rango esperado. Dangerous es el que corresponde a esa sesión pero queda fuera. Unknown es aquel sobre el que GTSM no puede emitir juicio porque no lo asocia a una sesión registrada.

Los nombres son operativos, no epistemológicos. Un UPDATE malicioso enviado por un par comprometido puede ser Trusted para GTSM. Un segmento legítimo desviado por un camino más largo puede ser Dangerous. La clasificación decide si la distancia merece pasar a la siguiente prueba; no certifica el mensaje.

El mecanismo fue diseñado también para proteger recursos escasos del plano de control. Por eso importa dónde se hace la clasificación. Un paquete descartado por el proceso BGP ya pudo atravesar la tarjeta, la cola de control, el kernel y parte de TCP. El beneficio contra agotamiento de CPU es mayor si el descarte ocurre en hardware o cerca del plano de reenvío.

La telemetría debe indicar el primer punto efectivo: contador de hardware, política del plano de control, visibilidad en kernel, socket TCP, estado BGP. «Drops GTSM: 1000» sin ubicación no permite afirmar qué recurso se protegió.

No hay negociación que arregle una suposición equivocada

Para protocolos existentes, RFC 5082 presupone configuración manual. Los extremos deben enviar a 255 y admitir la distancia correcta. BGP no intercambia una capacidad genérica que descubra el camino o resuelva diferencias entre configuraciones.

Conviene separar cuatro objetos: diseño aprobado, valor configurado, camino observado y regla aplicada. El diseño puede decir «dos saltos»; ECMP puede ofrecer dos y tres; el CLI puede admitir tres; una ACL anterior puede descartar antes. Sólo la unión de los cuatro describe la sesión real.

Una sesión Established tampoco prueba que GTSM esté activo. Podría funcionar porque ambos lados lo deshabilitaron o porque nunca se ensayó el espacio negativo. La prueba convincente conserva un paquete legítimo dentro del umbral y otro, controlado, justo fuera. El segundo debe desaparecer donde el operador predijo.

El multihop ensancha el círculo

La adyacencia directa presenta el caso más fuerte. El emisor entrega 255 y un router intermedio ya altera el dato. RFC 5082 reserva su afirmación más clara de aplicabilidad para topologías inherentemente limitadas y reconoce que la protección multihop es más difícil de cuantificar.

No significa que el multihop carezca de valor. Un radio de tres saltos sigue excluyendo fuentes más lejanas. Significa que cualquiera dentro de ese radio entra en el conjunto de posibles falsificadores. RFC 7454 expresa esa pérdida de eficacia de forma explícita.

La asimetría agrava la gestión. A puede llegar a B en dos saltos y B volver en tres. El SYN pasa; el SYN-ACK cae. Un hash ECMP puede seleccionar ocasionalmente el camino largo y producir una caída intermitente. IPv4 e IPv6 pueden tener geometrías diferentes aunque compartan el nombre del vecino.

Por eso el inventario se organiza por dirección, familia y época de sesión. Debe incluir valores observados para el trayecto normal, la ventana de mantenimiento y el fallo creíble. El margen se justifica con esos datos; no con un número grande que evita tickets.

Cuando el túnel se convierte en ascensor

Un túnel puede atravesar una red extensa sin reducir el TTL interno. En la salida, el paquete reaparece con una apariencia de cercanía. Otros modos copian o propagan los valores entre cabeceras. MPLS, encapsulación IP y cadenas virtualizadas no entregan una equivalencia universal de «un salto».

La seguridad depende entonces de quién puede inyectar en la entrada, de la integridad del túnel, de la confianza en sus extremos y de la validación de origen al desencapsular. Si cualquiera puede introducir tráfico lejos y hacerlo salir junto al vecino, el túnel transporta también la capacidad de falsificar proximidad.

Hay que registrar valores externo e interno, modelo de TTL, punto de terminación y política de ingreso. Una migración a un mitigador DDoS o a un firewall puede conservar las direcciones y cambiar por completo esta aritmética.

Los fragmentos plantean otra excepción. Los que no son iniciales carecen de la cabecera TCP que permite asociarlos a la sesión. Reensamblarlos antes de decidir consume memoria y CPU. RFC 5082 aconseja evitar fragmentación en estos protocolos; la operación debe confirmar MTU, manejo de ICMP y política específica para fragmentos.

Cercanía, identidad y permiso no se sustituyen

GTSM mide distancia plausible. El filtrado de ingreso valida si la fuente puede aparecer por esa interfaz. TCP-AO protege la autenticidad e integridad de segmentos según una clave. Las protecciones del plano de control limitan clases y tasas. La política BGP decide qué rutas son aceptables.

Cada capa bloquea un caso distinto. El atacante local que satisface GTSM puede fallar la validación de fuente. El atacante en camino puede fallar la autenticación. Un vecino autenticado pero comprometido puede anunciar un prefijo indebido y debe fallar la política de importación. Tráfico Unknown puede requerir policía de control aunque GTSM no lo descarte.

La gobernanza madura no resume todo como «BGP seguro». Conserva columnas, propietarios y pruebas independientes. Topología responde por el umbral; plataforma por el punto de descarte; seguridad por fuentes y claves; routing por estado y rutas.

Una prueba de cambio con desenlace previsto

Antes de mover el camino, medir ambos sentidos. Verificar 255 en salida, distribución de llegada y contador de aplicación. Calcular el valor después de la maniobra, incluido el trayecto de emergencia. Si el mínimo legítimo baja, decidir si se corrige la topología o se aprueba un radio mayor.

En un canario aislado, probar un paquete por encima del umbral, otro exactamente en él y otro una unidad por debajo. Los dos primeros deben alcanzar la siguiente capa; el último debe incrementar el descarte temprano y no aparecer en TCP/BGP. Luego ensayar por separado una fuente falsificada en el enlace, una clave errónea y una ruta no autorizada. El valor de la matriz está en que cada fallo ocurre donde corresponde.

Durante el cambio, coordinar ambos extremos para evitar una protección asimétrica. Después, correlacionar contadores, retransmisiones, estados BGP y rutas. La ausencia de NLRI no demuestra un rechazo TTL; puede venir de ACL, autenticación, NOTIFICATION o política.

El rollback devuelve el camino o los umbrales explícitos, no simplemente «hace que BGP vuelva». Desactivar GTSM de un lado y abrir al máximo del otro ofrece disponibilidad a costa de una regresión invisible.

El TTL 252 del incidente no era una firma falsa. Era una distancia nueva frente a una frontera antigua. GTSM conserva su rigor cuando se respeta ese alcance: admite por proximidad para seguir examinando; jamás concede identidad ni derecho de anunciar.