Resumen

  • El respondedor de HIP puede escoger una R1 precalculada después de I1 y seguir sin estado específico; la firma demuestra quién generó el material cubierto, no cuándo atendió esta solicitud.
  • I2 válida, R2 verificada, asociación de carga útil y respuesta de aplicación son hitos diferentes. Cada uno autoriza una afirmación más estrecha de lo que suelen mostrar los paneles.

El orden de los paquetes no es el orden de las promesas

I1 activa el intercambio. R1 ofrece el reto, el material Diffie–Hellman y la identidad del respondedor. I2 devuelve la solución y la contribución autenticada del iniciador. R2 completa el intercambio base. Esa descripción invita a imaginar que el respondedor va acumulando estado desde el primer paquete. RFC 5201 permite lo contrario.

El respondedor puede mantener un conjunto de R1 preparadas. Cuando llega I1, selecciona una, ajusta los campos permitidos y responde sin abrir una asociación para ese iniciador. La figura del protocolo dice de forma expresa que permanece sin estado. RFC 7401, que sustituyó a RFC 5201, conserva la misma arquitectura.

La finalidad es económica y defensiva. Si cada I1 con origen falsificado obligara a reservar memoria, verificar una firma o calcular Diffie–Hellman, el coste recaería en el objetivo. La R1 precalculada traslada trabajo al iniciador y retrasa la asignación costosa hasta que llegue una I2 que merezca validación.

Por eso una respuesta rápida no equivale a una reserva. Puede ser el producto correcto de una ruta que deliberadamente no recuerda al solicitante.

La firma conserva procedencia, no presencia

La firma de R1 cubre material producido por la Host Identity del respondedor. La especificación limita su significado: la R1 fue generada alguna vez por ese respondedor. No cubre toda la información específica de I1 y, al ser precalculada, no impide por sí sola la repetición.

Una sonda sí puede afirmar que recibió ciertos bytes a una hora local y que la firma era válida bajo una clave y un conjunto de algoritmos. No puede derivar de ello que el respondedor estaba procesando en ese instante, que vio esa I1 particular, que creó estado o que aceptó prestar el servicio.

El contador de generación R1 ayuda a elegir retos más recientes. No es un reloj universal. Puede conservarse, reiniciarse o perderse según las reglas del protocolo y de la implementación. HIPv2 mantiene la decisión de no insertar una marca de tiempo en R1 para no exigir sincronización global. Convertir el contador en “edad del servidor” inventa una semántica.

El recibo útil debe guardar HIT, generación, vida y dificultad del puzzle, valor opaco, parámetros criptográficos, resultado de la firma y tiempos monotónicos locales. La incertidumbre sobre frescura debe aparecer como incertidumbre.

Resolver el puzzle solo paga el peaje computacional

El iniciador prueba valores hasta obtener el patrón de hash exigido sobre el reto, ambos HIT y la solución. El respondedor comprueba el resultado con un hash barato. Así puede descartar I2 falsas antes de la verificación de clave pública y del cálculo de secreto compartido.

La RFC llama “sincero” al iniciador que gastó ciclos de CPU. Esa palabra no debe convertirse en una evaluación de confianza. El trabajo no acredita a una empresa, no demuestra intención benigna, no satisface una política comercial, no reserva capacidad y no prueba que exista una aplicación detrás del endpoint.

Tampoco es una defensa absoluta. El vínculo al HIT dificulta fabricar muchas identidades a partir de un único intercambio, pero el texto reconoce el caso de atacantes con HIT fijos. Una implementación puede recordar fallos y aceptar el coste de memoria. El operador debe registrar qué variante ejecutó y qué regla eligió la dificultad.

I2 cambia la clase de evidencia

Con I2 llega la solución del puzzle, la clave pública del iniciador y su firma. El respondedor puede verificar primero el trabajo barato y, si procede, realizar las operaciones costosas. Cuando acepta la I2, deriva material de claves y crea la asociación HIP correspondiente.

Ese evento ya implica una decisión local de admisión técnica. Sin embargo, un registro del respondedor no demuestra que R2 haya cruzado la red. La verificación de R2 por el iniciador completa el intercambio desde su perspectiva y prueba que el respondedor poseía el resultado compartido. Para una reconstrucción sólida hacen falta ambos lados.

Esta graduación evita diagnósticos engañosos. Si hay R1 en la captura y no hay sesión en la base del respondedor, puede no faltar ningún registro: quizá I2 nunca llegó, el reto caducó, la solución falló o la firma no se aceptó. La ausencia de estado antes de I2 es una propiedad, no un hueco.

El tráfico útil vive un escalón después

El intercambio base crea estado HIP y material de claves, pero no especifica por sí mismo el formato de datos. RFC 7401 remite a transportes separados y exige soporte para ESP conforme a RFC 7402. Su explicación de recuperación indica que, tras completar el intercambio, se puede crear una nueva asociación de carga útil y entonces enviar datos.

R2 verificada no prueba que ambos extremos instalaron las asociaciones ESP. Una instalación local no prueba simetría. Un paquete protegido saliente no prueba recepción. La recepción de red no prueba aceptación de aplicación. La evidencia debe avanzar con cada efecto real.

Para declarar un camino listo hacen falta formato negociado, suites, localizadores, época de clave, identificadores de asociación protegidos, resultados de instalación en ambos extremos y primer paquete autenticado en cada sentido. Para declarar el servicio listo, añádase una respuesta específica de la aplicación.

La matriz que el panel debería mostrar

Señal Hecho comprobado Conclusión todavía prohibida
I1 transmitida El iniciador emitió el disparador El respondedor la recibió
Firma R1 válida La clave del respondedor originó ese material en algún momento Vida actual y estado reservado
Puzzle resuelto Se realizó el trabajo requerido Aceptación del respondedor
I2 aceptada Se creó estado HIP según una política R2 recibida por el iniciador
R2 verificada Terminó el intercambio base en ese extremo Asociación de carga útil activa
Estado ESP instalado Existe una asociación de transporte Éxito bidireccional de la aplicación
Petición y respuesta protegidas Ocurrió un efecto acotado Disponibilidad continuada

El recibo de cada fila debe incorporar versión de implementación, regla aplicada, coordenadas del protocolo, tiempo local y motivo de rechazo. La causalidad no cabe en un icono verde.

Un experimento histórico, una frontera vigente

RFC 5201 apareció en abril de 2008 como Experimental y afirma que no especifica un estándar de Internet. La nota del IESG planteó reparos sobre SHA-1, agilidad de MAC, usos de RSA y políticas basadas en direcciones IP. RFC 6253 añadió después el manejo de certificados.

RFC 7401 la dejó obsoleta en 2015, convirtió HIPv2 en Proposed Standard e incorporó agilidad criptográfica y experiencia de implementación. RFC 8002 y RFC 9374 actualizaron después partes de esta familia. No sería responsable recomendar hoy la suite de 2008.

Sí es responsable aprender de una decisión que HIPv2 conserva: una respuesta auténtica puede preceder a todo compromiso específico. La mínima especificación de una consola debe nombrar el nivel observado, no la historia que el operador desearía contar.

Fuentes

  1. RFC 5201 HTML
  2. RFC 5201 en texto
  3. Ficha de RFC 5201
  4. Datatracker de RFC 5201
  5. Historial de RFC 5201
  6. Referencias de RFC 5201
  7. Erratas de RFC 5201
  8. RFC 7401 — HIPv2
  9. RFC 7401 en texto
  10. Ficha de RFC 7401
  11. Erratas de RFC 7401
  12. RFC 7402 — transporte ESP para HIP
  13. RFC 4423 — arquitectura HIP
  14. RFC 4987 — defensas ante inundación SYN
  15. RFC 6253 — certificados HIP
  16. RFC 8002 — certificados HIPv2
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — capas de realidad y poder simbólico
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — primacía del código en ejecución