Empezamos fuerte: Internet está roto. Bueno, quizás no completamente, pero sí que tiene varios defectos. De hecho, siendo un poco más rigurosos y menos alarmistas con la anterior afirmación, podríamos decir que la arquitectura de red en la cual está diseñado internet tal y lo conocemos hoy en día, es mejorable. Puede parecer inocente afirmar esto, pero espero que al final de este artículo se entienda las debilidades que tiene la arquitectura actual y cómo podríamos mejorarla.
Pero empecemos por el principio. ¿Qué es una arquitectura? Podríamos definir una arquitectura como un conjunto de patrones y metodologías que permiten diseñar elementos con requisitos distintos. Ejemplifiquémoslo. Si tenemos en mente una iglesia/catedral, podemos decir con relativa facilidad, viendo el edificio, que tiene una arquitectura gótica, románica, clásica, etcétera. A pesar de que todos los elementos son edificios, cada uno tiene unas características distintas. Por tanto, una arquitectura captura patrones invariantes y comunes entre distintas construcciones independientes de los requisitos de cada una.
Pues ya tenemos el concepto de arquitectura definido, ahora nos falta el segundo: red. ¿Qué es una red? Al fin y al cabo, una red nos proporciona comunicación entre dos extremos, que de ahora en adelante llamaremos endpoints. ¿Pero estos endpoints que son? Pues en última instancia, son aplicaciones (siendo rigurosos, instancias de proceso del sistema operativo). Por lo tanto, una red no es más que una manera de copiar datos de manera distribuida (e imperfecta) entre dos aplicaciones. Esta definición de red, estaba muy presente en los inicios de las redes de comunicaciones, y en conclusión, viene a decir que, las redes de computadores, presentan servicios de comunicación entre procesos (IPC services en inglés).
Bien, ya tenemos una idea más o menos clara de lo que es una arquitectura de red. Ahora la pregunta que nos podríamos hacer sería la siguiente: ¿Cuál es la arquitectura de red actual? Pues no está formalmente definida. Según nuestra definición de arquitectura, el modelo actual no se corresponde a una arquitectura definida de manera formal y precisa. Lo que sí existe, son una serie de reglas que se cumplen (más o menos) y que funcionan (más o menos) y que hay problemas que no contemplan, y entonces cada caso de uso debe ser resuelto de manera independiente. Veamos más en detalle cuáles son los problemas que tenemos con la “arquitectura” actual.
Figura 1: ¿Está roto Internet? Qué es RINA y por qué puede
solucionar los problemas de la arquitectura TCP/IP actual
Pero empecemos por el principio. ¿Qué es una arquitectura? Podríamos definir una arquitectura como un conjunto de patrones y metodologías que permiten diseñar elementos con requisitos distintos. Ejemplifiquémoslo. Si tenemos en mente una iglesia/catedral, podemos decir con relativa facilidad, viendo el edificio, que tiene una arquitectura gótica, románica, clásica, etcétera. A pesar de que todos los elementos son edificios, cada uno tiene unas características distintas. Por tanto, una arquitectura captura patrones invariantes y comunes entre distintas construcciones independientes de los requisitos de cada una.
Pues ya tenemos el concepto de arquitectura definido, ahora nos falta el segundo: red. ¿Qué es una red? Al fin y al cabo, una red nos proporciona comunicación entre dos extremos, que de ahora en adelante llamaremos endpoints. ¿Pero estos endpoints que son? Pues en última instancia, son aplicaciones (siendo rigurosos, instancias de proceso del sistema operativo). Por lo tanto, una red no es más que una manera de copiar datos de manera distribuida (e imperfecta) entre dos aplicaciones. Esta definición de red, estaba muy presente en los inicios de las redes de comunicaciones, y en conclusión, viene a decir que, las redes de computadores, presentan servicios de comunicación entre procesos (IPC services en inglés).
Figura 2: Modelo de arquitectura de la OSI (izquierda, centro) y modelo de conjunto de protocolos de Internet (izquierda)
Fuente: RINA ETSI Report
Problemas de la arquitectura actual
1.- Layering
La arquitectura actual no deja espacio para nuevos protocolos de red. Hay una capa llamada “de red” común en todo Internet por encima del nivel de enlace. Esto implica que, por ejemplo, si una red quiere hacer routing que no sea IP, o esconder routers internos de redes privadas del Internet público, se deben usar soluciones ad-hoc.
El hecho de que se tengan que usar soluciones específicas para cada caso de uso es un problema, porque como es algo no está contemplado en la arquitectura común, cada diseñador de red arregla “sus problemas a su manera”. El caso de uso expuesto antes donde se quiere hacer routing de distinta manera, se puede resolver con MPLS (Layer 2.5), pero también se puede resolver de otras formas, por ejemplo en redes celulares está GTP, o protocolos de IP-tunneling (paquetes IP dentro de paquetes IP), etcétera.
1.- Layering
La arquitectura actual no deja espacio para nuevos protocolos de red. Hay una capa llamada “de red” común en todo Internet por encima del nivel de enlace. Esto implica que, por ejemplo, si una red quiere hacer routing que no sea IP, o esconder routers internos de redes privadas del Internet público, se deben usar soluciones ad-hoc.
El hecho de que se tengan que usar soluciones específicas para cada caso de uso es un problema, porque como es algo no está contemplado en la arquitectura común, cada diseñador de red arregla “sus problemas a su manera”. El caso de uso expuesto antes donde se quiere hacer routing de distinta manera, se puede resolver con MPLS (Layer 2.5), pero también se puede resolver de otras formas, por ejemplo en redes celulares está GTP, o protocolos de IP-tunneling (paquetes IP dentro de paquetes IP), etcétera.
Figura 3: El modelo de arquitectura de Internet se amplía constantemente
para contemplar nuevos casos de uso. Fuente: RINA ETSI Report
Al fin y al cabo, en esta sección se pretende ilustrar que, como la arquitectura no contempla una solución común independiente del tipo de red, existen una miríada de soluciones dispares. Y al fin y al cabo, esto se resuelve de la manera en que se ilustra en la figura inferior. Algo que a priori debería ser sencillo, con unas capas fijas, se acaba convirtiendo en realidad en lo que se muestra en la figura siguiente, donde aparecen distintos protocolos que se meten entre las distintas capas para poder solucionar casos de uso que ocurren en la actualidad y que la arquitectura no contempla. Si tuviéramos una arquitectura bien definida y concreta, no acabaríamos teniendo una macedonia de protocolos y soluciones puntuales.
2.- Nombre y direccionamiento
Otro problema que existe en la arquitectura actual es cómo identificar distintas entidades dentro de una red. Tenemos las aplicaciones, que son los endpoints de un servicio de comunicación de red. Veamos un ejemplo en la figura a continuación.
Las aplicaciones no tienen un nombre independiente. Para establecer un flujo de conexión TCP, necesitamos la dirección donde se encuentra la aplicación, además de un puerto, que indica el endpoint del flujo. Paremos aquí un momento.
2.- Nombre y direccionamiento
Otro problema que existe en la arquitectura actual es cómo identificar distintas entidades dentro de una red. Tenemos las aplicaciones, que son los endpoints de un servicio de comunicación de red. Veamos un ejemplo en la figura a continuación.
Figura 4: Nombres y direccionamiento en la arquitectura actual
Las aplicaciones no tienen un nombre independiente. Para establecer un flujo de conexión TCP, necesitamos la dirección donde se encuentra la aplicación, además de un puerto, que indica el endpoint del flujo. Paremos aquí un momento.
Si nos fijamos en la dirección de la aplicación de Alice es www.elladodelmal.com:80, vemos que esto no se parece a una dirección IP, y en efecto, se necesita la traducción del DNS para convertirlo a dirección IP. El DNS resuelve la dirección antes de establecer el flujo de conexión, y el DNS es un sistema externo, ajeno a la red. La red no entiende de direcciones de aplicaciones, la red solo entiende que está conectando una interfaz de red (y un puerto) a otra interfaz de red (y otro puerto).
Por ejemplo, si la red se mueve, la red no tiene ni idea que la misma aplicación se está instanciando en otra parte, entonces cualquier gestión que haya que hacer (como por ejemplo volver a enrutar el tráfico), no se puede hacer sin un elemento externo a la red (como es el caso del DNS). En conclusión: que la red no sepa los nombres de las aplicaciones es un problema.
3.-Movilidad
Como hemos visto, el nombre de la aplicación no es estable y depende del sitio donde te encuentres. Una ejemplificación muy simple de la problemática que causa este hecho, sería que yo en mi casa me llamara Sergio, pero que en mi trabajo me llamaran de otra manera, solo por el simple hecho de haberme movido.
3.-Movilidad
Como hemos visto, el nombre de la aplicación no es estable y depende del sitio donde te encuentres. Una ejemplificación muy simple de la problemática que causa este hecho, sería que yo en mi casa me llamara Sergio, pero que en mi trabajo me llamaran de otra manera, solo por el simple hecho de haberme movido.
Con las redes pasa exactamente esto. Si te mueves, tu dirección cambia. ¡Y debe ser así! Porque la dirección debe identificar dónde te encuentras exactamente; pero el nombre de la aplicación debería ser estable, ya que solo indica quién eres y no debe variar en función de donde te encuentres.
Pero en el modelo actual no ocurre esto. En la capa de red (que se ocupa del enrutamiento) solo existe un único identificador: la dirección IP. Los routers no entienden de nombres de aplicaciones, solo direcciones IP. Así que si se quiere tener movilidad en una red, se deben usar más protocolos.
4.- Multi-homing
Se puede dar el caso de que Alice tenga más de dos interfaces de red en su máquina, es decir, Alice se puede conectar a una red o a más de una red. El problema aquí, es que cada interfaz debe tener una dirección IP distinta. Con lo cual, la aplicación de Alice tiene 2 direcciones, ya que tenemos una dirección para cada interfaz.
Pongamos un ejemplo, si la aplicación de Bob envía tráfico a la aplicación de Alice, la red enrutará dicho tráfico desde 12.12.12.12 a 10.0.0.1. Lo que pasa es que si 10.0.0.1 se rompe, la aplicación de Bob no tiene ninguna manera de enviar ese tráfico a la aplicación de Alice. El tema aquí es que la aplicación de Bob no quiere ir a 10.0.0.1, ni a 10.11.0.1, sino que quiere ir a la aplicación de Alice.
Por supuesto, esto es algo que se puede solucionar parcialmente en el modelo actual (solucionar parcialmente, porque los endpoints deben ser partícipes en esta solución, no es la red quien brinda soluciones). Igual a este punto el lector ya se imagina cómo… más protocolos (SHIM6, Multipath TCP, BGP…).
Sin embargo, si esto hubiera estado pensado desde un principio e incluido en la arquitectura, se le podría haber encontrado una solución proporcionada de forma nativa en la arquitectura. De todas formas, la solución a este problema es trivial tal y como se muestra en la siguiente figura.
Pero en el modelo actual no ocurre esto. En la capa de red (que se ocupa del enrutamiento) solo existe un único identificador: la dirección IP. Los routers no entienden de nombres de aplicaciones, solo direcciones IP. Así que si se quiere tener movilidad en una red, se deben usar más protocolos.
4.- Multi-homing
Se puede dar el caso de que Alice tenga más de dos interfaces de red en su máquina, es decir, Alice se puede conectar a una red o a más de una red. El problema aquí, es que cada interfaz debe tener una dirección IP distinta. Con lo cual, la aplicación de Alice tiene 2 direcciones, ya que tenemos una dirección para cada interfaz.
Pongamos un ejemplo, si la aplicación de Bob envía tráfico a la aplicación de Alice, la red enrutará dicho tráfico desde 12.12.12.12 a 10.0.0.1. Lo que pasa es que si 10.0.0.1 se rompe, la aplicación de Bob no tiene ninguna manera de enviar ese tráfico a la aplicación de Alice. El tema aquí es que la aplicación de Bob no quiere ir a 10.0.0.1, ni a 10.11.0.1, sino que quiere ir a la aplicación de Alice.
Figura 5: Problema del multi-homing.
Sin embargo, si esto hubiera estado pensado desde un principio e incluido en la arquitectura, se le podría haber encontrado una solución proporcionada de forma nativa en la arquitectura. De todas formas, la solución a este problema es trivial tal y como se muestra en la siguiente figura.
Figura 6: Solución del problema de multi-homing dando direcciones a los nodos
Bastaría con que la arquitectura estuviera diseñada con direcciones en los nodos, no a las interfaces. Y luego enrutar tráfico en base a estas direcciones de nodos.
Concluyendo…
La arquitectura actual, como hemos ido viendo tiene defectos:
- En su estructura
- Cómo se diseñan protocolos: no se rehúsa cosas en común entre protocolos, todos ellos se diseñan desde cero (aunque hagan funciones muy parecidas).
- Nombres y direcciones. Como hemos ido viendo, tiene todos los problemas de multi-homing y movilidad que hemos comentado.
Y no hemos hablado de cosas que también dan para rato, como por ejemplo la API de los sockets para programar aplicaciones, seguridad - que de eso tenéis muchos ejemplos en el libro de Ataques en redes de datos IPv4 & IPv6 -, gestión de la red, ya que a más protocolos, más complicación a la hora de gestionar una red.
Quizás llegado a este punto, podrías estar pensando sobre lo inocente que puede ser hablar sobre “lo mal que funciona Internet”, pero en realidad paradójicamente esta información te está llegando gracias a la arquitectura actual. Y millones de cosas que funcionan sobre esta arquitectura y que nadie hace 20 años pensaba que pudieran llegar a suceder. Pero realmente, las cosas que se han ido mencionando son defectos reales que tiene la arquitectura y que sí se pueden mejorar. Y de la voluntad de intentar mejorar todo esto, aparece RINA. Pero esto, lo hablaremos en detalle en la siguiente parte de este artículo.
Figura 7: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de
JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso
Saludos,
Autor: Bruno Ibáñez, Investigador de Ciberseguridad e IA en Ideas Locas y Sergio Giménez investigador de i2cat.
No hay comentarios:
Publicar un comentario