Imagina que utilizas tu teléfono en el trabajo para conectarte a una reunión virtual a través de la red WiFi de tu oficina.
La videoconferencia va sobrada pero tienes que llegar a una reunión con un cliente al otro lado de la ciudad. El animador dice que sólo quedan 15 minutos, así que decides ver el resto mientras caminas hacia tu coche para ahorrar tiempo.
Cuando el teléfono sale del alcance de la red WiFi, se conecta automáticamente a una red celular (4G o 5G) y empieza a utilizarla en su lugar. En este proceso, todas las conexiones que tienes 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 conexión”.
Como detallé en mi primer post de esta serie, el protocolo QUIC se desarrolló para superar varias ineficiencias que TCP tiene en torno a su diseño a prueba de futuro, incluyendo mejoras de privacidad y seguridad. En este post, entraré en más detalles al respecto, centrándome en el problema cotidiano que he ilustrado más arriba, y hablaré del futuro de la migración fluida entre redes.
El problema del TCP en la Internet actual
Como mencioné en mi anterior post, TCP no es el mejor protocolo para transferir tus 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 cambiar de red, ya no se pueden utilizar, 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 conllevan 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 ineficaz. Al fin y al cabo, sólo cambia la dirección IP, todo lo demás sobre la conexión TCP y su estado (por ejemplo, los parámetros de cifrado del protocolo Transport Layer Security (TLS)) podría conceptualmente permanecer igual. Estamos pagando un montón de 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 (puramente) 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). Así, aunque cambies de red y de dirección IP, mientras sigas 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 realmente eres tú 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, QUIC Connection Migration 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.
Mejorar la privacidad del usuario final
El CID no sólo describe conexiones individuales, sino que (implícitamente) está vinculado a dispositivos individuales y, por tanto, a usuarios. Si un malhechor tuviera acceso a varias redes (por ejemplo, tanto a la red cableada a la que se conecta el WiFi como a la red móvil 4G), ¡podría utilizar los CID para rastrear a usuarios individuales en distintas redes! Aunque es probable que esto quede fuera del alcance de los hackers individuales, las grandes organizaciones, 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 no cambiante 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 se describe mediante el recuadro verde, sino TAMBIÉN mediante el círculo morado y el triángulo rojo. Fundamentalmente, sólo el cliente y el servidor conocen estos CID adicionales; cualquier atacante que se limite a observar el tráfico de red no lo sabrá porque los nuevos CID se intercambian de forma segura una vez establecida una 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 balanceadores 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 no encriptado puede (y probablemente será) leído (y probablemente mal usado/abusado) por middleboxes (y atacantes), de nuevo comprometiendo de alguna manera 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 implantar 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.
¿Por qué no puedo usar WiFi y 4G al mismo tiempo?
Esta es una excelente pregunta y actualmente se está trabajando en una función llamada Mulipath para resolver este problema. Este concepto se ha desarrollado para el TCP durante más de una década, pero ha sido difícil implantarlo en todo el mundo.
Con QUIC, basado en las funciones de migración de conexiones descritas anteriormente, este enfoque es mucho más factible. Empresas como Apple, Google y Alibaba están experimentando activamente con ella 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 Experto en Protocolo y Rendimiento Web en Akamai. Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.