Mientras lees esto, paquetes y paquetes de datos salen y entran del portátil, móvil o PC que estás usando para hacerlo. La magia de tu conexión a internet se basa en diversos protocolos como TCP, IP, UDP, SSL/TLS, DNS, o HTTP/HTTPS.
Todos esos acrónimos definen la forma en que nos comunicamos a través de internet, pero la propia evolución de la red de redes ha hecho que esos protocolos cambien. Lo han hecho y sobre todo lo seguirán haciendo para garantizar dos cosas: velocidad y seguridad.
En 1998 internet tenía 50 millones de usuarios que accedían a los servicios que proporcionaban 25 millones de servidores (sobre todo web y de correo electrónico). Ese año, contaba Vinton Cerf, fue en el que nació la ICANN (Internet Corporation for Assigned Names and Numbers), la asociación encargada de coordinar y gestionar esa gigantesca base de datos que entre otras cosas engloba todos los dominios de internet que los usuarios visitamos a diario.
Hace 20 años las cosas eran muy distintas, claro. Las conexiones de banda ancha eran una utopía para la mayoría de los usuarios, que comenzaban a contagiarse de la fiebre por aquellos célebres pitidos que hacían los módems con los que se conectaban a internet. Los protocolos que habían sido adecuados en aquella tumultuosa época previa al desastre de las puntocom pronto tendrían que enfrentarse a los nuevos retos.
El mayor de todos fue el explosivo crecimiento de una red que se convirtió en el nuevo tejido de las comunicaciones a nivel mundial. A las conexiones de banda se le sumó la revolución móvil, y eso provocó que de repente aquellos protocolos que Bob Kahn y Vinton Cerf comenzaran a definir en 1974 con su 'A Protocol for Packet Network Intercommunication' (PDF) se quedaran algo cojos.
De hecho todos los que acabaron usándose en la red de redes necesitaban mejoras. Ocurrió con los protocolos de aplicación (DNS, FTP, TLS/SSL, HTTP, IMAP4, POP3, SIP, SMTP, SNMP, SSH, Telnet, RTP), los de transporte (TCP, UDP), los de internet (IPv4, IPv6, ICMP, IGMP), o los de enlace (ARP). Muchos más surgieron alrededor de los citados, pero en todos los casos ocurrió lo mismo: se quedaban pequeños, anticuados... o las dos cosas.
No es de extrañar: según la ITU (PDF) en 2017 nuestro planeta, con 7.300 millones de personas poblándolo, ya usaba internet en una proporción asombrosa: el 84,4% de la población de países desarrollados ya está conectada, aunque la brecha digital persiste. Solo el 42,9% de los países en vías de desarrollo y el 14,7% de los países menos desarrollados (LDCs) dispone de ese acceso a internet.
Lo cierto es que cuando internet empezó a conquistar nuestro mundo lo hizo gracias a unos protocolos que lógicamente estaban pensados para aquella época y aquellas necesidades. Las necesidades —como veníamos diciendo— cambiaron y hubo que ir adaptando esos protocolos.
Así fue como de las conexiones SSL acabaron migrando (en su mayoría) al protocolo TLS, como el protocolo HTTP añadió nuevas cabeceras y métodos para acabar también migrando (gradualmente, aún estamos en ello) al protocolo HTTPS, y en el importante protocolo DNS acabamos usando su versión segura, DNSSEC.
Como explicaban en APnic, esos cambios han sido importantes, pero hay varios protocolos que están planteando cambios importantes a la estructura de internet. Las principales razones para la aparición de esas nuevas alternativas son tres:
El heredero al trono del protocolo HTTP (Hypertext Transfer Protocol), su sucesor natural, es HTTP/2. Convivimos de hecho con esta nueva versión desde hace tiempo, y curiosamente este proyecto partió del trabajo realizado con el protocolo SPDY que Google creó en 2012.
Una de las ideas fundamentales de HTTP/2 es la multiplexación de peticiones en una sola conexión TCP, algo que evita encolar peticiones en un cliente que se van bloqueando unas a otras. Esto hace que las conexiones se aprovechen mucho mejor, y gracias al soporte masivo de navegadores y servidores web es un protocolo que ya tiene una amplia adopción.
Esa ventaja se combina con otras igualmente importantes, como el hecho de que HTTP/2 usa cifrado por defecto (aunque no sea estrictamente obligatorio, lo hace vía TLS/1.2), algo que entre otras cosas evita interferencias con intermediarios que asumen que se usa HTTP/1.1. No es una versión escrita desde cero del actual HTTP, y muchos de los métodos y la semántica se conservan, lo que ha facilitado enormemente la transición
Al contrario que HTTP/2, el protocolo TLS (Transport Layer Security) en su versión 1.3 está en pleno desarrollo. El borrador fue publicado a principios de marzo de 2018, y se espera que pronto se complete su estandarización. Eso no impide que algunas implementaciones de servicios y aplicaciones lo soporten ya.
Aunque esa numeración no lo deja demasiado claro, TLS 1.3 es una versión especialmente importante que casi merecería un número más redondo de versión, quizás un TLS 2.0. Sea como fuere, en esta versión se da la bienvenida a las llamadas claves efímeras.
Eso hace que un potencial atacante vaya a tenerlo mucho más difícil a la hora de tratar de interceptar y descifrar una comunicación. Las claves estáticas que se usan hoy en día plantean el problema de ser precisamente "perennes", pero con las claves efímeras ese problema desaparece: tienen una caducidad y que cambian en cada establecimiento de cada comunicación, lo que hace que el proceso de intercambio de claves sea mucho más dinámico y más difícil de superar por parte de ese potencial atacante.
Como sucede con HTTP/2, este protocolo se basa en un proyecto inicial de Google que ahora ha pasado a supervisar la IETF (Internet Engineering Task Force) con el nombre iQUIC. Una de las claves es el uso de HTTP sobre UDP (User Datagram Protocol) en lugar de hacerlo sobre TCP, un protocolo "ordenado" frente a esa otra alternativa algo más descuidada que es UDP, que por ejemplo desecha todo lo que dedica TCP al control de errores.
Con UDP los paquetes se envían al receptor sin más, y el emisor no espera a que el receptor le diga si han llegado o no: los sigue enviando pase lo que pase, lo que hace que no haya garantías de que el receptor está recibiendo todos los paquetes. El protocolo se usa con frecuencia en emisiones en broadcasts e incluso en juego online, y Google ya ha integrado soporte en Chrome.
Otra de las características clave de QUIC es que está cifrado por defecto. La propia estructura de QUIC hace que plantee algún que otro quebradero de cabeza a las operadoras, ya que hace imposible tratar de estimar cosas como el RTT (Round Trip Time), un parámetro con la que las operadoras pueden analizar y evaluar la calidad y prestaciones de sus redes.
Uno de los problemas actuales del protocolo DNS es que su diseño favorece a aquellos que quieren imponer ciertas políticas. Estudios como este muestran cómo operadoras y grandes organizaciones usan o pueden usar esa estructura para, entre otras cosas, "secuestrar" las comunicaciones (hijacking) y manipularlas o espiarlas.
Para corregir ese problema ha surgido el que podría ser el más notable de todos estos protocolos. Se trata de DOH (DNS Over HTTP), una alternativa que aprovecha la conexión HTTP para el tráfico DNS, lo que hace que se eliminen esos discriminadores que permiten hacer cosas como ese secuestro de comunicaciones del que hablábamos.
Esto evitaría a gobiernos y organizaciones bloquear fácilmente dominios completos. El trabajo en este protocolo está aún en fases previas de desarrollo, aunque aquí una vez más ciertos organismos, empresas y gobiernos podrían no ver con buenos ojos un cambio que limitaría su control sobre estas redes.
El trabajo que hay detrás de todos estos protocolos es, como decíamos, el que hará que internet pueda seguir evolucionando y adaptándose a los nuevos tiempos y, claro está, a las nuevas necesidades.
Los problemas que amenazan con el estancamiento provienen de quienes adaptan y personalizan esos protocolos para uso propio —ejem, AMP, ejem—. Cuando un protocolo no puede evolucionar porque su implantación en ciertos escenarios "congela" su capacidad para adaptarse, se dice que se ha osificado.
EL protocolo TCP es un buen ejemplo de ello, explican en APnic. Este protocolo está tan extendido en tantos dispositivos e intermediarios que lo han adaptado a sus necesidades (bloquear paquetes con opciones TCP que no se reconocen, control optimizado de la congestión) y eso hace difícil que el protocolo estándar evolucione de forma sencilla.
Eso se une a esas nuevas necesidades en el ámbito de la privacidad y el rendimiento de esas comunicaciones online. Comunicaciones que se sustentan sobre estos protocolos y que deben seguir garantizando la interoperabilidad. Los cambios siempre son difíciles, pero si queremos que internet siga creciendo con nosotros, tendremos que aceptarlos. Y las operadoras, organizaciones, empresas y gobiernos, también.
