¿Qué es QUIC Flood? Ataques DDoS contra HTTP/3 y cómo mitigarlos

QUIC Flood es una familia de ataques DDoS que explota el protocolo QUIC — la base de HTTP/3 — para presionar CPU, memoria, conexiones y aplicaciones. A diferencia de ataques clásicos como el SYN Flood sobre TCP, los floods QUIC operan sobre UDP con cifrado integrado en user-space, lo que cambia cómo los dispositivos de seguridad observan y controlan el tráfico.

QUIC, TLS 1.3 y HTTP/3: arquitectura y visibilidad de seguridad

QUIC fue estandarizado por el IETF en la RFC 9000, publicada en 2021. La RFC 9001 define la integración de TLS 1.3 con QUIC, y la RFC 9114, publicada en 2022, define HTTP/3 sobre QUIC. QUIC fue desarrollado inicialmente por Google, pero la versión IETF es una estandarización propia con una especificación distinta.

La integración de transporte y cifrado en QUIC tiene implicaciones directas para la seguridad. En el stack TCP/TLS, el handshake TCP ocurre antes que TLS — lo que permite que los dispositivos stateful observen el establecimiento de la conexión a nivel de transporte antes de que fluya cualquier dato cifrado. En QUIC, el handshake de transporte y el handshake criptográfico ocurren de forma integrada. El stack QUIC — incluido TLS — suele ejecutarse en user-space; el kernel proporciona el socket UDP pero no tiene visibilidad sobre las estructuras internas del protocolo QUIC.

Esto no hace que el tráfico QUIC sea completamente opaco para toda finalidad de control. Los dispositivos de red y firewalls pueden observar y controlar atributos como direcciones IP, puertos, tamaño de datagrama, PPS, duración y patrones de flujo. Los paquetes QUIC Initial tienen campos identificables y pueden ser procesados parcialmente por herramientas especializadas. Lo que requiere terminación QUIC y TLS es la inspección íntegra de HTTP/3 — solicitudes, cabeceras, cuerpo y lógica de aplicación — y las políticas basadas en el contenido.

La siguiente tabla resume las propiedades relevantes para la seguridad de los tres stacks:

Sin terminación QUIC y TLS, los dispositivos de seguridad no pueden inspeccionar íntegramente el contenido HTTP/3. Aún así, pueden aplicar controles L3/L4, análisis de flujos, limitación de tasa, filtrado de paquetes malformados y políticas por dirección, prefijo, ASN, puerto o comportamiento.

¿Cómo funciona un QUIC Flood?

El QUIC Flood explota características del protocolo para presionar los recursos del servidor de maneras que las herramientas diseñadas exclusivamente para TCP pueden no detectar ni controlar. Los vectores varían en mecanismo, recurso objetivo y dificultad de mitigación — y frecuentemente se combinan en campañas sofisticadas.

El recurso presionado depende del vector: un flood de UDP/443 presiona banda y PPS; un flood de Initial packets puede presionar CPU de parsing y derivación de claves; el abuso de streams HTTP/3 presiona la lógica de aplicación. El efecto real depende de la implementación QUIC del servidor, la configuración de defensas, la capacidad de la infraestructura y el perfil específico del ataque.

Principales vectores de ataque contra QUIC y HTTP/3

Flood de UDP/443

El vector más directo: inundar el servidor con datagramas UDP en el puerto 443. Cuando el tráfico UDP/443 alcanza el stack o la implementación QUIC, el destino puede necesitar clasificar y procesar parte de los datagramas para identificar paquetes válidos o aplicar reglas de descarte. Controles de red, firewall, balanceador de carga, mitigación upstream, XDP/eBPF o filtros de borde pueden filtrar parte de ese tráfico antes de que llegue al servidor de aplicación. A altos volúmenes de PPS, ese procesamiento puede presionar la CPU incluso cuando parte del tráfico se descarta antes de alcanzar la implementación QUIC.

Bloquear completamente UDP 443 como respuesta inmediata resuelve el flood, pero elimina HTTP/3 para todos los usuarios legítimos — un trade-off que la mayoría de los operadores no puede aceptar durante todo un incidente. Controles más granulares, como rate limiting por prefijo, filtrado de paquetes malformados y validación de versión, permiten reducir el impacto sin eliminar el servicio.

QUIC Initial flood

El atacante envía grandes volúmenes de QUIC Initial packets. Un flood de QUIC Initial puede presionar CPU, parsing, validación de tokens, buffers y recursos de handshake. El impacto depende de cuánto trabajo realiza la implementación antes de validar la dirección del cliente y de aplicar límites de tasa.

Las implementaciones robustas pueden aplicar validación de dirección y limitar recursos antes de mantener estado completo. Aun así, floods de Initials válidos pueden generar coste en parsing, derivación de claves iniciales, generación de Retry, timers o buffers — especialmente cuando provienen de botnets con IPs reales que completan la validación.

Los ataques con IP spoofed y los ataques de botnets con IPs reales tienen características diferentes: en el primer caso, el mecanismo de Retry puede reducir el trabajo antes de la validación; en el segundo, la validación se completa y el coste recae sobre las etapas posteriores del handshake.

Paquetes malformados o de versión inválida

Enviar paquetes QUIC con contenido malformado, campos inválidos o versiones no soportadas obliga al servidor a intentar parsear y clasificar cada paquete antes de descartarlo. A altos volúmenes, esto puede presionar la CPU de parsing. Los dispositivos que pueden identificar y filtrar estos paquetes antes del procesamiento más profundo reducen ese coste.

HTTP Flood sobre HTTP/3

Un HTTP Flood transportado via HTTP/3 sigue la misma lógica que cualquier ataque de capa de aplicación: solicitudes sintácticamente válidas que agotan CPU, base de datos, llamadas a terceros o lógica de negocio. Este vector requiere terminación QUIC/TLS para una inspección y control efectivos.

La diferencia respecto al HTTP Flood sobre TCP es que, sin terminación QUIC, los dispositivos intermedios no pueden inspeccionar el contenido de la solicitud ni aplicar políticas de WAF, rate limiting por ruta o protección de APIs.

Abuso de streams HTTP/3

QUIC permite la multiplexación de múltiples streams sobre una única conexión. Un cliente puede abrir un gran número de streams simultáneos, cada uno generando coste de procesamiento. El protocolo define límites de streams via frames MAX_STREAMS, pero el coste de gestionar los límites y de procesar streams hasta ese límite puede ser relevante bajo ataque.

Los límites de streams por conexión deben configurarse con atención al perfil de uso legítimo — valores demasiado restrictivos pueden impactar a aplicaciones que dependen de alta concurrencia de streams.

0-RTT replay

El 0-RTT permite a un cliente reutilizar información de una sesión TLS anterior — normalmente mediante PSK (Pre-Shared Key) o tickets de sesión — para enviar datos antes de la finalización completa del handshake. Los tokens de validación de dirección y los tickets/PSK para reanudación de sesión son mecanismos distintos.

Los datos 0-RTT pueden estar sujetos a replay en condiciones específicas. Las aplicaciones deben aceptarlos solo en operaciones idempotentes o implementar medidas propias de anti-replay. No es correcto tratar el 0-RTT replay como falsificación trivial de tráfico por un tercero sin claves — un adversario sin acceso a las claves de sesión no puede forjar paquetes 0-RTT válidos.

Desde el punto de vista de los ataques, el 0-RTT puede ser usado por clientes con tickets válidos para enviar solicitudes costosas antes de la validación completa del handshake, amplificando potencialmente el coste por conexión para operaciones no idempotentes.

Connection ID y migración

El Connection ID (CID) identifica una conexión QUIC y permite que persista durante cambios de dirección IP. Los CIDs pueden rotarse o emitirse según las políticas de los endpoints; durante el handshake inicial, los valores de CID pueden ser controlados por el cliente.

El CID no es una identidad confiable del usuario y no debe ser la única señal para las políticas de seguridad. Debe usarse como señal complementaria junto con IP, prefijo, ASN, reputación, identidad, sesión, credencial, token, endpoint y comportamiento.

Las migraciones QUIC normalmente requieren validación de camino via PATH_CHALLENGE y PATH_RESPONSE antes de enviar datos significativos al nuevo camino. Las migraciones excesivas o con patrón anómalo pueden ser señal de intento de evasión de controles por IP y deben monitorearse.

Validación de dirección, Retry y límites anti-amplificación

Validación de dirección y Retry

La validación de dirección, definida en la RFC 9000 Sección 8, es el mecanismo por el cual un servidor confirma que la dirección de origen de un cliente es alcanzable antes de invertir recursos significativos en el handshake.

Retry es un mecanismo opcional de validación de dirección. El servidor puede responder a un Initial packet con un Retry packet que contiene un token. El cliente debe incluir ese token en un nuevo Initial packet para demostrar alcanzabilidad. Un cliente con IP spoofed nunca recibe el Retry y no puede completar el ciclo.

Retry es opcional: no se emite automáticamente para todo Initial. Puede usarse para exigir prueba de alcanzabilidad antes de invertir más recursos, pero su uso debe equilibrar protección, coste operacional e impacto de latencia en el establecimiento de conexiones. La tokenización y validación del Retry tienen coste; bajo un flood intenso de Initials, el propio procesamiento de Retry puede ser relevante.

Otros mecanismos también pueden contribuir a la validación de dirección, como tokens emitidos en conexiones anteriores.

Cuando Retry y tokens estén habilitados, monitorea su emisión, aceptación, rechazo y expiración como indicadores adicionales de salud y presión sobre el handshake.

Límite anti-amplificación

Antes de validar la dirección del cliente, QUIC limita la cantidad de datos que un servidor puede enviar en respuesta al tráfico recibido. Como regla general, antes de la validación el endpoint no debe enviar más de tres veces los bytes recibidos en ese camino. Este límite reduce la asimetría explotable en ataques de reflexión sobre QUIC.

Además, los datagramas que transportan un QUIC Initial deben tener al menos 1.200 bytes, conforme a la RFC 9000. Un datagrama que transporta un QUIC Initial por debajo de 1.200 bytes debe ser descartado por el servidor conforme a las reglas de la RFC 9000. Este requisito reduce el factor de amplificación disponible: el atacante debe enviar al menos 1.200 bytes para que el servidor procese un Initial, lo que limita la asimetría en comparación con protocolos sin requisito de tamaño mínimo.

En conjunto, el límite anti-amplificación y el requisito de tamaño mínimo reducen el potencial de reflexión/amplificación, pero no eliminan ataques de IPs reales, floods de alto PPS o presión de CPU sobre parsing y handshake. Los operadores deben aplicar limitación de tasa, filtrado anti-spoofing y controles de capacidad como complemento.

Telemetría y detección de anomalías en QUIC

La detección eficaz de anomalías en QUIC requiere telemetría específica del protocolo — las métricas TCP tradicionales no capturan señales QUIC relevantes. Las alertas deben calibrarse con baseline histórico y segmentarse por servicio, región, versión de cliente, red de acceso y perfil de tráfico. Un cambio puede indicar un ataque, un cambio en la adopción de HTTP/3, un problema de compatibilidad o una variación legítima de demanda.

Mitigación de QUIC Flood en capas

Una arquitectura de mitigación eficaz para QUIC combina controles en múltiples capas. Ningún control aislado resuelve todos los vectores.

Mitigación L3/L4 para UDP

• Limitación de tasa por IP, prefijo, ASN y puerto — aplicable al tráfico UDP sin necesidad de terminación QUIC.
• Filtrado de paquetes malformados o con campos inválidos identificables sin terminación TLS.
• Descarte de datagramas que transportan QUIC Initial por debajo de 1.200 bytes, conforme a las reglas de la RFC 9000. El coste de este control depende de dónde se aplique la validación — por ejemplo, en el edge, en el balanceador de carga, en el kernel via XDP/eBPF o en la implementación QUIC.
• Filtrado de versiones QUIC no soportadas antes del procesamiento más profundo.
• BCP 38/uRPF en upstream para reducir la viabilidad del IP spoofing en el origen.
• Limitación de tasa de Initial packets por ventana de tiempo, por origen o globalmente.

Los controles L3/L4 protegen contra floods volumétricos y algunos Initial floods, pero no inspeccionan el contenido HTTP/3 ni detectan abuso de streams o HTTP Flood.

Validación de dirección, Retry y tokens

• Habilitar la validación de dirección en la implementación QUIC, con Retry cuando sea adecuado al perfil de latencia y compatibilidad.
• Utilizar tokens de conexiones anteriores para reducir la latencia de validación en clientes conocidos.
• Cuando Retry y tokens estén habilitados, monitorear su emisión, aceptación, rechazo y expiración como indicadores adicionales de salud y presión sobre el handshake.
• Evaluar el coste del propio procesamiento de Retry bajo floods intensos y calibrar límites upstream como complemento.

Limitación de conexiones, streams y solicitudes

• Límites de conexiones por IP, prefijo y globalmente — para controlar el coste total de handshakes pendientes.
• Límites de streams HTTP/3 por conexión — configurados conforme al perfil de uso legítimo.
• Rate limiting por ruta HTTP/3, identidad, token, tenant y comportamiento — aplicable tras terminación QUIC/TLS.
• Límites de 0-RTT por cliente, sesión y operación — aceptar solo para operaciones idempotentes.

Terminación QUIC/TLS y controles L7

Cuando QUIC y TLS se terminan en el edge, los controles de capa 7 pueden aplicarse a las solicitudes HTTP/3: WAF, rate limiting por endpoint, protección de APIs, detección de bots y políticas por identidad y comportamiento. Esto normalmente es necesario para la inspección íntegra de HTTP/3 y para responder a vectores como HTTP Flood y abuso de streams.

Sin terminación, aún es posible aplicar los controles L3/L4 descritos anteriormente y reducir una parte significativa del riesgo — pero no todos los vectores.

Observabilidad y ajuste de políticas

• Telemetría separada para UDP/443 y QUIC — independiente de los paneles TCP.
• Correlación entre métricas de red (PPS, banda, descartes) y métricas de aplicación (latencia, errores, coste por endpoint).
• Ajuste continuo de políticas con base en el baseline por servicio, región y período.
• Pruebas periódicas del proceso de mitigación en ejercicios controlados.

Consideración sobre fallback TCP

Los operadores pueden optar por reducir o suspender temporalmente QUIC para segmentos o perfiles de riesgo específicos durante incidentes. Esto puede dirigir el tráfico a HTTP/2 sobre TCP, donde las herramientas de inspección stateful son más maduras. Este comportamiento de fallback puede ocurrir en navegadores y clientes que soportan Alt-Svc, pero no debe tratarse como garantizado. Los cambios deben probarse, monitorizarse y tener criterios de rollback — pueden afectar el rendimiento, la compatibilidad y la experiencia del usuario.

Una arquitectura distribuida de edge o scrubbing puede ayudar a absorber y filtrar tráfico antes del origen. Los resultados dependen de la topología, cobertura, capacidad, configuración, perfil del ataque e integración con los protocolos publicados.

Errores comunes al proteger QUIC y HTTP/3

Bloquear UDP 443 como respuesta inmediata a cualquier tráfico QUIC anómalo: esto elimina HTTP/3 para todos los usuarios legítimos. Usa controles granulares — filtrado de paquetes inválidos, limitación de tasa por prefijo, validación de tamaño mínimo — como primeras respuestas, preservando el servicio mientras se reduce el impacto.

Asumir que las protecciones de SYN Flood TCP se aplican automáticamente a QUIC: los SYN Cookies no tienen equivalente directo en todas las implementaciones QUIC. Verifica explícitamente si tu implementación tiene validación de dirección via Retry habilitada y qué mecanismos son configurables.

No diferenciar telemetría UDP/443 de TCP/443: los ataques QUIC son invisibles en dashboards enfocados exclusivamente en TCP. Configura recopilación de telemetría separada para UDP/443 y métricas específicas del protocolo QUIC.

Tratar la terminación QUIC como única defensa posible: la terminación es necesaria para la inspección L7 completa, pero los controles L3/L4, la limitación de tasa, la validación de dirección y el filtrado de paquetes malformados son efectivos para vectores volumétricos y de Initial flood sin requerir terminación.

Usar Connection ID como único identificador para políticas de seguridad: el CID no es una identidad confiable. Úsalo como señal complementaria, no sustituto de IP, prefijo, identidad, sesión y comportamiento.

No calibrar alertas con baseline por servicio y región: los umbrales globales generan falsos positivos y pueden no detectar anomalías concentradas en subconjuntos de tráfico. Segmenta el baseline por aplicación, endpoint, versión de cliente y período.

Preguntas frecuentes

¿QUIC es intrínsecamente más vulnerable a DDoS que TCP por usar UDP? No necesariamente. QUIC fue diseñado con mecanismos de defensa específicos — validación de dirección, Retry, límite anti-amplificación y requisito de tamaño mínimo para Initials. El principal desafío es que las herramientas y procesos desarrollados históricamente para TCP necesitan adaptarse o complementarse para observar y controlar el tráfico QUIC de forma eficaz.

¿Cómo difiere el QUIC Flood de los ataques low and slow como Slowloris? Son vectores diferentes. Slowloris mantiene conexiones TCP abiertas con transmisión mínima, agotando los pools de conexión. Los floods de QUIC Initial presionan la CPU de parsing y los recursos de handshake; el HTTP Flood sobre HTTP/3 presiona la aplicación; los floods volumétricos de UDP presionan banda y PPS. Las contramedidas son distintas para cada vector.

¿Por qué es importante el requisito de 1.200 bytes para los Initial packets? Un datagrama que transporta un QUIC Initial por debajo de 1.200 bytes debe ser descartado por el servidor conforme a la RFC 9000. El requisito reduce la asimetría de tamaño que podría favorecer los ataques de reflexión. Al exigir un datagrama mayor para transportar un Initial, el protocolo eleva el coste de banda del emisor y limita la relación entre bytes enviados por el atacante y bytes que el servidor puede transmitir antes de validar la dirección. La regla no elimina el coste de procesamiento de floods de alto PPS, parsing, derivación de claves, validación de tokens, buffers o presión de handshake.

¿Es Retry suficiente para proteger contra los Initial floods? Retry puede reducir el trabajo realizado antes de la validación de dirección, especialmente contra ataques con IP spoofed. No resuelve directamente los ataques de botnets con IPs reales que completan la validación. El propio procesamiento de Retry tiene coste; bajo floods intensos, complementar con rate limiting upstream es importante.

¿Cómo gestionar el 0-RTT de forma segura? Acepta datos 0-RTT solo en operaciones idempotentes. Implementa medidas de anti-replay adecuadas en la aplicación. Monitoriza la proporción de aceptación y rechazo de 0-RTT como parte de la telemetría de seguridad. Los datos 0-RTT no pueden ser falsificados por terceros sin las claves de sesión — el riesgo de replay es para clientes que tienen tickets válidos, no para adversarios externos sin claves.

¿Cómo distinguir un flood QUIC de un aumento legítimo en la adopción de HTTP/3? La distinción requiere baseline histórico por servicio y región. Los floods pueden presentar picos abruptos, fallos de validación, paquetes inválidos, aumento de CPU por handshake o crecimiento desproporcionado de intentos en relación a sesiones y solicitudes útiles. Sin embargo, las botnets distribuidas con IPs reales pueden parecerse al tráfico legítimo en algunas métricas individuales. El análisis debe correlacionar red, handshake, aplicación, identidad y comportamiento — ningún indicador aislado es concluyente.

En entornos que usan validación de dirección observable, el crecimiento legítimo tiende a mantener tasas de finalización compatibles con el baseline. Aun así, la interpretación debe considerar la política de Retry adoptada, el uso de tokens, redes móviles, NATs, versiones de cliente y cambios de configuración que pueden afectar las métricas de finalización independientemente de un ataque.

Referencias técnicas

• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 9001 — Using TLS to Secure QUIC
• RFC 9114 — HTTP/3
• RFC 9002 — QUIC Loss Detection and Congestion Control
• RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks (BCP 38)
• RFC 3704 — Ingress Filtering for Multihomed Networks

Cómo implementar en Azion

Azion puede componer una estrategia de protección para aplicaciones que publican QUIC y HTTP/3, conforme a los productos contratados, los protocolos habilitados y las políticas configuradas.

1. Controles de borde para UDP y QUIC: políticas de red, limitación de tasa y mecanismos de mitigación pueden ayudar a reducir el tráfico anómalo antes de que llegue al origen.

2. Terminación y protección de aplicación: cuando QUIC, TLS y HTTP/3 se terminan en el edge, los controles de capa 7 pueden aplicarse a las solicitudes, incluyendo políticas de seguridad, limitación de tasa y protección de APIs, conforme a la configuración del entorno.

3. Controles de conexión y comportamiento: validación de clientes, límites de conexión, límites de solicitudes y análisis de comportamiento pueden ayudar a reducir la exposición a floods de handshake, abuso de streams y automatización maliciosa.

4. Observabilidad: logs, métricas y telemetría pueden apoyar la detección de anomalías, la investigación de incidentes y el ajuste de políticas de mitigación.

La cobertura efectiva depende de la arquitectura de la aplicación, de las implementaciones QUIC y HTTP/3 utilizadas, de los productos habilitados, de las políticas configuradas y del perfil del ataque.

Aprende más en la documentación de DDoS Protection de Azion.