Summary

  • El CID localiza un contexto DTLS existente, pero no valida la nueva dirección de origen UDP.
  • RRC básico sondea la dirección nueva; RRC mejorado pregunta primero si el camino anterior sigue siendo preferido.
  • La respuesta con la cookie correcta limita una decisión de vinculación, no la causa, simetría, estabilidad ni entrega de la aplicación.

Reconocer la conexión no basta

Un registro protegido llega desde una dirección distinta. El CID conduce al contexto correcto y la autenticación funciona. RFC 9853 impide convertir ese hallazgo en aceptación automática de la dirección. Añade RRC al CID de DTLS 1.2 de RFC 9146 y a DTLS 1.3 de RFC 9147.

El protocolo no conoce la causa: puede existir un cambio de NAT, una migración voluntaria o una copia auténtica adelantada por otra ruta. La observación debe conservarse como diferencia de dirección, no como diagnóstico.

RRC usa la extensión 61 y ContentType 27. Sus mensajes cifrados y autenticados llevan una cookie de ocho bytes. El registro IANA separa path_challenge, path_response y path_drop. Una cookie fresca enlaza respuesta y reto en una generación concreta; reutilizarla sin protección contra repetición debilita esa relación.

Dos algoritmos, dos modelos de amenaza

El control básico envía el reto a la dirección nueva. Si vuelve una respuesta protegida con la cookie correcta antes de T, el iniciador actualiza la vinculación; si vence T, no la cambia. El intercambio demuestra que ese reto salió y esa respuesta volvió. No demuestra rutas idénticas, estabilidad futura, PMTU inversa ni entrega posterior.

El control mejorado se ocupa de un atacante fuera del camino que puede copiar registros válidos y ganar la carrera por una ruta más rápida. Primero desafía la dirección anterior. Si el camino viejo sigue siendo preferido, path_response ordena conservarlo. Si está vivo pero dejó de ser preferido, path_drop da paso a un control básico de la dirección nueva. El vencimiento también conduce al control básico, sin autorizar por sí mismo ningún cambio.

En un rebinding de NAT las dos partes ven cosas distintas: el iniciador percibe un camino nuevo, mientras el respondedor todavía ve el viejo. Por eso path_drop sólo tiene sentido cuando el respondedor sabe que migró voluntariamente. Incluso el modo mejorado tiene un límite: una ruta reenviada que siempre sea más rápida puede confundirse con una mejora real.

Antes de validar, el receptor detiene los datos de aplicación almacenados o limita lo enviado a tres veces los datos aceptados desde la dirección no validada. Después, las operaciones pendientes pueden reanudarse hacia la dirección vinculada. Poder enviar no equivale a haber entregado.

T debe reflejar el camino: tres RTT si se conoce el RTT activo y un segundo si no, salvo perfiles específicos. Un segundo cambio durante una validación no se anida: se descarta la respuesta, vence el intento, la vinculación no cambia y nuevos datos comienzan otra generación.

Cinco recibos para una sola palabra

“Continuidad” necesita cinco recibos: contexto y CID; modo, cookie, direcciones y temporizador del control; acto exacto de vinculación; primer paquete protegido recibido en cada dirección; solicitud de aplicación aceptada y respuesta correlacionada dentro del plazo. El retorno de una cookie sólo cubre el segundo tramo y puede habilitar el tercero.

RFC 9853 recomienda registrar fallos, respuestas múltiples y sondeos frecuentes para SIEM y diagnóstico. Son señales posibles, no hechos de ataque o inestabilidad. La ficha del RFC Editor, el Datatracker y los errata documentan la norma, no despliegues.

La primacía del código en ejecución, la especificación inicial mínima y las capas de realidad obligan a mantener “validado” dentro de lo que el sistema realmente ejecutó.

Sources