Summary

  • En un datagrama candidato de al menos 21 bytes, que los últimos 16 bytes coincidan con un token asociado a la conexión obliga al receptor a terminarla; no autentica al emisor.
  • No identifica por qué desapareció el estado, qué backend fue responsable ni cuándo ocurrió la pérdida.
  • La investigación necesita conservar junto al paquete la ruta, la época de clave y la última evidencia de estado correcto.

Un balanceador desvía el tráfico a otro backend. Instantes después, el cliente recibe un paquete cuyos últimos dieciséis bytes coinciden con un token conocido y abandona de inmediato la conexión. La señal determina correctamente la acción del cliente, pero no basta para afirmar que «el servidor perdió el estado».

El RFC 9000, sección 10.3, reserva el restablecimiento sin estado para un extremo que no puede acceder al estado de la conexión. En QUIC v1, con las funciones AEAD definidas, un paquete de cabecera corta de menos de 21 bytes nunca es válido y debe descartarse. A partir de 21 bytes, el receptor compara los últimos 16 bytes con los tokens asociados a identificadores de conexión activos. Una coincidencia provoca el cierre inmediato, pero no autentica al emisor ni transporta una causa, una identidad del servidor de aplicación o el momento de la pérdida de estado.

El diseño busca que el paquete resulte difícil de distinguir de uno normal con cabecera corta. Los bytes de apariencia aleatoria ocultan la señal a observadores y las restricciones de tamaño evitan respuestas que alimenten bucles. Por ello, una captura pasiva tampoco puede etiquetar con seguridad cualquier paquete parecido como restablecimiento.

La sección 10.3.1 describe la construcción del token y permite derivarlo de una clave estática y un identificador de conexión. Así, una capa de enrutamiento sin el estado completo puede producir un token coincidente. Sin embargo, el token no revela al cliente qué versión de clave, instancia o cambio operativo lo generó.

La sección 10.3.2 establece un límite crítico: identificadores distintos no deben compartir token. Una colisión o reutilización incorrecta puede generar un falso positivo y terminar una conexión sana. Reconocer correctamente la coincidencia no demuestra que la asignación y conservación del token fueran correctas en toda la infraestructura.

Las consideraciones de seguridad de la sección 21.11 mantienen esa frontera. La exposición o gestión deficiente de un token puede facilitar una inyección. Detectar una coincidencia de token no atribuye por sí solo un ataque, no exime al operador y no demuestra que una conmutación preservara el estado.

Como recomendación editorial, el expediente de incidente debe conservar: hora de observación; tupla de direcciones y puertos; longitud y forma del paquete; huellas del CID y del token en lugar de divulgar los valores; secuencia correspondiente; backend emisor y época de clave; decisión del balanceador; último paquete correcto; eventos de despliegue o conmutación; y evidencia independiente de presencia o ausencia en el almacén de estado.

Esa cronología permite separar mecanismos que producen el mismo resultado para el cliente: reinicio, expulsión del estado, vencimiento, enrutamiento erróneo, réplica atrasada, rotación de clave incoherente, colisión de token o inyección. El restablecimiento explica por qué el cliente cierra ahora; la evidencia operativa explica por qué ya no había estado disponible.