Resumen

  • GTSM comprueba la proximidad mediante el TTL de IPv4 o el Hop Limit de IPv6; no autentica al emisor ni sustituye la protección criptográfica de la sesión TCP de BGP.
  • El resultado depende del radio de saltos, el filtrado de entrada, la confianza en el vecino directo y el comportamiento de los túneles.
  • La garantía del par requiere un recibo unido: valor de salto, interfaz y túnel, vecino aprobado, claves TCP-AO, sesión y dueño de cada control.

El cross-connect acaba de trasladarse. Ambos routers BGP siguen enviando con TTL 255 y cada paquete recibido supera la comprobación GTSM. El registro del cambio concluye que el par remoto quedó autenticado.

La conclusión es más amplia que la evidencia. La comprobación muestra que el paquete llegó dentro del límite de saltos permitido. Por sí sola no revela qué sistema autorizado lo creó, si un equipo en el mismo enlace podía falsificarlo, si un túnel alteró la distancia aparente ni si el segmento llevaba un autenticador criptográfico válido. La sesión puede estar activa y GTSM puede funcionar correctamente mientras la palabra «autenticado» sigue sin estar demostrada.

RFC 4271 sitúa BGP sobre TCP. Dos sistemas forman una conexión TCP y luego intercambian mensajes BGP. Esto separa cuatro preguntas: si el paquete IP llegó desde una distancia plausible; si el segmento TCP pertenece a la conexión protegida; si el vecino configurado aceptó la sesión; y si la organización tras ese vecino conserva autoridad para intercambiar rutas. Un único indicador verde no puede contestarlas todas.

RFC 5082 define GTSM a partir de una asimetría sencilla. Un par de protocolo conectado directamente envía con el valor máximo, 255. Cada router que reenvía un paquete reduce ese valor, por lo que el receptor que espera 255 puede descartar tráfico que probablemente se originó más lejos. Si la clasificación se hace cerca del hardware de línea, también impide que paquetes falsificados consuman recursos escasos del plano de control.

Es una protección útil: reduce la superficie de ataque y proporciona una prueba topológica barata antes del procesamiento costoso. Por eso RFC 7454 recomienda seguridad TTL en peerings BGP conectados directamente.

El límite es igual de importante. RFC 5082 afirma que GTSM no sustituye a la autenticación y que no protege contra suplantación o repetición desde el propio enlace. Un dispositivo vecino comprometido está lo bastante cerca. También lo está un atacante en el segmento de confianza. Un paquete originado o desencapsulado en un extremo de túnel aceptado puede parecer cercano. Superar la prueba demuestra proximidad configurada, no autoría.

El uso multihop amplía la diferencia. GTSM puede aceptar un radio de TTL configurado para loopbacks o sesiones de varios saltos, pero cada salto aceptado aumenta los lugares desde los que puede llegar un paquete plausible. Un cambio de topología puede modificar el significado sin alterar el umbral numérico.

Los túneles añaden otra ambigüedad. RFC 5082 analiza casos IP y MPLS porque el TTL interno que ve el par depende de la encapsulación, del modo de propagación y de si el desencapsulador es también el extremo del protocolo. La integridad y el punto de terminación del túnel forman parte de la evidencia. Una alarma GTSM tras una migración puede revelar un nuevo camino; un resultado positivo no certifica el túnel.

La autenticación criptográfica de segmentos responde a otra pregunta. RFC 5925 define TCP-AO para conexiones largas como BGP. Calcula un código de autenticación sobre material ligado a la conexión usando tuplas de claves maestras y claves de tráfico por conexión. Las extensiones de números de secuencia evitan repeticiones cuando se agota el espacio ordinario de secuencia TCP. Un resultado TCP-AO válido respalda que el segmento lo produjo quien posee material de clave aceptado para esa conexión.

TCP-AO tampoco elimina la gobernanza. Los operadores deben asociar cada clave con una relación de peering, instalarla en ambos extremos, fijar su periodo de validez, coordinar la rotación y retirar material obsoleto. Un MAC válido con una clave que debió retirarse puede ser coherente criptográficamente y estar desautorizado operacionalmente.

Los controles son más sólidos juntos porque fallan de formas distintas. GTSM filtra tráfico implausiblemente lejano, los filtros de entrada reducen direcciones falsas, TCP-AO autentica segmentos y la configuración del vecino liga la sesión a la relación aprobada. Ninguno debe apropiarse del nombre de otro.

Fuentes