Resumen

  • RFC 1326 estudió la encapsulación mutua: X viajaba dentro de Y en una red, mientras Y viajaba dentro de X en otra. Una ruta circular podía añadir una capa nueva sin retirar las anteriores.
  • Si cada cabecera exterior aportaba un contador de saltos nuevo, el límite interior dejaba de medir el recorrido total. Al alcanzar la MTU, un paquete originaba fragmentos que repetían el ciclo.
  • Conservar contadores, inspeccionar capas o prohibir ciertos anidamientos eran defensas parciales. La composición necesitaba un presupuesto que ninguna frontera pudiera reiniciar.

La población apareció después del umbral

Antes de la fragmentación, el fallo parecía una simple anomalía de tamaño. Un paquete ganaba una cabecera en cada vuelta. El aumento era regular y podía confundirse con el coste normal de varios túneles. La MTU introducía una discontinuidad: cuando el objeto ya no cabía, el sistema no detenía necesariamente la ruta; lo convertía en varios objetos más pequeños.

Esos fragmentos no heredaban una salida correcta por el hecho de ser más pequeños. Seguían dentro de la misma relación de rutas y encapsuladores. Cada uno podía regresar, ganar capas y alcanzar otra vez el límite de tamaño. Por eso RFC 1326 habló de una explosión exponencial del número de paquetes en bucle. Era una afirmación sobre la recurrencia, no el relato de una explosión física ni la atribución de un ataque.

La distinción importa porque el documento no registró un incidente concreto. Construyó un escenario técnico. Su valor no depende de saber cuántos paquetes circularon en una red histórica; depende de mostrar cómo una transformación lineal por vuelta se convierte en multiplicación cuando el tamaño activa la fragmentación.

El túnel útil y el túnel recursivo compartían la misma operación

Encapsular resolvía un problema real de interoperabilidad. Si una red troncal entendía Y y el paquete original pertenecía a X, un router de entrada podía añadir Y, dirigir la envoltura a una salida y recuperar allí X. El núcleo intermedio no necesitaba comprender el protocolo transportado.

RFC 1326 examinó el caso en que la relación existía en ambas direcciones. Había lugares con X sobre Y y otros con Y sobre X. El texto mencionó IP sobre AppleTalk y AppleTalk sobre IP, y situó el problema en un entorno de muchos protocolos estándar y propietarios que debían encontrarse.

Una ruta transitoria equivocada bastaba para unir los dos mecanismos. X se convertía en Y<X>. Otra frontera, que necesitaba atravesar X, añadía esa capa sin quitar Y y obtenía X<Y<X>>. Cuando el paquete regresaba al primer tipo de entrada, aparecía Y<X<Y<X>>>.

Cada router podía justificar su acto mirando solo el siguiente segmento. Esa justificación no contenía una prueba de progreso. Añadir la cabecera adecuada demostraba compatibilidad con la red inmediata, no que el paquete se acercara al destino, fuera a encontrar el desencapsulador correcto o consumiera una vida común.

La cabecera visible no contaba la historia completa

Los bucles ordinarios disponían de un límite: un contador de saltos se reducía hasta provocar el descarte. El caso peligroso de RFC 1326 suponía que la encapsulación sucesiva no conservaba el contador de la cabecera anterior. El valor antiguo podía seguir intacto, pero quedaba oculto dentro del nuevo paquete. La red exterior obedecía otro valor recién creado.

Así, un contador exterior positivo aportaba evidencia estrecha: indicaba la vida restante de la envoltura actual. No revelaba cuántos túneles había atravesado el objeto interior ni cuántas veces había regresado a una entrada. Repetir contadores localmente válidos no producía un contador global.

Trasladar el valor entre protocolos tampoco era trivial. El RFC señaló que X.25 y SMDS no tenían contador de saltos, y que las escalas podían diferir. AppleTalk llegaba a 16 saltos; IP podía representar hasta 256. Reducir siempre al rango menor podía frenar el circuito, pero también cortar una ruta IP legítima de más de 16 saltos. La conversión incorporaba una decisión sobre qué camino válido se estaba dispuesto a perder.

Inspeccionar más capas no eliminaba lo desconocido

Otra propuesta pedía al router mirar dentro del paquete. Si antes de envolver Y<X> en X encontraba ya una capa X, podía reconocer una posible recurrencia y descartar. La idea funcionaba solo hasta el límite del conocimiento del equipo.

Un protocolo de red podía estar transportado dentro de uno de transporte. Una cabecera desconocida impedía seguir descendiendo. El cifrado ocultaba la estructura. Además, una ruta anidada legítima podía requerir dos cabeceras Y. La repetición visual no era equivalente a una prueba de bucle.

El memo combinó finalmente varias precauciones: desalentar la encapsulación mutua, prohibir la encapsulación mutua anidada, conservar contadores e inspeccionar cuando fuese apropiado. Esa lista era honesta sobre la ausencia de una solución universal. RFC 1326 era Informational y declaró que no discutía cuestiones de seguridad. Convertir hoy su escenario en un ataque documentado añadiría un hecho que la fuente no contiene.

Cuando el tráfico de error expulsaba a la corrección

La consecuencia operacional más grave no era el tamaño de un paquete aislado. La población en bucle podía saturar los enlaces. Si entonces se descartaban actualizaciones de enrutamiento o mensajes de gestión, la red perdía precisamente el intercambio que podía romper el circuito por sí sola. Un error del plano de datos se convertía en un obstáculo para su plano de control.

Esto obliga a separar varias evidencias. La caída de un mensaje de routing no demuestra por sí sola la causa. La presencia de fragmentos no demuestra recursión. Una cabecera añadida no demuestra que se perdió la salida. Solo la relación temporal entre reentrada, profundidad, tamaño, fragmentación, pérdida de control y cambio de ruta permite sostener la cadena.

El RFC indicó que, una vez roto el bucle, los paquetes se vaciarían con rapidez. No dio una duración ni una observación de servicio. La ruptura de la ruta, la limpieza del tráfico y la recuperación percibida por el usuario son estados distintos.

Dos vidas para dos clases de movimiento

RFC 2003 definió después la encapsulación de IP dentro de IP. Cuando el túnel forma parte del forwarding, se decrementa una vez el TTL interior; un datagrama con TTL cero no puede encapsularse. También se rechazan ciertos casos donde la fuente coincide con el encapsulador o con el destino del túnel. Son límites verificables para un ámbito definido.

RFC 2473 introdujo en IPv6 una separación más explícita. El hop limit original mide el avance del paquete original. Tunnel Encapsulation Limit mide cuántas capas anidadas adicionales puede adquirir. Si vale cero, el paquete no entra en otro túnel antes de salir del actual.

No son dos nombres para el mismo contador. Uno disminuye con el forwarding del objeto original; el otro disminuye con cada encapsulación anidada. Al asignar un presupuesto a la operación peligrosa, la arquitectura dejó de esperar que la vida de una cabecera representara una propiedad que pertenecía a toda la pila.

RFC 2473 conservó además la advertencia de multiplicación: fragmentar un paquete de túnel ya fragmentado duplica los fragmentos. La respuesta posterior no negó el mecanismo de 1992. Lo convirtió en una condición que podía observarse y limitarse con mayor precisión.

Fuentes

Estas fuentes establecen el estado de los documentos, los mecanismos descritos y respuestas protocolarias posteriores. No prueban un incidente de 1992, un túnel actual, una intrusión, un defecto de proveedor, una tasa de despliegue, daños ni una reparación exitosa.