Resumen

  • RFC 2356 separó la dirección de auxilio cambiante de un nodo Mobile IP de su identidad SKIP estable, seleccionada mediante NSID y MKID.
  • Que el primer paquete autenticado pudiera activar el reenvío no eliminaba las claves previamente confiadas, la política del cortafuegos, el estado de enlace ni la incertidumbre sobre el resultado final.

La movilidad rompía una equivalencia cómoda: dirección igual a identidad. En Mobile IP, la dirección de origen visible podía cambiar precisamente porque el nodo estaba cumpliendo el protocolo. Para el encaminamiento era una solución; para un cortafuegos basado en direcciones era una anomalía.

RFC 2002 había definido una dirección local permanente y una care-of address que reflejaba el punto de conexión del momento. El agente local interceptaba el tráfico destinado a la primera y lo reenviaba hacia la segunda. Cuando la dirección local pertenecía a una red privada, el tráfico exterior no podía limitarse a emitirla en Internet. Podía no existir una ruta pública y el cortafuegos podía rechazarla. Hacían falta un destino exterior, encapsulación y una manera de reconocer al mismo nodo después de cada cambio.

La propuesta de G. Montenegro y V. Gupta, publicada como Informational en junio de 1998, resolvía ese último problema con SKIP. No era un estándar de Internet ni cubría toda combinación de redes privadas. Su escenario era un nodo de una organización, protegido en casa por un cortafuegos, que se conectaba directamente al Internet público mediante una dirección de auxilio propia. Si el nodo estaba dentro de otra red privada, el texto no ofrecía la misma solución.

SKIP aportaba una ventaja temporal. Al ser un sistema de claves sin sesión, podía incluir material de autenticación en el paquete. El cortafuegos no tenía que completar una negociación separada antes de reenviar el primer paquete válido. La frase admite una mala lectura: no había ida y vuelta previa en el flujo, pero sí debía existir confianza previa. Las partes necesitaban componentes públicos Diffie-Hellman auténticos, cargados por configuración o recuperados de un directorio de certificados.

El encabezado SKIP permitía sustituir la dirección fuente como índice de la asociación de seguridad. Un NSID decía qué espacio de nombres se usaba; un MKID elegía la identidad dentro de él. Con NSID 1, el MKID podía ser la dirección local permanente aunque la cabecera exterior mostrara una care-of address nueva. NSID 8 podía derivar el identificador de un componente público Diffie-Hellman sin firma. Aun así, si no intervenía una autoridad certificadora, los nombres de los principales tenían que llegar por un medio seguro.

Sobre esa base aparecía una entrada de control de acceso nomadic. No concedía confianza a cualquier origen. Permitía evaluar paquetes procedentes de direcciones variables cuando declaraban el identificador criptográfico previsto. AH debía autenticar el paquete —o ESP debía ofrecer una protección equivalente— y después la política decidía si esa identidad podía acceder al recurso solicitado. Identificación y autorización seguían siendo dos actos.

El nodo iniciaba la comunicación y el cortafuegos aprendía la dirección de auxilio observada. Podía entonces registrar una asociación dinámica entre la clave, la dirección local y esa dirección temporal, y usarla para el tráfico de vuelta. El registro no era una historia completa de movilidad. La solicitud de registro más reciente reemplazaba la anterior. La forma simple no admitía varias asociaciones simultáneas, salvo que el cortafuegos analizara Mobile IP con mayor profundidad.

Este estado obligaba a mirar la ruta real. El cortafuegos que había visto la solicitud esperaba ver también la respuesta. En un perímetro con varios equipos, una Registration Reply asimétrica podía salir por otro punto y no encontrar la asociación. Un cortafuegos consciente de Mobile IP podía extraer identidad de la respuesta y funcionar con menos estado, pero asumía una responsabilidad protocolaria mayor.

Había otra decisión antes del túnel: ¿estaba el nodo dentro o fuera? Las listas de rangos ofrecían una aproximación. RFC 2356 reconocía, sin embargo, que la clasificación podía ser difícil y que la entrada directa de la persona usuaria resultaba útil. El usuario podía conocer el contexto aunque la numeración fuera ambigua. Esa señal era una declaración operativa; no convertía una dirección en prueba de ubicación física.

El agente local necesitaba su propia visión del recorrido. La Traversal Extension transportaba en las solicitudes y respuestas de registro las direcciones de los puntos que debían atravesarse en cada sentido. También permitía cadenas de varios cortafuegos. Algunos valores recibidos desde el otro extremo funcionaban como pistas. Eran instrucciones de encaminamiento y encapsulación, no certificados de que el paso se hubiera completado.

La parte más política del RFC comparaba cuatro disposiciones de canal. Cifrar solo el tramo público protegía el enlace exterior. El cifrado extremo a extremo relegaba al cortafuegos al reenvío y dejaba la autenticación en el agente local. Una autenticación intermedia permitía al cortafuegos verificar el flujo cifrado, pero exigía entregarle un secreto Diffie-Hellman de largo plazo. Dos canales cifrados separados terminaban en el cortafuegos y le permitían inspeccionar el contenido. Otro túnel podía recuperar confidencialidad respecto de él.

Por eso “cifrado” no describía quién tenía poder. El control dependía de dónde terminaban las asociaciones y de quién poseía los secretos. La encapsulación RFC 2003 resolvía una necesidad de transporte entre espacios de direcciones; AH resolvía autenticación; ESP, confidencialidad y eventualmente autenticación. Un sistema podía cumplir una de esas funciones y fallar en las demás.

En sentido inverso, el agente local capturaba el paquete para la dirección permanente, lo encapsulaba hacia la dirección temporal y lo enviaba por el cortafuegos. Este consultaba la asociación dinámica y protegía el tramo público. El hecho de que la respuesta cruzara la frontera todavía no demostraba que el corresponsal hubiera recibido o procesado nada. Registro, reenvío y resultado de aplicación eran recibos distintos.

La movilidad extendía además el perímetro. El portátil podía necesitar DHCP, facturación u otros intercambios públicos sin cifrar mientras mantenía su acceso privado. Debía filtrar por sí mismo. Si era comprometido, su identidad válida podía llevar al atacante más lejos que una dirección desconocida. La clave estable resolvía la continuidad, pero aumentaba el costo de atribuirle demasiada autoridad.

La contribución histórica del RFC fue, por tanto, una contabilidad de diferencias. Dirección observada no era identidad; identidad no era autenticación; autenticación no era permiso; permiso no era enlace vigente; enlace no era registro; registro no era entrega. El diseño funcionaba cuando cada transición dejaba evidencia propia.