QUIC: El protocolo experimental de Google ¿un riesgo?

¿Qué es QUIC (IETF)?

 

QUIC o Quick UDP Internet Connections es un protocolo de red cifrado que trabaja en la capa de transporte (4), todavía experimental, desarrollado básicamente para agilizar el acceso web, hacerlo más eficiente y seguro, controlando la congestión y disminuyendo la latencia en la comunicación. Por defecto está habilitado en Google Chrome. Microsoft Edge, Firefox y Opera también lo soportan.

¿Cuáles son las ventajas del QUIC protocol?

Ya se han puesto de relieve algunas características y ventajas importantes de QUIC, pero a continuación detallamos en qué consiste otra serie de mejoras. Para hacerlo tomaremos como referencia al protocolo TCP, el cual juega un papel importante como precursor del concepto del nuevo protocolo de transporte pero queda algo por debajo del protocolo de Google, tal y como aclaran las siguientes ventajas de QUIC.

Rápida conectividad

La razón principal del rendimiento superior de QUIC frente a TCP es su rapidez en establecer conexión. Aun sin un cifrado SSL/TLS, la conexión a través del protocolo de transporte clásico recorre más pasos con el handshake de tres vías (three-way handshake) que la solución de Google basada en UDP. QUIC inicia una conexión con un único paquete (o dos paquetes si se trata de la primera vez que se establece la conexión) y transmite en ellos todos los parámetros TLS o HTTPS necesarios. En la mayoría de los casos, un cliente puede enviar datos directamente a un servidor sin que este tenga que enviar una respuesta, mientras que TCP debe obtener y procesar la confirmación del servidor.

Permite conexiones multiplexadas

TCP recurre a los puertos TCP y a las direcciones IP de los sistemas conectados para identificar las conexiones. Así, no es posible que un cliente se comunique con el servidor a través de varios puertos en una única conexión. El QUIC protocol soluciona la situación de manera diferente recurriendo a una identificación de la conexión de 64 bits y a diferentes “streams” para transportar los datos en una conexión. Las conexiones QUIC no están vinculadas a un puerto específico (en este caso puerto UDP), a una dirección IP o a un punto final determinado. La modificación de los puertos y de las direcciones IP es, como consecuencia,igual de posible que las mencionadas conexiones multiplexadas.

Adjudicación de números de secuencia únicos

Cada segmento de datos de una conexión QUIC obtiene un número de secuencia propio independientemente de que se trate de un segmento original o de uno reenviado. TCP no establece esta distinción, por lo que un host tampoco puede determinar el estado de una secuencia. Solo la utilización de una extensión de cronosellador (timestamp) permite al protocolo de transporte clásico dicha distinción. El marcado continuo de los paquetes es, por lo tanto, una ventaja, ya que permite una estimación más precisa del tiempo de recorrido del paquete (RTT, Round Trip Time).

Corrección de errores hacia delante

Los paquetes que se pierden representan un gran problema en el transporte de datos con QUIC. Gracias a un sistema de corrección de errores basado en XOR no es necesaria una transmisión nueva de los datos, pues estos pueden reconstruirse en cualquier momento con ayuda de paquetes FEC (Forward Error Correction), copias de seguridad de los paquetes originales para un grupo de datos. La corrección de errores no funciona, sin embargo, cuando faltan varios paquetes de un grupo de datos.

Control de sobrecargas (packet pacing)

TCP siempre intenta enviar datos lo más rápido posible, lo que contribuye a la velocidad de las conexiones pero va ligado también a cierto índice de pérdida. Si un paquete se pierde, se inicia una nueva transferencia (TCP fast retransmit). Para ello, TCP disminuye de manera transitoria la ventana de visualización, lo que tiene como consecuencia que los datos se transmitan en impulsos. El QUIC protocol contrarresta tales picos de carga con ayuda del llamado packet pacing. Este procedimiento se ocupa de que la tasa de transferencia se limite automáticamente, de manera que se eviten las sobrecargas en conexiones con un ancho de banda reducido. No obstante, esta técnica no es nueva, puesto que algunos núcleos de Linux utilizan este método para el protocolo TCP.

Autenticación y codificación

La seguridad ha sido un aspecto esencial desde el principio en la planificación y concepción de QUIC y, en el transcurso del proceso, los desarrolladores se han ocupado de uno de los mayores problemas de TCP: el encabezado de los paquetes enviados está redactado como texto simple y puede leerse sin necesidad de autenticación. Los ataques man in the middle y las manipulaciones de paquetes (como, por ejemplo, la de los números de secuencia), no son algo extraordinario. Los paquetes QUIC siempre se autentifican y en general suelen estar cifrados (incluso la carga útil o payload). Asimismo, la autenticación por parte del destinatario hace que las partes del encabezado que no se presentan de forma cifrada estén protegidas de la inyección y la manipulación.

Independencia del hardware

Otra de las grandes ventajas de QUIC frente a TCP es que el protocolo de Google no depende del sistema. Mientras que los dispositivos y plataformas deben soportar el protocolo TCP para posibilitar la comunicación, el soporte de QUIC solo es necesario en las capas de aplicación. Por eso, en principio son las empresas de software las que integran el protocolo sin depender de los fabricantes de hardware. Hasta la fecha son sobre todo aplicaciones de Google como los servidores de Google, Chromium o Chrome, las que disponen de implementaciones para QUIC, pero con el navegador Opera, el software de servidores Caddy y los productos de balanceo de carga y de servidores web de LiteSpeed Technologies también existen aplicaciones de terceros que permiten conexiones a través del nuevo protocolo de transporte.

Desventajas del QUIC protocol

La posibilidad de que QUIC se utilice cada vez más en el futuro se debe sobre todo al compromiso del IETF. Gracias a los ajustes en los estándares generales efectuados desde la creación del grupo de trabajo en 2016, el protocolo ha pasado de estar fuertemente adaptado a Google a convertirse en un protocolo de red general que está ganando en relevancia. No obstante, el proceso de optimización todavía no ha concluido: el equipo de QUIC sigue ocupándose de los problemas existentes para los que es necesario encontrar las soluciones adecuadas.

En concreto el tema de la seguridad, uno de los más importantes en el desarrollo del protocolo, plantea grandes debates. Mientras que la autenticación y el cifrado se ocupan, sin duda, de un transporte de datos seguro, estos dos factores también son responsables de una desventaja decisiva de QUIC: debido a que los encabezados del paquete contienen menos información con texto claro que en las conexiones TCP, tareas como la solución de problemas, la regulación del tráfico ola gestión de redes en conexiones QUIC se complican notablemente. Tanto los operadores de red como los fabricantes de firewalls y de otras cajas intermedias (middleboxes) se encuentran con dificultades para garantizar la calidad de sus servicios.

Otro problema del protocolo QUIC es que el control automático de las sobrecargas en las conexiones con un amplio ancho de banda puede provocar en algunos casos una peor tasa de transferencia.

Problemas en la seguridad de la red con el protocolo QUIC

El dolor de cabeza con QUIC es que al ser un protocolo experimental, está todavía en desarrollo, lo están reescribiendo constantemente y no es soportado totalmente por los appliances de seguridad, por ende estos dispositivos tendrán problemas a la hora de registrar ese tráfico correctamente, emitir reportes avanzados, filtrarlo, etc. Y esto crea un gran hueco de seguridad en muchas organizaciones.

Algunos dispositivos de seguridad perimetral pueden bloquearlo o permitirlo pero no pueden tratarlo de la misma forma en que se tratan a los paquetes HTTP y HTTPS, recuerda que es básicamente un paquete UDP, por ejemplo: este tráfico no va a ser revisado por todos los módulos como Web Filtering, Content Filtering, Deep Packet Inspection, Sandboxing, Malware Scanning y reportes avanzados. En este caso el dispositivo de seguridad perimetral no reconoce el tráfico QUIC como tráfico WEB, ve un paquete genérico UDP en el registro del módulo firewall y en la mayoría de los casos tendrá problemas para determinar a qué página web se realizó la conexión, en qué categoría está esa página, aplicar Traffic Shaping y por supuesto no puede bloquear el acceso a la página web por usuario, por IP o por mac address, dependiendo del método que esté utilizando el dispositivo.

De TCP a QUIC

Se espera que los sitios web y los servicios que utilizan conexiones cifradas puedan utilizar QUIC y experimentar un aumento de velocidad particularmente considerable.

Sin embargo, migrar de TCP a QUIC no será una tarea fácil, ya que hay una gran cantidad de servicios existentes que están construidos alrededor del protocolo anterior.


Agregar un comentario