Resumen

  • Las RFC 5206 y 8046 autentican el anuncio de movilidad, pero la dirección nueva suele empezar como UNVERIFIED. La respuesta a un nonce enviado allí aporta la prueba de alcance.
  • Credit-Based Authorization permite continuidad limitada durante la duda. Su propósito es evitar amplificación, no declarar que la ruta, la SA o la aplicación ya funcionan.

Un movimiento no cabe en una sola luz verde

HIP mantiene la identidad del host mientras cambia la dirección que transporta los paquetes. Para una consola, la tentación es mostrar una sola transición: antiguo locator rojo, nuevo locator verde. El protocolo conserva más realidad que ese dibujo.

Primero llega un mensaje autenticado. Demuestra que quien posee el contexto HIP anunció una dirección, un tiempo de vida y quizá una preferencia. Después viene la pregunta de red: ¿puede ese mismo par recibir y contestar allí? Entre ambas existe un estado diseñado, UNVERIFIED.

La diferencia protege incluso al par honesto. Una interfaz puede haberse apagado entre la firma y el envío. El enrutamiento puede estar convergiendo. Un NAT puede haber olvidado su estado. Una política puede filtrar ESP aunque acepte UPDATE. La autenticidad del hablante no corrige ninguno de esos hechos.

La prueba debe recorrer el camino

El método típico inserta un nonce aleatorio en ECHO_REQUEST y dirige el UPDATE a la nueva dirección. La respuesta correspondiente acredita que el mensaje llegó y que el par contestó desde el contexto esperado. También puede servir un paquete protegido en una SA recién anunciada, porque esa observación ocurrió realmente en la ruta.

El recibo debe conservar nonce, destino, tiempos, reintentos, asociación, SPI y resultado criptográfico. Guardar sólo verification=true impide distinguir una respuesta HIP de datos implícitos, un reintento tardío o un error de correlación.

Crear una SA no basta. Tampoco basta cambiar una tabla local. La secuencia honesta separa preparación criptográfica, llegada en la dirección, primer payload aceptado y recuperación de la aplicación.

Preferencia y vigencia son políticas

El bit preferido dice dónde desea recibir el peer. Si la dirección no está verificada y existe otra ACTIVE, la especificación recomienda conservar la ruta activa mientras termina la prueba. Sólo después se cambia el estado.

El tiempo de vida del locator limita cuánto tiempo permanece la declaración. No es un contrato de disponibilidad. Una ruta puede fallar antes de expirar; una dirección puede volver a ser incierta tras un periodo sin tráfico; una renovación puede mover DEPRECATED de nuevo a UNVERIFIED, no a verdad automática.

Las excepciones de R1 pertenecen al intercambio base y deben registrarse con su regla concreta. No autorizan a tratar cualquier locator firmado como validado.

CBA reconoce la duda

Una aplicación móvil puede sufrir si espera un round trip completo. CBA usa el volumen recibido recientemente del peer como crédito para enviar una cantidad limitada a la dirección todavía no verificada. El crédito se consume y envejece.

El mecanismo no prueba propiedad de dirección. No impide toda inundación. Evita que la redirección produzca una amplificación atractiva y reduce el beneficio de un atacante fuera del camino. Precisamente por eso el estado continúa llamándose UNVERIFIED.

La métrica correcta incluye crédito ganado, factor de envejecimiento, bytes gastados, tráfico rechazado y resultado final. «Paquetes enviados» no equivale a «ruta comprobada» cuando el protocolo permite enviarlos antes de la prueba.

Un recibo para cada autoridad

La operación debería enlazar: asociación; UPDATE; conjunto de locators; controles de sintaxis; estado inicial; challenge; response; transición; selección preferida; SA; primer paquete protegido; resultado de servicio; expiración y eliminación. Cada evento tiene productor y reloj.

Esto evita atribuir al emisor autoridad sobre el routing, a IPsec autoridad sobre la aplicación o a un panel autoridad sobre hechos que no midió. También limita la retención: un historial de locators puede revelar movimientos aunque cada mensaje fuera legítimo.

Leer la sucesión correctamente

RFC 5206 fue Experimental en 2008 y está obsoleta. RFC 8046 la sustituyó en 2017 en Standards Track, cambió LOCATOR por LOCATOR_SET y trasladó multihoming a RFC 8047. Conservó la distinción entre anuncio y alcance.

Una referencia nueva no demuestra que el binario la implemente. El inventario necesita versión, parámetros, temporizadores, estados, CBA y observación de paquetes.

La dirección debe exigir cuatro afirmaciones separadas: anuncio autenticado, dirección verificada, ruta protegida activa y aplicación continua. La firma permite confiar en quién habló. Sólo el paquete de vuelta permite confiar en dónde respondió.

Fuentes

  1. Información RFC 5206
  2. RFC 5206 HTML
  3. RFC 5206 texto
  4. Datatracker RFC 5206
  5. Historia RFC 5206
  6. Referencias RFC 5206
  7. Errata RFC 5206
  8. Información RFC 8046
  9. RFC 8046 HTML
  10. RFC 8046 texto
  11. Datatracker RFC 8046
  12. Historia RFC 8046
  13. Referencias RFC 8046
  14. Errata RFC 8046
  15. RFC 7401 — HIP v2
  16. RFC 7402 — transporte ESP HIP
  17. RFC 8047 — multihoming HIP
  18. RFC 6973 — privacidad
  19. RFC 4423 — arquitectura HIP
  20. Heng Lu — capas de realidad
  21. Heng Lu — especificación inicial mínima
  22. Heng Lu — primacía del código operativo