El estándar: Quic

Podcast de Redes de Eduardo Collado

En Mayo de 2020 ya hablamos de Quic en este podcast, y justo un año después ya tenemos Quic estándar, totalmente estandarizado gracias a un trabajo que ha llevado 6 largos años y que ha tenido que ser dividido en 4 RFCs, aunque la que se a a llevar la gloria y que será la más recordada tiene pinta que va a ser la RFC 9000:

• RFC 8999: Version-Independent Properties of QUIC.
• RFC 9000: QUIC: A UDP-Based Multiplexed and SecureTransport.
• RFC 9001: Using TLS to Secure QUIC.
• RFC 9002: QUIC Loss Detection and Congestion Control.

La RFC 8999 cubre básicamente los aspectos independientes de la versión, la 9000 cubre el protocolo principal, por eso será la que se recordará más, la 9001 la seguridad de TLS y la 9002 los mecanismos de recuperación y prevención de pérdida de paquetes en Quic.

Es importante resaltar que hoy estamos hablando de Quic y no de HTTP/3 ya que todavía queda que se publique información no publicada.

Para empezar un poco con el repaso de Quic comentar algo que puede parecer una tontería y es que según la RFC 9000, en la página 10 el protocolo de transporte Quick es un nombre no un acrónimo de «Quick UDP Internet Connections«, pero siempre está bien que sepamos de donde viene originalmente el nombre, aunque no corresponda totalmente.

Quic funciona sobre UDP, lo cual, erróneamente, nos puede llevar a pensar que estaríamos hablando de un protocolo no confiable, que pudiera tener pérdidas de información, en fin, podemos pensar que Quic hereda las características de UDP, pero no es cierto.

Quic, como ya hablamos hace un año, tiene un control de transmisión muy completo con su handshake, la parte criptográfica, y dispone de un control de congestión que nada tiene que envidiar al de TCP.

Realmente el que Quic corra sobre UDP es por motivos prácticos, se podría haber desarrollado para correr sobre IP directamente, pero en Internet tenemos muchos dispositivos que sobre IP sólo esperan ver TCP o UDP y el desarrollar Quic sobre IP directamente habría supuesto la necesidad de modificar el código en muchos dispositivos intermedios, que seamos serios, no se van a actualizar por el motivo que sea.

Por otro lado tenemos los firewalls o balanceadores, y el no preparar un protocolo sobre TCP o sobre UDP haría que las configuraciones fueran más complejas y menos amigables.

En Quic tenemos un handshake muy optimizado. Si pensamos en cómo sería el hadnshake de TLS sobre TCP tendríamos el handshake del TCP y luego el handshake del TLS, pero en Quic no es así.

Como Quic integra TLS 1.3 sólo se hace un handshake, con lo que la conexión se establece mucho más rápida de lo se se hace en otros entornos.

En el caso de utilizar la función 0-RTT en HTTP/2 tendríamos que hacer el handshake de HTTP y el de TCP, pero en Quic con HTTP/3 que ya está integrado en Quic, tendremos un único handshake.

Recordad que 0-RTT básicamente lo que hace es recordar si se ha hablado antes para evitar ciertas comprobaciones.

El problema que tiene 0-RTT es que todavía tiene errores que dificultan su utilización:

• 0-RTT requiere claves de cifrado con lo que sólo se puede usar a partir de la segunda conexión.
• Un atacante podría reproducir los datos de 0-RTT y ejecutar el mismo comando varias veces, así que 0-RTT sólo podemos usarlo en métodos idempotentes que no afecten al estado del servidor.
• En Quic 0-RTT es vulnerable a ataques de amplificación de UDP, el propio atacante podría falsificar su dirección IP y hacer peticiones muy grandes. Para solucionar esto 0-RTT limita la cantidad de dato a enviar a un multiplo de 3 de los datos recibidos y esto es claramente insuficiente para la mayoría de las peticiones.

El 0-RTT va ser de mucha utilidad no en la navegación de usuarios sino en peticiones de API, una actividad que cada vez es más utilizada.

En las redes móviles es donde hay más pérdidas de paquetes y supuestamente Quic ahí debería de ser bastante eficiente gestionando estas conexiones.

En TCP si hay un corte o pérdida e datos, estos se solicitan de nuevo mientras se bloquea la conexión y se reordenan para volver a tener los segmentos completo.

Sin embargo en Quic no tenemos bloqueos ya que Quic es capaz de diferenciar diferentes streams de información. Esto es muy útil para cargas incrementales de jpeg progresivos, java scripts, etc…

Sin embargo es muy poco probable que la pérdida de paquetes se produzca sólo en un stream, cuando vas con el móvil y pierdes señal afecta a todo, no sólo a un stream, con lo que todos estos mecanismos de recuperación ante pérdidas de información parcial pues no serían muy útiles.

La evolución de como se han sufrido las pérdidas de información ha sido curiosa, al principio se perdía información por medio poco fiables y había que tener un control de la información muy fuerte, como en X.25, pero a día de hoy las redes son bastante confiables y lo que te puede pasar es que el móvil se te quede sin cobertura al pasar por un túnel.

Aquí os dejo el capítulo sobre HTTP/3 y QUIC de hace un año.

HTTP/3 y QUIC