Resumen

  • NEW_TOKEN es una credencial emitida por el servidor para validar una dirección en una conexión QUIC posterior; Retry se usa de inmediato.
  • La validación correcta es evidencia limitada sobre la dirección de origen según la política del servidor, no identidad de un cliente que regresa.
  • El registro debe separar token, autenticación del handshake, identidad de aplicación, autorización y resultado.

El panel de operaciones recibe un Initial con token y lo marca como “cliente recurrente”. La etiqueta parece razonable porque NEW_TOKEN puede evitar otro intercambio de validación de dirección. Sin embargo, responde a una pregunta mucho más estrecha: ¿puede el servidor aceptar ese token como evidencia suficiente de relación entre la dirección de origen y la conexión que lo recibió?

Durante una conexión, el servidor puede enviar bytes opacos en una trama NEW_TOKEN. El cliente los coloca en paquetes Initial de una conexión posterior. Es, por tanto, una credencial para el futuro. Retry es diferente: se emplea inmediatamente en el intento actual y no debe trasladarse a conexiones posteriores. NEW_TOKEN puede seguir siendo útil con el paso del tiempo, sujeto a expiración y aplicabilidad.

El servidor define el formato y las reglas. Debe poder comprobar la integridad, la autoridad del servidor emisor, el alcance de la versión QUIC, la expiración y si cambió la IP de origen. RFC 9000 no establece una vida útil universal, una tasa de reutilización ni una puntuación de confianza. El tiempo de emisión puede figurar explícitamente o permitir derivar la expiración. El cliente debería utilizar normalmente un token aplicable y no usado, y no reutilizarlo entre intentos distintos.

La prueba tiene límites claros. NAT puede reunir muchos equipos bajo una dirección; una dirección puede reasignarse; un dispositivo puede cambiar de red. El token permite al servidor correlacionar la conexión que lo emitió con otra posterior, y la reutilización puede aumentar la posibilidad de vinculación para quienes observan el camino. Un cliente que quiera romper esa continuidad puede descartar los tokens. Además, estos tokens no forman parte del handshake criptográfico. Validarlos no autentica al par y no demuestra continuidad de cuenta, identidad del dispositivo, autorización ni éxito de la solicitud.

Si cambió la dirección, el servidor debe mantener el límite antiamplificación aunque el token influya en la decisión de no enviar Retry. Un token válido no elimina las protecciones de transporte. Si es inválido, el tratamiento normal es considerar al cliente no validado y posiblemente enviar Retry, no convertir la invalidez en un fallo de identidad ni cerrar automáticamente la conexión. La integridad debe impedir adivinación, modificación y falsificación. La reproducción debe evitarse o limitarse. NEW_TOKEN necesita una validez más larga que Retry, pero no debería aceptarse varias veces; se fomenta el uso único cuando sea posible.

DNS sobre QUIC ofrece una ilustración de privacidad. Un token vinculado a una IP puede evitar un viaje adicional, mientras que un cambio de dirección que el cliente no advierte puede producir vinculación. La reanudación de sesión puede reducir el problema, no eliminarlo. La recomendación operativa es conservar el beneficio de transporte y registrar una prueba acotada.

El libro de evidencias debe separar emisor y autoridad del servidor; tipo de token; emisión y expiración; versión QUIC; identificador o resumen seguro para la privacidad; coincidencia de IP; decisión de primer uso o reutilización; resultado de validación; estado antiamplificación; decisión Retry; autenticación del handshake; identidad de cuenta o dispositivo; autorización; resultado de solicitud o transacción; política de retención. Los resúmenes y la retención limitada son controles operativos, no requisitos de QUIC.

La separación también evita confusiones con otros controles. La integridad de Retry se refiere a un paquete inmediato; la regla de tres veces limita el envío antes de validar; el Connection ID es un identificador de encaminamiento; 0-RTT plantea exposición a reproducción y compromiso de datos; DNS Cookie pertenece a otro protocolo. Ninguna dimensión reemplaza a NEW_TOKEN ni amplía su significado.