Cómo QUIC le ayuda a conectarse sin problemas a diferentes redes

Imagine que utiliza su teléfono en el trabajo para conectarse a una reunión virtual a través de la red WiFi de su oficina.

La videoconferencia va sobrada de tiempo pero usted tiene que llegar a una reunión con un cliente al otro lado de la ciudad. El moderador dice que sólo quedan 15 minutos, así que decide ver el resto mientras camina hacia su coche para ahorrar tiempo.

Cuando su teléfono sale del alcance de la red WiFi, se conecta automáticamente a una red celular (4G o 5G) y comienza a utilizarla en su lugar. En este proceso, todas las conexiones que tiene con el servidor de vídeo se cierran y se vuelven a cargar, lo que provoca interrupciones en el vídeo o que éste se congele si no se pueden volver a establecer las conexiones.

Esto se conoce como el "problema del aparcamiento" y es una de las ineficiencias del Protocolo de Control de Transporte (TCP) que su sucesor, QUIC, supera con la nueva función de "migración de conexiones".

Como detallé en mi primer post de esta serie, el protocolo QUIC se desarrolló para superar varias ineficiencias que el TCP tiene en torno a su diseño a prueba de futuro, incluyendo la privacidad, y mejoras en la seguridad. En este post, entraré en más detalles al respecto, centrándome en el problema cotidiano que he ilustrado anteriormente, y hablaré del futuro de la migración sin fisuras entre redes.

Como mencioné en mi anterior post, TCP no es el mejor protocolo para transferir sus datos de forma fiable a través de la Internet actual.

Esto se debe a la simplicidad de las conexiones TCP: fluyen entre dos direcciones IP y si una de esas direcciones IP cambia, por ejemplo, al trasladarse de red, ya no pueden utilizarse, como se muestra en la figura 1. (Nota: en la práctica, TCP también utiliza los llamados "puertos", y no todos los cambios de red provocan cambios de dirección IP, pero los conceptos son los mismos).

Aunque este proceso no es el fin del mundo (la nueva conexión funcionará perfectamente), es algo ineficiente. Después de todo, es sólo la dirección IP la que cambia, todo lo demás sobre la conexión TCP y su estado (por ejemplo, los parámetros de encriptación del protocolo de Seguridad de la Capa de Transporte (TLS)) podría conceptualmente permanecer igual. Estamos pagando una sobrecarga adicional innecesaria, por ejemplo, esperando a que se produzcan los nuevos apretones de manos TCP y TLS.

Para ayudar a resolver este problema, QUIC ya no se basa (únicamente) en las direcciones IP para definir las conexiones. En su lugar, asigna un número a cada conexión (el llamado ID de conexión o CID). De este modo, aunque cambie de red y de dirección IP, mientras siga utilizando el mismo CID, la conexión "antigua" seguirá siendo utilizable. Al servidor no le importa que la dirección IP haya cambiado: puede confiar en el CID para saber que se trata realmente de usted en esa nueva red. Esto significa que tanto el cliente como el servidor pueden mantener el estado de conexión existente y no hay sobrecarga de establecimiento de conexión, como se muestra en la figura 2.

Como tal, la migración de conexiones QUIC resuelve una ineficiencia de rendimiento prevalente en TCP. Sin embargo, si funcionara como se muestra en la figura 2, ¡sería fundamentalmente inseguro y terrible para la privacidad del usuario final!

El CID no sólo describe conexiones individuales, ¡sino que está (implícitamente) vinculado a dispositivos individuales y, por tanto, a usuarios! Si una parte nefasta tuviera una visión de múltiples redes (por ejemplo, tanto la red cableada a la que se conecta el WiFi como la red celular 4G), ¡podría utilizar los CID para rastrear a usuarios individuales a través de diferentes redes! Aunque probablemente esto esté fuera del alcance de los piratas informáticos individuales, las organizaciones más grandes, como las grandes empresas y especialmente las naciones-estado, podrían utilizar esta capacidad.

Por suerte, los diseñadores de QUIC eran muy conscientes de este problema, denominado "enlazabilidad". QUIC lo soluciona cambiando el CID cada vez que los usuarios cambian de red. Esto significa que los atacantes no pueden atribuir directamente la conexión a un dispositivo individual porque la dirección IP y el CID cambian. ¡Problema resuelto!

Sin embargo, ¿no necesitábamos en primer lugar un CID que no cambiara para hacer frente al hecho de que la dirección IP cambia? ¿Cómo es posible que eso funcione si el CID también cambia?

El truco consiste en asignar no sólo uno, sino varios CID a la misma conexión subyacente. En la figura 3, la conexión azul no sólo está descrita por el recuadro verde, sino TAMBIÉN por el círculo morado y el triángulo rojo. Crucialmente, sólo el cliente y el servidor conocen estos CID adicionales; cualquier atacante que se limite a observar el tráfico de la red no lo sabrá porque los nuevos CID se intercambian de forma segura una vez establecida la conexión QUIC cifrada. De este modo, los clientes pueden utilizar con seguridad el siguiente CID de la lista: sólo el servidor sabrá que en realidad se está dirigiendo a la misma conexión subyacente. 

(Nota: en la práctica, este mecanismo es aún más complicado debido a la necesidad de soportar equilibradores de carga y otros casos de uso. Consulte esta entrada del blog para obtener más información). 

Aunque este mecanismo funciona bastante bien, tiene algunos inconvenientes. El CID es una de las pocas partes que deben permanecer sin cifrar en los metadatos de la cabecera del paquete QUIC. Esto se debe en parte a que el servidor necesita poder buscar la conexión correcta basándose en el CID antes de poder utilizar las claves de descifrado TLS de esa conexión para desbloquear el paquete. Como se discutió en el post anterior de esta serie, cualquier metadato sin cifrar puede (y probablemente lo hará) ser leído (y probablemente mal utilizado/abusado) por middleboxes (y atacantes), comprometiendo de nuevo en cierto modo el diseño a prueba de futuro de QUIC. 

Utilizar un esquema de cifrado independiente sólo para los CID (de modo que puedan cifrarse por separado del paquete) puede resolver este problema. Sin embargo, eso aumenta la dificultad de implementar otros servicios, como cortafuegos y equilibradores de carga. Este problema es bastante difícil de resolver adecuadamente en la práctica, y aún se está trabajando en el IETF para definir cómo debería ser.

Es una pregunta excelente y actualmente se está trabajando en una función llamada Mulipath para solucionar este problema. Este concepto se ha desarrollado para TCP durante más de una década, pero ha sido difícil desplegarlo en todo el mundo. 

Con QUIC, basado en las características de migración de conexiones descritas anteriormente, este enfoque se hace mucho más factible. Empresas como Apple, Google y Alibaba están experimentando activamente con él para mejorar la solidez general de la red y aumentar el rendimiento combinando el ancho de banda de ambas redes para una única conexión conceptual.

En mi próximo post, hablaré del rendimiento de los protocolos en la naturaleza y de por qué es difícil comparar QUIC y HTTP/3 con TCP y HTTP/2.

Robin Marx es experta en rendimiento y protocolo web de Akamai. Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.