Resumen

  • RFC 5202 hizo legible ESP_INFO para que sistemas intermedios siguieran el cambio de SPI; RFC 7402 mantuvo esa decisión al sustituirla. La firma da integridad y procedencia, no secreto.
  • La dirección debe pedir recibos separados para contenido cifrado, control autenticado, metadatos observables, activación de la nueva SA y eliminación de registros.

Un cambio que debía atravesar el cristal

La mejor forma de entender este diseño no es imaginar un candado, sino una sala con dos conductos. Por uno viaja la carga ESP: cifrada. Por el otro pasa la instrucción que permite a un firewall o NAT reconocer la nueva asociación. Si el segundo conducto fuera igualmente opaco, el intermediario perdería el estado que necesita para prestar su función.

ESP define el SPI como un valor de 32 bits que el receptor usa para localizar una asociación de seguridad entrante. En la cabecera queda junto al número de secuencia, antes de la zona cifrada. RFC 4303 deja claro que ambos campos participan en la integridad pero no se cifran.

HIP añade semántica. El SPI comprime el contexto de un par de HIT y puede servir a sistemas intermedios para mapear direcciones. La precisión temporal es esencial: destino más SPI identifica el HIT receptor en ese momento, no para siempre ni en todo Internet. Una cifra idéntica puede usarse en otros equipos.

La firma estaba allí para el lector intermedio

Al rotar una SA, HIP envía ESP_INFO con el SPI antiguo, el nuevo y el índice de material de claves. El UPDATE lleva también secuencia, un Diffie–Hellman opcional, HMAC y firma HIP. La respuesta devuelve sus parámetros y acuses.

RFC 5202 explica que los sistemas intermedios que usan el SPI deben inspeccionar esos paquetes. El paquete está firmado para beneficio de dichos sistemas. Como pueden necesitar el SPI nuevo, el contenido no puede cifrarse. RFC 7402 conserva las mismas frases en el estándar sucesor.

Esto separa propiedades que muchas fichas comerciales mezclan. La firma permite detectar alteración y atribuir el mensaje al contexto criptográfico correspondiente. El cifrado impediría leer los campos. Un dato firmado y visible puede ser más confiable precisamente porque un tercero autorizado logra verificarlo.

Por eso firma correcta no autoriza la etiqueta metadato privado. Tampoco demuestra que la nueva SA se instaló, que circuló un paquete protegido o que la aplicación respondió. Cada conclusión necesita su punto de observación.

La superficie de inferencia

La cabecera HIP presenta HIT de emisor y receptor; ESP_INFO enlaza una coordenada anterior con otra nueva; la red añade direcciones y tiempo. Un dispositivo con contexto puede actualizar su estado como pretende la especificación. RFC 9063 reconoce que firewalls y NAT conscientes de HIP pueden observar pasivamente el tráfico y mantener estado blando entre control y datos.

RFC 6973 llama análisis de tráfico a inferir mediante presencia, dirección, tiempo, tamaño, composición o frecuencia, incluso si el flujo está cifrado. La transición de SPI es un evento estructurado dentro de esa superficie.

No se debe exagerar. El SPI no nombra a una persona. Por sí solo no identifica de manera universal un host ni revela la carga. La atribución depende de los datos que el observador ya reúne y de cuánto tiempo los conserva. La afirmación responsable es que existe una correlación temporal posible, no una identidad civil automática.

El azar futuro no borra un enlace pasado

HIP recomienda elegir SPI al azar, usar otro para cada intercambio con el mismo par y cambiarlo obligatoriamente durante rekey. Esas medidas combaten repetición y reutilización. No impiden que una captura almacene la relación entre el valor viejo y el nuevo.

El periodo real de exposición lo decide la cadena de retención. La tabla del firewall puede caducar en minutos; el colector de flujos puede conservar meses; un ticket puede incluir una captura sin fecha de borrado. La rotación frecuente de identidades no alcanza a esas réplicas.

La organización necesita, por tanto, un presupuesto de metadatos. Debe especificar qué campo queda disponible, qué función lo requiere, qué actor lo consulta, a dónde se exporta y cómo se prueba el final de su vida. Sin ese inventario, cifrado de extremo a extremo se convierte en una promesa más amplia que el protocolo.

Una escalera de pruebas

El primer peldaño es UPDATE visto. El segundo, HMAC y firma verificados. El tercero, ESP_INFO analizado. El cuarto, mapeo intermedio instalado. Después vienen SA instalada en el extremo, primer paquete autenticado con el SPI nuevo, último uso del SPI antiguo y estado eliminado.

Guardar solo el cuarto paso produce un doble error. Puede atribuir éxito de datos a un cambio de tabla, y puede olvidar que la tabla es una copia de información sensible para operaciones. El recibo debe incluir sensor, dirección, localizadores, referencia a HIT, dos SPI, SEQ/ACK, algoritmos, regla aplicada, expiración y destino de exportación.

La eliminación necesita su propio recibo. Un contador en cero no basta si la captura sigue en un sistema externo. Deben comprobarse tabla, almacenamiento de paquetes, flujo derivado, copia de soporte y copia de seguridad conforme a la política declarada.

Del experimento al estándar

RFC 5202 apareció como Experimental en 2008 y hoy está obsoleta. Su único erratum retenido corrige una palabra sobre parámetros de transformación, sin tocar la tesis. RFC 7402 la sustituyó en 2015 para HIPv2 en Standards Track.

El mantenimiento de la cláusula demuestra que la visibilidad no era un descuido histórico. El informe RFC 6538 y la arquitectura RFC 9063 muestran el equilibrio más amplio: HIP puede reforzar autenticación y permitir prácticas de privacidad, mientras ciertos intermediarios participan en el plano de control. La solución no es negar uno de los lados, sino limitar su mandato.

Una decisión verificable

La dirección debe prohibir que una sola etiqueta de seguridad cubra contenido, control y retención. En contratos, paneles y auditorías deben aparecer cuatro respuestas distintas: qué se cifró, qué se autenticó, qué metadato quedó legible y cuándo desapareció cada copia.

La especificación común debe ser mínima: solo la visibilidad necesaria para la función interoperable. El resto —analítica, conservación, unión entre sensores y acceso humano— es una decisión local que requiere propósito y responsabilidad. La realidad está en el paquete, la tabla y la eliminación observada, no en el símbolo verde.

Fuentes

  1. RFC 5202 HTML
  2. RFC 5202 en texto
  3. Información de RFC 5202
  4. Datatracker IETF: RFC 5202
  5. Historial de RFC 5202
  6. Referencias de RFC 5202
  7. Erratas de RFC 5202
  8. RFC 7402 HTML
  9. RFC 7402 en texto
  10. Información de RFC 7402
  11. Datatracker IETF: RFC 7402
  12. Historial de RFC 7402
  13. Referencias de RFC 7402
  14. Erratas de RFC 7402
  15. RFC 4303 — ESP
  16. RFC 4301 — arquitectura IPsec
  17. RFC 9063 — arquitectura HIP
  18. RFC 6538 — informe del experimento HIP
  19. RFC 6973 — consideraciones de privacidad
  20. Heng Lu — capas de realidad y poder simbólico
  21. Heng Lu — especificación inicial mínima
  22. Heng Lu — primacía del código en ejecución