Ya se ha indicado en la entrada anterior, el funcionamiento básico de I2P y su composición más simple, se ha indicado el uso de túneles y sus diferentes tipos, también se ha indicado el proceso de instalación sobre una máquina con Linux. En esta ocasión se intentará profundizar aun más sobre el funcionamiento de I2P a nivel técnico, indicado cada una de las entidades que se incluyen todo el proceso de envío de mensajes entre emisor y receptor.

En primer lugar, los conceptos clave de I2P son 3:

  1. Anonimato sin ocultación de los participantes en el proceso de comunicación:

    se ha hablado anteriormente de esto, consiste principalmente en la capacidad que tiene I2P de proporcionar a sus usuarios anonimato sin la necesidad de ocultar su localización (como lo hace TOR), en el caso de I2P no es ningún secreto para un usuario que usa I2P saber que otro usuario se encuentra utilizando I2P también, sin embargo, el anonimato proporcionado se encuentra en que todas las peticiones realizadas por los usuarios en la red son básicamente iguales, por lo tanto se puede saber que un usuario participa en dicha red, pero la información sobre lo que esta haciendo no es publica ni se registra en ningún sitio, es en efecto, anónima. Por otro lado, en I2P existe una separación entre los elementos que participan en la red (tuneles y routers) y los puntos finales (destinos), tanto los routers como los destinos, son también anónimos, esto quiere decir que es información privada, el hecho de que un router particular se conecte con un destino concreto. Por ejemplo, los usuarios finales normalmente tienen tienen muchos destinos locales en sus routers, tal vez uno para servidores IRC, otro para servidores web anónimos (también conocidos en I2P como “eepsite”), etc.

  2. Uso de Túneles Inbound y Outbound

    Los túneles Inbound y Outbound como su nombre lo indican, permiten a un usuario recibir y enviar peticiones respectivamente utilizando una serie de routers conectados entre si, dichos routers tienen distintas funcionalidades y roles, que como ya se ha dicho se separan en 3 categorias, GateWay, Participant y EndPoint. Este conjunto de routers tiene como finalidad establecer un camino directo hacia un destino por medio de un listado de routers seleccionados de forma explicita, cabe anotar que la comunicación es cifrada sobre cada “capa” (de acuerdo al modelo OSI de arquitectura de redes) donde cada router solamente puede descifrar una única capa, dicha información descifrada solamente contiene la dirección IP del próximo router al cual se debe redireccionar el paquete y toda la información es cifrada, por esta razón, ningún router podrá acceder a los datos que esta transmitiendo un emisor, solamente el receptor, el cual se ejecuta en una capa superior (capa de presentación en el modelo OSI) puede descifrar la información que esta destinada a él. Ahora bien, el hecho de que tengan que existir dos túneles para que la información pueda fluir en ambos sentidos, es debido a que cada túnel es unidireccional, lo que indica que los paquetes solamente se pueden o bien enviar (Outbound) o recibir (Inbound), esta es otra de las diferencias que se encuentran con los circuitos en TOR, dado que cada uno de los routers en un circuito construido en TOR tienen la capacidad tanto de enviar como de recibir paquetes.

  3. Uso de NetDB (Network Database)

    De este concepto no se ha hablado con anterioridad, no obstante es vital para el correcto funcionamiento de los túneles en I2P, dado que suministra dos tipos de metadatos importantes a la hora de construir cada túnel que son “routerInfo” y “leaseSets”. “routerInfo” da a cada router la información necesaria para contactar a un router particular (tales como claves publicas, direcciones, etc.) mientras que los “leaseSets” suministran la información necesaria para contactar con el destino, esta información incluye los siguientes campos:

    1. Inbound Gateway de un túnel que permita alcanzar al destino

    2. Fecha y hora en la cual el túnel expira (recordar que la duración de un túnel es limitada y se construyen dinámicamente)

    3. Par de claves publicas que permitan cifrar los mensajes que se enviaran a cada router encargado de redirigir la petición.

Esta información es actualizada por cada router, en concreto la información del “routerInfo” es enviada de forma directa al servicio de NetDB, mientras que los “leaseSets” deben ser enviados por medio de un túnel de salida de forma anónima para evitar cualquier tipo de correlación entre los routers, los “leaseSets” y los destinos.

Con los conceptos anteriores correctamente asimilados y entendidos, se puede comenzar a explicar como es el proceso que utiliza I2P para que un usuario pueda construir sus respectivos túneles y posteriormente comenzar a enviar paquetes de forma anónima. En primer lugar, un usuario solicitará un “routerInfo” de forma explicita al servicio de NetDB de I2P, el cual responderá con un listado de routers que pueden ser utilizados para construir un túnel, posteriormente el usuario envía un mensaje del tipo “build tunnel” al primer router en la lista lo que permite que se solicite la construcción del túnel a los demás routers hasta que el túnel este completamente construido

Ahora viene el momento del envío de un mensaje a un destino, para tal fin, el nodo emisor debe en primer lugar, solicitar el “leaseSet” al servicio de NetDB de I2P, el cual retornará la información necesaria para enviar el mensaje, la cual incluye, como ya se ha mencionado en lineas anteriores el Inbound Gateway del receptor, por lo tanto en este punto el emisor envía el el paquete conteniendo el mensaje a su correspondiente Outbound Tunnel el cual se encargará de enrutar la petición hacia el Inbound Gateway solicitado. Ahora bien, en el caso de que el emisor quiera que el receptor tenga la opción de responder a dicho mensaje, es necesario que envié de forma explicita información del destino como parte del mensaje enviado originalmente, esta información frecuentemente corresponde al ultimo “leaseSets” construido por el emisor, de esta forma el receptor ahorra tiempo ya que no requiere hacer una consulta al servicio de NetDB en busca de toda la información del Inbound Tunnel del emisor.

La siguiente imagen demuestra la explicación anterior

La imagen anterior corresponde al proceso de construcción de un túnel por parte de un emisor (el mismo mecanismo se emplea tanto para túneles Inbound como Outbound). Después de dicho procedimiento la siguiente imagen enseña como se lleva a cabo el proceso para el envío de un mensaje a su correspondiente destino y como este a su vez puede responder al emisor.

A continuación se describen cada uno de los pasos descritos en la imagen anterior para terminar de aclarar los conceptos establecidos en esta entrada

  1. El emisor solicita el “leaseSets” para enviar un mensaje a su destino “Adastra”

  2. El servicio NetDB retorna dicho “leaseSets” el cual contiene, entre otras cosas, el Inbound Gateway del destino para llevar a cabo la conexión desde el túnel de salida.

  3. El emisor procede a enviar el mensaje

  4. Cada uno de los routers que hacen parte del túnel Outbound se encargan de cifrar/descifrar el mensaje enviado por el emisor a nivel de la capa de transporte, por lo tanto solamente la dirección IP del siguiente router es “visible” mientras que el contenido del mensaje sigue viajando cifrado.

  5. El “leaseSets” suministra la información necesaria para que el “EndPoint” pueda enviar el mensaje al Inbound Gateway del receptor “Adastra”. Ademas de esto, en este punto hay una capa adicional de cifrado del mensaje llamada “Garlic Encription” cuya finalidad es evitar la “divulgación” no autorizada de información sensible entre el túnel de salida del emisor y el túnel de entrada del receptor. Este concepto es muy importante en I2P ya que garantiza que las comunicaciones entre los túneles Inbound y Outbound no se ven comprometidas, el resultado de este proceso es conocido como “Garlic Message”, que entre otras cosas, permite al emisor, enviar uno o muchos mensajes por medio de un “Garlic Message” cifrado con la clave publica del destinatario de esta forma cualquier otra entidad que participe en la red I2P no podrá determinar cuantos mensajes hay dentro del “Garlic Message”, que dicen, de donde vienen y a quien se dirigen.
    En este caso concreto el mensaje “Garlic” será cifrando con la clave pública que se incluye en el “leaseSets” de “Adastra”, permitiendo de esta forma que el mensaje sea cifrado sin transmitir la clave publica al router de entrada (Inbound Gateway) de “Adastra” (que perfectamente podría no serlo).

  6. El mensaje es enrutado por el túnel de entrada de “Adastra” hasta su correspondiente destino.

  7. “Adastra” descifra el mensaje enviado por “Emisor”. En el caso de que “Adastra” quiera responder a dicho mensaje tiene 2 opciones, en primer lugar si el mensaje tiene incluido el “leaseSets” de “Emisor” contiene la información necesaria para enviar el mensaje por medio de su túnel de salida, hacia el Inbound Gateway de “Emisor”, en el caso de que el mensaje no contenga el “leaseSets” de “Emisor”, es necesario realizar una búsqueda explicita de esta información al servicio NetDB.

    7.1 Se solicita el “leaseSets” para el destino “Emisor”

    7.2 El servicio NetDB retorna el “leaseSets” de “Adastra”

  8. Cifrado y transmisión del mensaje de “Adastra” hacia “Emisor”.

  9. Cifrado y transmisión del mensaje desde el EndPoint del túnel de salida de “Adastra” hacia el Inbound Gateway del túnel de entrada de “Emisor”. Se lleva a cabo el procedimiento adicional de cifrado del mensaje con la clave pública del destinatario, como se ha indicado antes, procedimiento de “Garlic Encription”

  10. Finalmente, el mensaje es enrutado por todos los routers de entrada del túnel Inbound de “Emisor” hasta llegar al destino final.

CIFRADO GARLIC

Finalmente, para terminar esta entrada, es necesario comprender lo que significa dentro del mundo de I2P el termino “Garlic”, aunque en anteriormente se ha indicado lo que significa el termino “Garlic Encription”, este termino puede aplicar a 3 conceptos diferentes en de I2P, los cuales son:

  • Cifrado a nivel de capa: Cuando el termino “Garlic” se emplea a nivel de cifrado entre dos o más nodos, se refiere a cifrado a nivel de capa, que como ya se ha indicado anteriormente, permite que aquella información que va destinada a un receptor determinado no sea descifrada en cada enrutamiento que se lleva a cabo en los diferentes túneles (Inbound, Outbound) de hecho, cuando un mensaje se esta transmitiendo en cada router, solamente se descifra la información correspondiente al siguiente router al que se le debe enviar el paquete en la cadena de envío, dejando el contenido del mensaje cifrado en la capa de transporte, cuando finalmente llega a su destino, a nivel de aplicación, el contenido del mensaje puede ser descifrado completamente.

  • Agregación de Múltiples mensajes juntos: En este caso, un “Garlic Message” corresponde a un conjunto de mensajes agregados en un solo canal cifrado, cada uno con su propia información de entrega, de esta forma es posible construir bloques “reply” con el mensaje original, este es precisamente el modelo que se ha enseñado en la ultima imagen de esta entrada, donde se construye un “Garlic Message” con la información del “leaseSets” del emisor, para que el receptor pueda responder al mensaje de forma inmediata sin necesidad de realizar de forma explicita una búsqueda al servicio de NetDB. El hecho de que un solo mensaje en un túnel de salida/entrada pueda contener múltiples mensajes es una característica interesante que permite mejorar el rendimiento en las comunicaciones y una de las principales ventajas que ofrece I2P frente a TOR

  • Cifrado utilizando ElGamal/AES: Se trata del mecanismo empleado por cada uno de los routers en cada canal de comunicación para cifrar los paquetes que viajan entre cada uno de ellos, todos los mensajes son cifrados utilizando el algoritmo de cifrado “ElGamal” y posteriormente se utiliza “AES256/CBC”.

En próximas entradas se detallará un poco más como estos conceptos aplican desde el punto de vista practico.