Resumen

  • RFC 9853 incorpora a DTLS 1.2 y 1.3 una prueba de retornabilidad autenticada y cifrada. Una respuesta ligada al desafío puede permitir actualizar la dirección asociada a un Connection ID; un vencimiento conserva el vínculo anterior.
  • El resultado no demuestra identidad, autorización ni que la migración haya terminado. Un acta defendible separa disparador, amenaza, presupuesto de sondeo, respuesta, traslado del contexto, aceptación de aplicación, observación y reversión.

La primera unidad de datos que llega desde la dirección B es criptográficamente válida. Su CID encuentra una asociación creada cuando el par usaba la dirección A, y el epoch y el número de secuencia parecen correctos. Todavía no se ha respondido la pregunta práctica: ¿debe el receptor enviar a B la próxima respuesta de la aplicación?

El CID impide que la tupla UDP sea el nombre permanente de la sesión. Eso permite que un dispositivo móvil, una red con NAT o un equipo restringido conserve una asociación DTLS al cambiar de dirección. También abre una superficie de desvío. Una copia auténtica puede adelantarse por otra ruta; una dirección fuente manipulada puede convertir un servidor en amplificador contra un tercero.

RFC 9146 ya exigía tres condiciones antes de reemplazar la dirección: verificación criptográfica del registro, novedad según epoch y secuencia, y una estrategia que muestre que la nueva dirección recibe y procesa registros DTLS. La especificación dejaba sin fijar la tercera estrategia.

RFC 9853, publicada como Standards Track del IETF en marzo de 2026, completa ese punto para DTLS 1.2 y 1.3 y actualiza RFC 9146 y RFC 9147. Su Return Routability Check, RRC, ocurre antes de cambiar la asociación entre CID y dirección.

La secuencia expresa el límite. El CID selecciona estado; la capa de registros autentica el datagrama; RRC prueba una ruta; después el receptor decide alterar su estado local. Localizar contexto no valida el camino, y validar el camino no concede autoridad aplicativa.

Una negociación previa

RRC se anuncia mediante la extensión vacía rrc, código 61. El cliente que la ofrece también debe ofrecer connection_id; el servidor la confirma en ServerHello. El subprotocolo no puede usarse si ambos no intercambiaron la extensión correctamente.

No es la única opción posible. Ante un registro CID desde una dirección distinta, el receptor debería ejecutar RRC salvo que disponga de validación de aplicación. La opción Echo de CoAP, definida en RFC 9175, puede exigir frescura o alcance según recurso, método y política. La aplicación puede plantear una condición más rica que la mera posibilidad de retorno.

RRC usa el content type 27, return_routability_check, y tres mensajes: path_challenge, path_response y path_drop. Cada mensaje contiene una cookie de ocho octetos y 64 bits de entropía, autenticada y cifrada bajo el contexto de seguridad actual.

La cookie no identifica al titular de la ruta ni autoriza una acción. Vincula la respuesta con un desafío concreto. El registro operativo necesita conservar conexión, intento, destino, hora y expiración; una marca genérica de «validado» elimina el alcance de la prueba.

Limitar antes de confiar

Al detectar el cambio, el receptor detiene los envíos de aplicación en espera o limita todo lo dirigido a la dirección no validada al presupuesto antiamplificación: tres veces los bytes recibidos desde esa dirección, sin contar registros descartados.

Es un techo de exposición. Una petición pequeña con origen falsificado no debe habilitar una respuesta grande. El desafío protegido es pequeño; una víctima sin el contexto DTLS no puede descifrarlo ni devolver una respuesta válida, y el vínculo no cambia.

En el procedimiento básico, el iniciador crea una cookie impredecible, la coloca en path_challenge, envía el mensaje a la nueva dirección y activa T. El par verifica el desafío y repite la cookie en path_response. Solo la coincidencia recibida permite actualizar la dirección. Si T vence, no se actualiza.

El sondeo puede tolerar pérdidas sin perder sus límites. Los desafíos adicionales deberían viajar en paquetes distintos y con cadencia; todos deben llevar datos aleatorios. A falta de reglas específicas, puede enviarse uno por RTT hasta agotar el presupuesto. Por cada desafío válido, el par responde exactamente una vez y a la dirección desde la que llegó. RRC no descubre el PMTU de la ruta inversa.

T también forma parte del veredicto. Con información externa del RTT activo debería equivaler a tres RTT; sin esa información, un segundo es el valor recomendado, salvo perfil de despliegue distinto. Vencer significa que la evidencia no llegó en la ventana elegida, no que el par haya desaparecido para siempre.

El camino anterior como testigo

La prueba básica reduce amplificación, pero un atacante fuera de ruta puede observar registros auténticos y enviar copias por un trayecto más rápido. Si la copia gana, parece una migración natural. Confirmar solo la ruta nueva podría convertir al atacante en intermediario.

La variante mejorada consulta primero la dirección previa. Si vuelve path_response por el camino todavía preferido, se conserva el vínculo. Si vuelve path_drop, ese camino funciona pero el par ya no lo prefiere, y entonces se prueba la dirección nueva. Si el sondeo antiguo vence, también se pasa a la prueba básica; nunca se migra por mero silencio.

Así se separan tres estados: silencio, abandono explícito y preferencia confirmada. La protección no es absoluta. Una ruta adversaria permanentemente más rápida puede ser indistinguible de una mejora del enrutamiento. Tráfico reciente en la ruta vieja o paquetes duplicados pueden alimentar heurísticas locales, pero no cambian lo que la cookie demuestra.

La especificación tampoco absorbe rebindings anidados. Si vuelve a cambiar la dirección durante una validación, una respuesta desfasada se descarta, el intento vence, el vínculo permanece y datos posteriores inician otra prueba. Reducir todo a «migración en curso» destruye la trazabilidad de cada candidato.

Retornabilidad no es identidad

Una prueba exitosa muestra que quien utiliza el contexto DTLS actual recibió un desafío protegido en la ruta ensayada y devolvió su valor dentro de la ventana. No prueba propiedad jurídica de la dirección, identidad humana o del equipo, autorización para moverse, ubicación, permanencia ni ausencia de vigilancia.

Tampoco prueba continuidad de la operación. Una orden CoAP puede requerir frescura adicional; un trabajo pendiente puede haber caducado; una petición quizá ya no sea idempotente; la política puede haber cambiado. Reanudar bytes es un resultado de transporte. Mantener el significado del trabajo es un resultado de aplicación.

La doctrina de Lu Heng sobre especificación inicial mínima, decisión futura localizada y adopción voluntaria ilumina la división: el estrato común contiene la evidencia determinista necesaria, mientras amenaza, alternativa aplicativa, momento y efecto quedan en manos de quienes ejecutan el código. The Policy Mirror sitúa el poder real en la transición que cambia la dirección y libera la salida, no en el código IANA ni en el identificador.

Señales que una luz verde oculta

RFC 9853 aconseja registrar fallos, varias respuestas al mismo desafío y sondeos frecuentes. Pueden indicar, respectivamente, suplantación o retorno roto, una carrera fuera de ruta, o inestabilidad subyacente aunque cada intento acabe bien.

DTLS 1.3 oculta el tipo de registro a observadores en ruta. En DTLS 1.2, un mensaje RRC que no vaya dentro de tls12_cid deja visible su tipo y un middlebox puede filtrarlo. Activar CID en ambas direcciones limita esa interferencia. DTLS 1.3 también permite renovar CIDs para no reutilizarlos entre rutas; DTLS 1.2 no puede pedir nuevos CIDs durante la sesión y resulta inadecuado cuando la correlación en multihoming es un riesgo real.

Un adversario ya situado en ruta sigue pudiendo perjudicar la conectividad o reenviar los desafíos al par verdadero. El registro TLS de IANA coordina el tipo 27, la extensión 61 y los tres mensajes iniciales; no certifica despliegue, identidad ni éxito del servicio.

Fuentes y límites

Las fuentes principales son RFC 9853 y su ficha de estado y erratas, RFC 9146, RFC 9147, RFC 9175, RFC 9000, el registro de IANA y RFC 8126. Describen contratos normativos, no adopción, rendimiento, conducta de proveedores, incidentes ni políticas de un operador concreto.

El registro independiente de erratas de RFC 9853 conserva el historial de correcciones consultado al cierre de la investigación.