Resumen

  • RFC 5207 analiza por separado el control HIP y los datos protegidos con ESP; la prueba de la primera fase no se extiende automáticamente a la segunda.
  • Un SPI tiene significado en una sola dirección, y el estado aprendido en un borde no sirve si el retorno usa otro camino o si la política nunca instaló la regla.
  • La salud real requiere unir mensajes de negociación, mapeos y pinholes por dispositivo, tráfico ESP bidireccional, validación de los hosts y resultado de servicio.

El registro mostraba cuatro mensajes y cero bytes útiles

Una plataforma de acceso remoto cuenta I1, R1, I2 y R2 y considera terminada la conexión. Los dos hosts se autenticaron. El primer firewall permitió la negociación iniciada desde dentro. El panel guarda un icono verde.

Los datos protegidos toman después una salida distinta. El SPI de vuelta llega a un segundo borde que no participó en la negociación. No hay regla, el paquete cae y la aplicación agota su tiempo. El icono no mentía sobre los cuatro mensajes; mentía al ampliar su autoridad a toda la sesión.

Es un caso hipotético. RFC 5207 no documenta ese despliegue ni aporta una tasa de fallos contemporánea. Su valor es más fundamental: divide HIP en dos fases y muestra que NAT y firewall necesitan información diferente para cada una.

Publicada en 2008, la RFC es informativa y procede del grupo de investigación HIP del IRTF. Es una descripción de problemas, no un estándar de Internet ni una certificación de productos actuales. Precisamente por eso permite analizar el límite sin fingir que toda red usa la misma solución.

La primera fase puede fallar por ausencia de un campo

El diseño IPv4 original transportaba el intercambio HIP como un tipo de carga IP propio. Un NAT básico podía cambiar direcciones y reenviar. Un NAPT habitual necesitaba, además, distinguir varios hosts internos mediante puertos. El paquete HIP no presentaba esos puertos.

El problema no era una identidad criptográfica incorrecta. Era la ausencia de una coordenada que el intermediario había convertido en requisito operativo. Si el inicio venía desde fuera, faltaba también el estado de traducción que suele crear un paquete saliente.

En IPv6, los datos HIP aparecían en encabezados de extensión. Una política que rechaza extensiones desconocidas podía bloquearlos. Decir host does not support HIP ante ese resultado atribuye al extremo una decisión del camino.

UDP ofrece una coordenada más familiar. Una encapsulación iniciada desde dentro puede crear el mapeo y permitir respuestas. Pero ese éxito responde sólo a la pregunta de control. La aplicación aún necesita que ESP encuentre representación y permiso en ambos sentidos.

El cifrado elimina la visibilidad que el middlebox esperaba

ESP protege los encabezados superiores. El NAT ya no ve puertos de transporte ni datos de aplicación. HIP evita algunos problemas de checksum usando HIT en lugar de direcciones IP dentro de ciertos cálculos, pero eso no crea por sí solo un método de multiplexación.

El SPI queda visible y puede parecer suficiente. RFC 5207 subraya que su significado es unidireccional. El valor usado para enviar no revela el elegido para recibir. Una tabla que contiene SPI observado aún puede desconocer la mitad de la comunicación.

También puede haber colisiones entre hosts detrás del mismo NAT. Un equipo puede reescribir el SPI como reescribe un puerto. Entonces debe conservarse la correspondencia: valor interno, valor externo, sentido, asociación, dispositivo, regla y tiempo. Sin ella, la reparación destruye la procedencia.

La precisión numérica no concede autoridad adicional. El SPI no identifica globalmente al usuario, a la aplicación ni a una sesión bidireccional. Tampoco demuestra que el receptor aceptó integridad, anti-replay o descifrado.

Aprender durante el handshake no instala una verdad global

RFC 5207 describe un NAT arquitecturado o SPINAT que observa la negociación y aprende los SPI acordados. Es una mejora concreta: el control puede exponer ambos valores antes del tráfico protegido.

Sin embargo, el parser debe comprender la versión correcta; la política debe aprobar la apertura; el estado debe instalarse en el dispositivo que realmente reenviará; la vida útil debe alcanzar al primer dato; y el flujo debe conservar el camino. Ninguna de esas condiciones nace del verbo learn.

Por eso una respuesta del controlador necesita continuación. ¿Qué regla exacta se escribió? ¿En qué tabla? ¿Con qué propietario y vencimiento? ¿Cuántos paquetes coincidieron? ¿Se observó el mismo ESP después del borde? El control plane registra intención y decisión; el data plane registra efecto.

Si la organización guarda sólo el resultado del parser, un cambio de ruta no invalida el estado verde. La automatización continúa afirmando salud aunque la regla correcta exista en el aparato equivocado.

La señalización conoce una política, no siempre el camino

Otra familia de soluciones permite que los hosts comuniquen explícitamente los SPI al NAT o firewall mediante mecanismos genéricos. RFC 5207 menciona MIDCOM y NATFW NSLP. Esta estrategia evita exigir un parser HIP completo en cada middlebox, pero exige saber a quién hablar.

El documento señala la dificultad en entornos multihomed. Con varios bordes, el host debe identificar qué dispositivos controlan la ruta. Una solicitud válida dirigida al borde A no crea estado en B. Un 200 OK administrativo puede ser completamente irrelevante para el paquete real.

La señalización acoplada al camino intenta recorrer los dispositivos efectivos. Aun así, la ruta puede cambiar más tarde. El recibo necesita un identificador de época y una comprobación posterior. No basta con registrar que el mensaje salió.

Abrir un pinhole es una acción sensible. La autenticación del solicitante, su autorización, el patrón admitido, la duración y la retirada deben ser explícitos. Un peer autenticado en HIP no recibe automáticamente autoridad para modificar toda política de frontera.

El éxito por UDP puede esconder la deuda de ESP

Los middleboxes antiguos suelen permitir UDP saliente y su retorno. Encapsular la negociación puede rescatar la primera fase. RFC 5207 advierte que ESP sigue presentando problemas incluso cuando esa negociación funciona.

Algunos NAT ofrecen VPN pass-through: observan flujos IPsec e intentan correlacionar SPI. Puede ser razonable con pocos hosts, pero las colisiones y la dirección única limitan la inferencia. No es una prueba de que toda asociación tenga ida y vuelta correcta.

La encapsulación UDP de ESP proporciona puertos y se convirtió en parte de desarrollos posteriores. RFC 5770 describió un enfoque experimental basado en ICE; RFC 9028 especificó un modo nativo; RFC 9063 refleja la arquitectura HIP moderna. Esa secuencia es historia de especificaciones. No demuestra que firmware, configuración, política y camino de una instalación coincidan.

El inventario debe nombrar versión, modo, encapsulación, puerto, candidatos, keepalive y observación. Compatible con NAT traversal comprime demasiadas decisiones en una etiqueta comercial.

Una alarma mal nombrada amplía el remedio

Cuando la métrica se llama HIP session established aunque sólo vea la negociación, el diagnóstico se reparte mal. Seguridad muestra el pinhole. Red muestra el SPI saliente. Protocolo muestra autenticación. Aplicación muestra silencio. Cada registro es auténtico, pero ninguno contiene el conjunto.

La presión por restaurar servicio favorece cambios amplios: permitir ESP desde cualquier origen, alargar estados, fijar una salida o desactivar inspección. El tráfico quizá vuelva. También queda una excepción con mayor superficie y sin explicación causal.

El método más seguro identifica el primer salto sin recibo. Huellas de cada mensaje en ambos lados; SPI orientados; instalación por dispositivo; observaciones ESP antes y después; validación y descifrado en los hosts; transacción útil. Allí donde se rompe la cadena se limita la reparación.

La palabra desconocido protege la red. Evita convertir falta de telemetría en éxito y permite pedir una observación adicional sin culpar prematuramente a un componente.

Ni la RFC antigua ni la nueva son estado de ejecución

RFC 5207 refleja el análisis de 2008. Las extensiones posteriores abordaron parte del problema. Un auditor puede equivocarse si trata el texto antiguo como descripción universal; también si cree que publicar un mecanismo nuevo actualiza automáticamente cada aparato.

La especificación define semántica. El software demuestra implementación. La configuración demuestra selección. La política demuestra permiso. La captura demuestra un paquete en un punto. El endpoint demuestra aceptación criptográfica. La aplicación demuestra utilidad.

Running-code primacy exige conservar esas autoridades. No invita a despreciar la RFC, sino a usarla como mapa para recoger evidencia en vez de como sustituto de la observación.

El recibo mínimo sigue dos fases y dos direcciones

Debe incluir versión y modo HIP, HIT y locator, huellas y tiempos de I1/R1/I2/R2, mapping de NAT, identidad y revisión de firewall, SPI de salida y entrada, solicitud y respuesta de señalización, regla instalada, propietario, expiración, camino de cada fase, contadores ESP a cada lado, resultados de integridad y anti-replay, bytes descifrados y resultado de la aplicación.

No hace falta que un solo sistema conozca todo. Hace falta que ninguno expanda su declaración. El firewall informa su regla. El NAT informa su mapeo. El host informa su asociación. El servicio informa su trabajo. La correlación, no la etiqueta, prueba la sesión.

Fuentes