Resumen

  • Un PATH_RESPONSE coincidente demuestra que quien recibió un PATH_CHALLENGE impredecible pudo devolver sus ocho bytes.
  • La evidencia no prueba identidad criptográfica, persona, dispositivo, cuenta, aplicación, autorización, MTU ni disponibilidad futura.
  • El registro operativo debe separar retorno de ruta, autenticación, resultado de aplicación y política de conservación.

El error típico comienza cuando un operador ve un PATH_RESPONSE coincidente y lo convierte en una aprobación duradera. RFC 9000 no define ese significado. La validación de ruta comprueba la alcanzabilidad de un par a través de una ruta de red. Se usa durante la migración de conexión y puede sondear una nueva dirección local antes de migrar, pero su condición de éxito no identifica al interlocutor.

El endpoint envía PATH_CHALLENGE por la ruta que desea validar. La información debe tener al menos 64 bits de entropía: un valor impredecible de ocho bytes. El receptor responde con PATH_RESPONSE y repite exactamente esos datos. La respuesta se envía por la ruta donde llegó el desafío. A la vez, quien inició el proceso acepta una respuesta coincidente que llegue por cualquier ruta de red. Esa distinción prueba la capacidad de retorno sin convertir el intercambio en autenticación; exigir una ruta concreta para la respuesta facilitaría un ataque de migración.

La validación tiene éxito cuando la respuesta contiene datos de un PATH_CHALLENGE anterior. Un ACK del paquete que transportó el desafío no sirve, porque un par malicioso podría falsificarlo. Se pueden enviar varios desafíos para tolerar pérdidas, pero no deberían colocarse varios en un mismo paquete. Ningún otro paquete o trama sustituye a la PATH_RESPONSE coincidente.

El resultado describe una condición de dirección y ruta en un instante. No demuestra la identidad de una persona, dispositivo, cuenta o principal de aplicación. Tampoco demuestra identidad criptográfica, autorización, resultado de negocio o disponibilidad posterior. Son límites operativos derivados de la estrecha condición de éxito de RFC 9000. Por eso, autenticación criptográfica, identidad de aplicación, autorización, resultado y retención deben registrarse en campos separados.

Validar la ruta no equivale a validar la MTU. Un desafío exitoso en un datagrama menor de 1200 bytes puede validar la dirección o la ruta sin demostrar compatibilidad con la MTU requerida. Para ello hace falta un desafío ampliado. Los datagramas PATH_RESPONSE normalmente se amplían al menos a 1200 bytes, pero nunca más allá del límite antiamplificación. El registro debe separar el resultado de validación de dirección del resultado de MTU y conservar tamaño de datagrama y estado antiamplificación.

La falta de una respuesta no declara el fracaso de inmediato. RFC 9000 recomienda un temporizador basado en tres veces la mayor PTO entre la ruta actual y la nueva, permitiendo varias PTO para que una sola pérdida no decida. La validación falla cuando el endpoint abandona el intento. Abandonar una ruta no termina necesariamente la conexión si queda otra ruta válida. El fracaso del sondeo significa que esa ruta candidata no es utilizable para esa conexión.

Un cambio de dirección, incluido el rebinding de NAT, exige validar la ruta salvo que esa dirección ya se hubiera validado. Esto no convierte la validación de QUIC en una técnica de atravesamiento NAT: RFC 9000 no aporta los mecanismos de sincronización necesarios. En una migración pueden cambiar capacidad y tiempos. QUIC reinicia el estado de control de congestión y RTT en lugar de reutilizar mediciones anteriores como garantías.

El registro operativo debería incluir identificador de ruta limitado a la conexión y resumen del desafío protegido para la privacidad; tiempos de desafío y respuesta; tupla local/remota probada; tamaño del datagrama; coincidencia y ruta de llegada. Debe distinguir validación de dirección y MTU, registrar antiamplificación antes y después, entradas PTO, motivo de abandono y resultado del temporizador. También debe anotar el disparador de rebinding o migración, evidencia de dirección validada previamente y rutas alternativas utilizables. Los resúmenes y la retención limitada son recomendaciones operativas, no requisitos de QUIC.

La deduplicación exige mantener cinco separaciones. TR-039 trata el presupuesto de amplificación antes de validar. TR-033 trata evidencia de retorno de DNS Cookie. TR-043 trata integridad de Retry. TR-040 separa connection IDs de identidad. TR-061 trata evidencia de NEW_TOKEN entre conexiones futuras. Ninguna debe confundirse con esta prueba de ruta.