Resumen

  • La arquitectura HIP de 2006, escrita por Robert Moskowitz y Pekka Nikander, usa una identidad basada en clave pública para nombrar el extremo y reserva a la dirección IP el papel de localizarlo para el encaminamiento.
  • La separación puede conservar una asociación cuando cambia la dirección si ambos hosts usan HIP. No transfiere un registro de recursos ni actualiza automáticamente las reglas de cada aplicación.

Un portátil sale de una red y recibe otra dirección. Ha cambiado el camino por el que llegan los paquetes, pero no el equipo con el que se comunica. Durante mucho tiempo, los protocolos han pedido a la misma cifra que describa tanto una ubicación topológica como el extremo de una comunicación. Robert Moskowitz y Pekka Nikander pusieron esa carga doble en el centro de la RFC 4423.

El Host Identity Protocol añade un espacio de identidad entre la capa de Internet y la de transporte. En esa arquitectura, el identificador de host es una clave pública; la identidad que representa es el concepto abstracto. El Host Identity Tag (HIT) sirve como representación compacta de 128 bits. La dirección IP no desaparece: sigue diciendo a los routers adónde enviar el tráfico. Lo que deja de hacer es definir por sí sola qué host corresponde a una asociación de transporte.

Ese cambio de vínculo explica el alcance de HIP. La RFC 4423 describe asociaciones de transporte ligadas a identidades de host. Si el host cambia de dirección al moverse, conectarse a otra red o renumerarse, un par compatible con HIP puede actualizar el localizador y conservar la asociación asociada a esa identidad. Un mismo host también puede ser alcanzable por varias interfaces. Así, parte de la continuidad pasa a depender del estado criptográfico que comparten los dos extremos participantes.

La historia de las RFC permite precisar la aportación de Moskowitz. La RFC 4423 se publicó en mayo de 2006 como documento Informativo. Su propio resumen la define como una instantánea del razonamiento de los autores en otoño de 2003 y advierte que la arquitectura podía haber evolucionado; no es una norma de Internet. La RFC 7401, editada por Moskowitz junto con otros autores, especifica HIP versión 2 en la categoría Standards Track. Describe cómo hosts que consienten establecen un estado compartido en la capa IP mediante un intercambio criptográfico de cuatro paquetes. En 2021, la RFC 9063, de Moskowitz y Miika Komu, actualizó la arquitectura, dejó obsoleta la RFC 4423 e incorporó aprendizajes de implementaciones de la RFC 7401, además de abordar la agilidad criptográfica y la confianza en el primer uso.

La secuencia documenta una idea técnica que maduró; no demuestra que Internet haya dejado de depender de las direcciones. HIP mantiene la asociación que administran sus dos extremos. Un cortafuegos puede seguir permitiendo solo una IP de origen. DNS puede conservar un localizador anterior. El otro extremo quizá no implemente HIP. Una aplicación puede guardar una dirección en su configuración o utilizarla como señal de reputación. Que una asociación sobreviva al cambio no migra automáticamente ninguno de esos elementos.

Nota 68 de Heng Lu aporta una lente económica diferente: la dirección puede convertirse en memoria de negocio cuando clientes, socios y equipos de seguridad construyen expectativas en torno a ella. Esa observación no describe HIP ni prueba que se haya desplegado en un entorno concreto. Sirve para separar dos ideas de continuidad. HIP distingue la identidad del host que usa el intercambio de protocolo del localizador que usa el encaminamiento; no rehace las relaciones externas que se hayan acumulado alrededor de una IP.

La contribución de Moskowitz se entiende mejor como una frontera de arquitectura: «mi ruta puede cambiar; mi identidad autenticada como extremo es otro estado». El diseño es valioso precisamente porque su alcance es limitado. Puede reducir la dependencia de direcciones fijas en movilidad y multihoming, pero deja el DNS, el encaminamiento, la administración de recursos, las políticas de aplicación y la continuidad de cara al cliente en sus propios sistemas.

Fuentes