Host Identity Protocol RFC 7401: lecciones para las direcciones IPvX

Host Identity Protocol RFC 7401 nos resulta útil como ejemplo publicado por el IETF de un protocolo que separa la función de identificador de la función de localizador en las direcciones IP y establece un estado común de nivel IP entre hosts que así lo acuerdan.² HIP utiliza identificadores de clave pública del espacio Host Identity para la autenticación mutua de los participantes y se basa en un intercambio Diffie-Hellman.² Para el diseño de direcciones IPvX, no es un plano ya listo, sino un conjunto de preguntas arquitectónicas que ya fueron formuladas explícitamente en documentos del IETF sobre HIP.¹

Por qué es importante separar identificador y localizador

RFC 7401 describe HIP como una alternativa al doble uso de las direcciones IP: las direcciones IP pueden actuar tanto como locators, es decir, etiquetas de enrutamiento, como identifiers, es decir, identificadores de hosts o de puntos finales.³ En HIP, las claves criptográficas públicas de un par public/private key se utilizan como identificadores de hosts, y los protocolos de capas superiores se vinculan a esos identificadores en lugar de vincularse a una dirección IP.³

RFC 9063 formula el mismo problema de forma más amplia: Internet tiene dos espacios de nombres globales importantes —las direcciones IP y los nombres DNS—, y ambos espacios han quedado semánticamente sobrecargados por el intento de hacer demasiadas cosas con ellos.¹ En la arquitectura HIP, el espacio Host Identity se añade entre los espacios IP y DNS, y la capa de protocolo correspondiente se sitúa entre internetworking y transport layers.¹

Para IPvX extraemos de esto una lección prudente: el direccionamiento por claves no debe mezclar automáticamente la identidad criptográfica, la representación de esa identidad en los paquetes y la ruta de entrega actual.³ Esta es precisamente nuestra interpretación de diseño de HIP, no un requisito de RFC 7401 para IPvX.³

Clave, identidad y etiqueta compacta son entidades distintas

RFC 9063 distingue entre Host Identity y Host Identifier: Identity se refiere a la entidad abstracta que se identifica, mientras que Identifier es el patrón de bits concreto utilizado en el proceso de identificación.¹ En el caso central de la arquitectura HIP, Host Identifier es la clave pública de un par asimétrico.¹

HIP también define Host Identity Tag, o HIT, como un valor de 128 bits obtenido mediante hash criptográfico del Host Identifier con la adición de bits que indican el hash utilizado.¹ En la terminología de RFC 9063, Host Identity Hash es el hash criptográfico usado al crear un HIT a partir de un Host Identifier.¹ El documento también define Local Scope Identifier como un valor de 32 bits que designa una Host Identity en un ámbito local.¹

Estas definiciones nos aportan una disciplina terminológica útil para IPvX: «clave», «identidad abstracta», «etiqueta compacta» e «identificador de ámbito local» no son el mismo concepto en HIP.¹ Podemos usar esta disciplina al describir direcciones IPvX, pero no debemos presentarla como una prescripción directa de RFC 9063 para IPvX.¹

La historia de HIT también muestra que el formato de una representación compacta puede evolucionar.⁶ En RFC 4423, HIT se describía como un valor de 128 bits creado mediante el hash de un Host Identifier.⁶ En RFC 9063, la definición de HIT ya incluye bits que indican el hash utilizado.¹ Esto no demuestra cuál debe ser el formato de una dirección IPvX, pero muestra que, en HIP, el contexto algorítmico de una etiqueta compacta pasó a formar parte de la descripción arquitectónica.¹

Base Exchange como modelo para establecer estado

RFC 7401 define el base HIP protocol, o base exchange, utilizado entre hosts para establecer un IP-layer communications context, denominado HIP association, antes de la comunicación.³ En el contenido de RFC 7401 se enumeran por separado la creación de una HIP Association, el HIP Puzzle Mechanism, el intercambio de puzzle, el Diffie-Hellman autenticado con negociación de grupo DH, la protección contra repeticiones, el rechazo del base exchange, la interrupción del base exchange, la downgrade protection y el opportunistic mode.²

La especificación RFC 7401 también enumera los paquetes de control I1, R1, I2, R2, UPDATE, NOTIFY, CLOSE y CLOSE_ACK.² En el mismo documento hay secciones sobre la actualización de la HIP association, el tratamiento de errores, la HIP state machine, el procesamiento de UPDATE con SEQ y ACK, el procesamiento de CLOSE y CLOSE_ACK, así como handling state loss.²

Para IPvX, este conjunto de temas es útil como lista de verificación para diseñar una conexión, pero no como prueba de que IPvX deba repetir la state machine de HIP.² Podemos comprobar nuestro propio diseño frente a las mismas clases de preguntas: cómo se crea una asociación, cómo se negocian los parámetros, cómo se detectan los errores, cómo se actualiza el estado y cómo se cierra la comunicación.² Al mismo tiempo, la afirmación de un «arranque barato» no debe deducirse únicamente de RFC 7401; la fuente confirma directamente la existencia de un puzzle mechanism y de secciones de protección, pero no formula un requisito universal para cualquier protocolo de direccionamiento por claves.²

La seguridad de la carga útil y las asociaciones son capas separadas

RFC 7401 afirma que HIP designed to be resistant to denial-of-service and man-in-the-middle attacks.² El documento también indica que, cuando se utiliza con un protocolo de seguridad adecuado, por ejemplo ESP, HIP proporciona integrity protection y optional encryption para protocolos de nivel superior, como TCP y UDP.²

RFC 9063 precisa el papel arquitectónico: al utilizar HIP, la carga útil entre hosts HIP normalmente, aunque no necesariamente, se protege mediante Encapsulating Security Payload, y las Host Identities se utilizan para crear las ESP Security Associations necesarias y autenticar los hosts.¹ Esta es una frontera importante para IPvX: el direccionamiento basado en claves puede formar parte de la autenticación, pero la protección de la carga útil, los parámetros de security association y el ciclo de vida de esas asociaciones requieren una descripción aparte.¹

Los documentos HIP también muestran que la flexibilidad criptográfica fue objeto de una corrección explícita.² RFC 7401 señala que el documento aborda las observaciones del IESG, en particular sobre crypto agility, e incorpora lecciones de las implementaciones de RFC 5201.² RFC 9063 también dice que tiene en cuenta concerns raised by the IESG, particularly crypto agility.¹ Para IPvX esto no es una regla ya lista sobre hashes concretos o tipos de claves, pero sí una razón de peso para documentar explícitamente el contexto algorítmico de las direcciones y el procedimiento de evolución de los formatos.¹

Rendezvous, movilidad y cambio de direcciones

Una de las propiedades centrales de HIP en RFC 7401 es mantener la continuidad de la comunicación cuando cambian las direcciones IP gracias a la separación de las funciones identifier y locator.² RFC 9063 describe la capa HIP como compatible con end-host mobility, multihoming y NAT traversal.¹

En la terminología de RFC 9063, Rendezvous Mechanism es un mecanismo para encontrar hosts móviles por su HIT.¹ En RFC 4423, rendezvous mechanism también se definía como el mecanismo utilizado para encontrar hosts móviles por Host Identity Tag.⁶

De aquí se deriva para IPvX una formulación prudente de la lección: un identificador estable basado en claves no describe por sí solo dónde se encuentra ahora el destinatario.¹ Si un protocolo quiere conservar la identidad cuando cambia la ruta de entrega, necesita una forma independiente de vincular el identificador con el localizador o la ruta actuales; HIP denomina a esta clase de tarea rendezvous mechanism.¹

Es importante no exagerar esta conclusión.² RFC 7401 confirma la existencia de procedimientos UPDATE, SEQ y ACK para procesar actualizaciones de la HIP association, pero de ello no se desprende una regla automática de escalado para IPvX.² Podemos usar HIP como ejemplo de que el cambio de estado de una asociación se separa en procedimientos específicos; sin embargo, los parámetros de tolerancia a fallos y escalabilidad de IPvX deben verificarse mediante nuestros propios experimentos reproducibles.²

Certificados: extensibilidad sin sobrecargar el primer paquete

RFC 8002 actualiza RFC 7401 y define el CERT parameter como contenedor para certificados digitales en los paquetes de control HIP.⁵ El mismo documento subraya que el CERT parameter no define la semántica de los certificados, y que los escenarios de uso concretos deben ser definidos por los documentos que emplean este parámetro.⁵

Este es un buen ejemplo de separación entre mecanismo y política de confianza.⁵ El protocolo base puede describir el transporte de certificados, la agrupación de CERT parameters relacionados y la señalización de errores cuando falla una verificación, sin incrustar todas las decisiones de escenario en un único formato universal.⁵

RFC 8002 contiene también una lección negativa: no se recomienda usar CERT en el primer Initiator packet I1, porque esto puede aumentar el tiempo de procesamiento de I1 y convertirse en un problema ante processing storms of I1s.⁵ Para IPvX podemos formularlo como una hipótesis de diseño: las pruebas, los certificados y las atestaciones no deberían colocarse automáticamente en el paquete más temprano y masivo del handshake.⁵ Esta es precisamente una conclusión para nuestro diseño, no un requisito citado de RFC 8002 para IPvX.⁵

RFC 8002 también describe variantes para transmitir punteros en lugar de los propios certificados: Hash and URL, LDAP URL y Distinguished Name pueden reducir los HIP control packets, pero obligan al destinatario a resolver el URL, obtener el certificado o comprobar la caché local.⁸ Por eso, al diseñar el IPvX-handshake hay que tener en cuenta por separado el compromiso entre un mensaje autosuficiente y la dependencia de obtener externamente los datos de confianza.⁸

Documentar la madurez y las limitaciones

RFC 4423 era un documento informativo y se describía explícitamente como una instantánea del razonamiento sobre la arquitectura HIP en otoño de 2003.⁶ RFC 4423 también decía que la arquitectura podía haber cambiado y que el documento representaba un punto estable en la evolución de la comprensión.⁶ Este ejemplo es importante para un protocolo de investigación: el estado del documento y el grado de madurez de la arquitectura deben ser visibles para el lector.⁶

RFC 9063 sustituyó a RFC 4423 y siguió siendo un documento de categoría Informational, mientras que RFC 7401 es un documento Standards Track con estado Proposed Standard.⁴ Esto muestra que la descripción arquitectónica y la especificación base de un protocolo pueden tener estados distintos en el proceso del IETF.⁴

Security Considerations en RFC 9063 incluye flooding attacks, el uso de identities en access control lists, weaker types of identifiers y trust on first use.¹ Los apéndices de RFC 9063 también incluyen design considerations, benefits, drawbacks, deployment and adoption considerations, deployment analysis, infrastructure applications y management of identities in a commercial product.⁴ Para nuestros proyectos de RFC sobre IPvX, esto respalda la práctica de separar explícitamente el formato del paquete de las limitaciones, los supuestos operativos y los compromisos conocidos.⁴

El historial de RFC 7401 en Datatracker registra la publicación de la RFC el 9 de abril de 2015 y la actualización de los registros IANA el 10 de abril de 2015.⁷ Ese mismo historial muestra sincronizaciones posteriores de metadatos de RFC Editor, incluidos cambios en el abstract en 2018, la adición de la etiqueta Verified Errata en 2020 y actualizaciones de metadatos en 2026.⁷ Esto no demuestra la existencia de todas las RFC posteriores que la actualizan, pero sí muestra que el registro público del documento sigue manteniéndose después de la publicación.⁷

Qué incorporamos a IPvX

Primera lección: al describir direcciones IPvX basadas en claves conviene distinguir explícitamente entre identidad abstracta, clave pública como identificador, representación compacta con hash y localizador actual, porque HIP diferencia entre Host Identity, Host Identifier, HIT y locator role IP address.¹³

Segunda lección: el establecimiento de una conexión debe diseñarse como un ciclo de vida del estado, no como un único intercambio de claves, porque RFC 7401 describe HIP association, base exchange, state machine, UPDATE, NOTIFY, CLOSE, CLOSE_ACK y handling state loss.²

Tercera lección: rendezvous debe considerarse una tarea separada del control plane, porque RFC 9063 define un mecanismo para encontrar hosts móviles por HIT y vincula la arquitectura HIP con movilidad, multihoming y NAT traversal.¹

Cuarta lección: conviene separar los certificados y las pruebas adicionales de la semántica básica de la dirección, porque RFC 8002 define el CERT parameter como contenedor y deja la semántica de escenario a los documentos que utilizan ese parámetro.⁵

Quinta lección: las limitaciones, los resultados negativos y el historial de decisiones deben formar parte de nuestros borradores, porque los documentos HIP muestran explícitamente el estado de madurez, security considerations, drawbacks y deployment considerations.⁴⁶

La conclusión para nosotros es prudente: HIP no define IPvX ni nos exime de la obligación de comprobar el enrutamiento, los fallos y la escalabilidad en nuestros propios experimentos reproducibles.² Pero HIP proporciona un lenguaje publicado para discutir direcciones basadas en claves, asociaciones de seguridad, rendezvous, movilidad y las fronteras entre arquitectura, especificación y limitaciones operativas.¹²

Fuentes

1. RFC 9063: Host Identity Protocol Architecture, rfc-editor.org, 1 jul 2021
2. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
3. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
4. RFC 9063: Host Identity Protocol Architecture, datatracker.ietf.org
5. RFC 8002: Host Identity Protocol Certificates, datatracker.ietf.org
6. RFC 4423: Host Identity Protocol (HIP) Architecture, datatracker.ietf.org
7. History for rfc7401, datatracker.ietf.org
8. RFC 8002: Host Identity Protocol Certificates | RFC Editor, rfc-editor.org