Resumen

  • RFC 5204 define al RVS como punto inicial: busca el HIT registrado, reenvía I1 y deja que el respondedor envíe R1 directamente al iniciador.
  • FROM y RVS_HMAC conservan y protegen el contexto de la reescritura; no convierten la dirección registrada en una observación viva ni autentican por sí solos a los dos extremos.
  • Una operación defendible registra por separado descubrimiento DNS, época del registro, transformación, recepción remota, retorno, I2/R2, tráfico protegido y efecto de la aplicación.

El éxito estaba en el componente equivocado

Un RVS recibe I1, encuentra el HIT, elige el locator y registra “relay successful”. El monitor copia esa señal y presenta “host reachable”. Entre ambos eventos hay una inferencia no demostrada.

El propósito de RFC 5204, documento Experimental de 2008 obsoleto por RFC 8004, es ayudar a iniciar comunicación con nodos HIP móviles o multihomed. El nodo registra su HIT y su dirección actual. Un iniciador descubre el RVS, normalmente mediante DNS, y envía allí I1. Si existe un registro apropiado, el servidor reenvía el paquete; si no existe, lo descarta.

Ese comportamiento demuestra una decisión local bajo una vista del registro. No demuestra que el locator siga asignado, que el camino lo alcance, que el host acepte el contacto ni que la aplicación esté disponible.

Un caso hipotético lo aclara. El móvil cambia de acceso, pero la actualización se retrasa. El registro todavía no ha expirado y el RVS actúa correctamente sobre la información que posee. El paquete sale hacia la red anterior. La conformidad del servidor y la ausencia del par pueden coexistir.

I1 usa al intermediario; el retorno no

El flujo previsto tiene una asimetría esencial. I1 pasa por el RVS. R1 sale del respondedor directamente al iniciador. I2 y R2 también son directos. El servidor de rendezvous no es un relay permanente de la sesión.

Por eso deben existir estados distintos: iniciador-a-RVS, RVS-a-locator, recepción por el respondedor, retorno directo, finalización del base exchange y datos de usuario. Medir el segundo y etiquetarlo como el sexto borra justamente la incertidumbre que el diseño deja para los pares.

La especificación tampoco cubre al iniciador usando su propio RVS para atravesar NAT o firewall. Un producto puede añadir otro mecanismo, pero no debe atribuir esa promesa a RFC 5204 ni reutilizar el mismo recibo.

La reescritura tiene una procedencia acotada

El filtrado de egreso puede impedir que el RVS mantenga como source IP la dirección del iniciador. El servidor puede sustituirla por la suya y añadir un parámetro FROM con la dirección original. RVS_HMAC, calculado con la clave de integridad creada durante el registro, protege el paquete y ese parámetro.

Si ya hay valores FROM, cada servidor añade otro. La lista conserva la secuencia declarada de rendezvous. Es evidencia sobre la transformación, no una prueba completa del camino IP. Tampoco convierte la dirección de origen en la Host Identity del iniciador.

La autoridad de RVS_HMAC termina en la relación RVS-cliente. Probar que un servidor registrado protegió el campo es diferente de probar que el iniciador controlaba la dirección en ese instante, que el respondedor recibió el paquete o que los peers se autenticaron.

Dos integridades para dos preguntas

I1 todavía no incluye los HMAC y firmas end-to-end del intercambio HIP. Por eso el RVS puede modificar cabeceras, añadir parámetros y recalcular checksums. Más tarde, el base exchange autentica a los extremos.

Un sistema que representa ambos controles como “signature valid” pierde el sujeto de la firma. El primer control responde por la transformación del intermediario. El segundo responde por la negociación entre hosts. Después aún queda demostrar el plano de datos y la aplicación.

RFC 5204 advierte sobre redirección, amplificación, reflexión y ataques contra HIP. El RVS es atractivo precisamente porque puede proyectar tráfico hacia un locator basándose en estado registrado. Los límites de esa autoridad deben estar visibles en alertas y auditorías.

VIA_RVS no es un traceroute

Cuando el respondedor contesta a un I1 reenviado, añade VIA_RVS a R1. Su finalidad principal es diagnóstica: ayudar a identificar el rendezvous implicado si el establecimiento presenta problemas.

La presencia del parámetro demuestra que el respondedor construyó R1 con ese contexto. Todavía hace falta observar que el iniciador recibió y validó R1. La dirección contenida no relata todos los saltos ni garantiza que la ruta de retorno coincida con la ida.

Por ello conviene almacenar R1 creado, R1 recibido, R1 validado, I2 enviado, R2 recibido y asociación operativa como eventos diferentes.

DNS y registro son relojes separados

El DNS publica dónde buscar al RVS. Su dato tiene TTL, cache, posible firma y momento de resolución. El registro publica qué locator aceptó el RVS para un HIT. Tiene lifetime, renovación y última actualización.

Un RR reciente puede conducir a un servidor sin registro. Un registro válido puede contener un locator viejo. Una dirección correcta puede ser inaccesible por política o ruta. “Actual” en una base de datos significa actual para esa base, no necesariamente observado ahora en el mundo.

El recibo útil une ambos relojes y después añade observación: RR utilizado, HIT, ID y época del registro, I1 exacto, resultado del lookup, cabeceras antes y después, FROM, contexto HMAC, emisión, recepción, R1, I2/R2, asociación, ESP y resultado de servicio.

La obsolescencia exige inventario, no conclusiones automáticas

RFC 8004 reemplazó RFC 5204; RFC 7401, 8003, 8005 y 8046 actualizan piezas vecinas del conjunto HIP. Esto obliga a identificar la generación implementada. No prueba por sí solo que una plataforma esté anticuada, sea vulnerable o haya migrado.

La ficha “HIP supported” es demasiado pobre. Debe mostrar versión, algoritmos, tipos de registro, parámetros, políticas y evidencia de ejecución. Una cita de norma describe una intención; el running code y sus recibos describen la realidad operativa.

Sources