Preservando el Anonimato y Extendiendo su Uso – Arquitectura y Protocolos utilizados en I2P – Parte XXVIII

Hasta este punto se ha hablado de una forma extensa sobre la arquitectura del I2P y la capa de aplicación resaltando los principales clientes y plugins que pueden ser instalados en una instancia I2P, se ha hablado sobre los detalles funcionales de I2P y como los mensajes son transferidos entre emisores y receptores, no obstante no se ha profundizado sobre los protocolos y las distintas capas que soportan todo esto para que la comunicación anónima entre dos entidades sea posible, la pila de protocolos que se soportan en I2P están agrupados por capas complejas que extienden de forma significativa el modelo de referencia estándar OSI para comunicaciones en entornos de red. En realidad esta es una de las razones por las cuales I2P es también considerado un proyecto con un alto nivel académico y técnico que para muchos resulta interesante y sumamente practico. Para explicar a grandes rasgos la arquitectura de red de I2P y con el objetivo de que sea fácil de comprender para el lector (y a la vez con un buen nivel de contenido técnico), se comenzará por indicar cada uno de los elementos de la pila de protocolos de I2P desde su capa más alta (aplicación) hasta las capas más bajas (transporte).

Capa de Aplicación:

Aquí se encuentran las aplicaciones que se han mencionado en entradas anteriores y que permiten el acceso por parte de los clientes a toda la infraestructura de I2P para el envío y recepción de mensajes de forma anónima. En esta categoría se encuentran clientes como Plugins, Eepsites, etc. Además también es importante recordar que I2P, a diferencia de TOR no tiene las mismas limitaciones de soportar únicamente protocolo TCP (las peticiones UDP no puede aceptarlas como se ha visto anteriormente). I2P soporta ambos protocolos, en el caso de UDP existen algunas aplicaciones existentes que se ejecutan sobre dicho protocolo, tales como I2PSnark, Syndie y I2Phex.

Capa de Cifrado “Garlic”

Esta capa provee cifrado end-to-end de los mensajes y la correcta entrega de los mismos, esta capa es de gran importancia dado que es la que comunica la capa de aplicación con las capas inferiores, el cifrado a este nivel permite que todos los paquetes que viajan en las capas de más bajo nivel no puedan decifrar el mensaje que se trata de enviar y/o recibir por parte de uno de los participantes en el proceso de comunicación, este concepto es vital y es importante comprenderlo correctamente. Todos los mensajes en I2P tienen una estructura y un formato definido que se encuentra apoyado por su correspondiente especificación, cada mensaje en dicha especificación es conocido como mensaje I2NP (I2P Network Protocol) y estos pueden ser usados para “recubrir” otros mensajes para que sean transportados de forma segura hacia su destino (para ver la especificación oficial de mensajes I2P navegar aquí: http://www.i2p2.de/i2np.html). En esta capa se transportan mensajes Garlic que son realmente mensajes cifrados y recubiertos por un mensaje de datos estándar, este mensaje contiene a su vez instrucciones detalladas para su entrega al destinatario final, las cuales incluyen simplemente la lista de routers por los que el mensaje debe pasar antes de llegar a su destino, esta información viaja entre cada uno de los routers que conforman el túnel Outbound del emisor y el túnel Inbound del receptor.

Capa de Túneles

En esta capa se establecen las comunicaciones seguras en cada túnel (Inbound) y (OutBound) y del mismo modo que anteriormente en la capa de “Cifrado Garlic”se manipulaban mensajes I2NP, en esta capa existe un concepto adicional de mensajes llamado “Mensajes de Túnel” los cuales en realidad contienen mensajes I2NP cifrados (Garlic Messages) y sus correspondientes instrucciones de entrega que también se encuentran cifradas (todo esto empaquetado en un único paquete cifrado, esto es un mensaje de túnel), en este punto se puede decir que existe un cifrado a nivel de capa, dado que las claves para cifrar los mensajes Garlic y las instrucciones de entrega a destinatario son distintas, en primera instancia los mensajes Garlic no pueden ser descifrados por ningún router en la capa de túnel dado que utilizan la clave publica del receptor (que el emisor probablemente ha obtenido del LeaseSets registrado en el servicio de NetDB), con lo cual, solamente el receptor con su clave privada podrá descifrar dichos mensajes, mientras que las instrucciones de entrega si que podrán ser descifradas por cada router ya que para establecer cada conexión entre cada nodo, se utiliza la misma clave publica. La especificación oficial de los mensajes de Túnel puede ser consultada desde aquí: http://www.i2p2.de/tunnel_message_spec.html

Capa de Transporte I2P

Se trata de una extensión de la capa de transporte clásica soportada por prácticamente todos los sistemas de comunicación existentes hoy en día, sin embargo en el caso de I2P, en esta capa implementa un cifrado entre dos routers I2P y aunque el cifrado de la comunicación no implica en este punto ningún tipo de anonimato, se trata simplemente de una comunicación segura entre dos máquinas. El protocolo que se implementa en esta capa depende directamente de aquel que soporte la capa de aplicación; por ejemplo, anteriormente se ha mencionado que I2PSnark soporta UDP, en estos casos se debe usar protocolo UDP en la capa de transporte y SSU en esta capa. En I2P se utilizan dos extensiones especiales que son NTCP y SSU

SSU: Este es uno de los protocolos utilizados en I2P el cual es utilizado en conexiones salientes (igual que NTCP) se encuentra soportado por el protocolo UDP y proporciona una capa de transporte segura, cifrada y orientada a la conexión, además de que también provee servicios de detección automática de IP, servicios NAT, Detección de firewalls y Detección de cambios de configuración en el segmento de red donde se ejecuta I2P. Estos servicios son ampliamente utilizados por NTCP para su correcto funcionamiento, por lo tanto puede decirse que existe una relación de dependencia entre ambos protocolos.

NTCP: Se trata de un protocolo de transporte basado en Java introducido en I2P y que es más eficiente que el protocolo TCP sobre el que esta construido dado que soporta la especificación NIO de Java que pueden manejar múltiples conexiones utilizando varios hilos dando un desempeño mucho más adecuado. NTCP utiliza una dirección IP y un puerto (que deben mantenerse privados para el uso de I2P) que por defecto son auto-detectados dependiendo de la dirección IP publica del gateway del segmento de red donde se ejecuta I2P que proporciona la salida a internet, estas propiedades pueden modificarse en: http://127.0.0.1:7657/config

Capa de Transporte

Se trata de la capa ampliamente conocida del modelo de referencia OSI, en este caso concreto, I2P se basa en dos protocolos: TCP y UDP. Tal como se ha indicado en lineas anteriores, estos protocolos son el apoyo vital de los protocolos implementados en la capa de transporte I2P que son SSU y NTCP.

Capa IP

La capa de nivel más bajo que proporciona conectividad entre dos máquinas, su implementación sigue el modelo de referencia estándar OSI para la interconectividad, permite la asignación de direcciones IP validas y el enrutamiento de paquetes sobre redes intranet e internet.

Para afianzar todos estos conceptos se enseña el siguiente diagrama y su correspondiente explicación en cada una de las capas por las cuales transitan los mensajes.

En este diagrama se puede apreciar claramente como viajan los mensajes en cada una de las capas de I2P y las “transformaciones” que se van aplicando, así como también se puede apreciar como es el comportamiento de un paquete que llega desde un router externo y como el receptor descifra el mensaje garlic y extrae el mensaje I2NP para su posterior uso.

EXTENSIONES DE LA ARQUITECTURA

Aunque los elementos que se han indicado anteriormente corresponden a todas las capas utilizadas en I2P, aun existen elementos adicionales que si bien no hacen parte de forma estricta de la arquitectura base, implementan mejoras sustanciales en términos de desempeño y fiabilidad, cada una de estas extensiones se encuentra superpuesta por encima de alguna de las capas anteriormente descritas con el único fin de extender sus funcionalidades sin interferir de forma directa en su funcionamiento. Algunas de estas extensiones arquitecturales son:

Capa I2P de Transporte End-to-End

Se trata de una capa que se encuentra superpuesta por sobre la capa de I2P Client (ver más abajo) y permite utilizar las funcionalidades incluidas en TCP y/o UDP sin depender de forma estricta de SSU y NTCP (incluidos en capa de transporte I2P). Los protocolos soportados en esta capa son:

Streaming Library (Implementación TCP)

Esta librería se ha explicado anteriormente, su principal ventaja es el hecho de poder encapsular varios mensajes TCP/IP en un solo paquete administrado por esta librería, de esta forma, en una única petición/respuesta puede finalizarse la comunicación, dado que este paquete contendrá toda la información necesaria tanto para el emisor como para el receptor, como por ejemplo en el caso de una petición HTTP/HTTPS donde un cliente envía en la petición los paquetes SYN, FIN y el payload correspondiente y en la respuesta el servidor web retorna los mismos paquetes SYN,FIN y payload de respuesta junto con el ACK que reconoce la transmisión. El uso de este protocolo es bastante extendido en I2P dado que permite mejorar de manera considerable el “peso” y el rendimiento de la red permitiendo un escenario muy eficiente.

Datagram Library (Implementación UDP)

Se trata de mensajes que proporcionan funcionalidades adicionales sobre los mensajes I2NP enviados, dado que facilitan mensajes autenticados y fáciles de replicar a su emisor utilizando el formato estándar de los mensajes I2NP. Esta librería permite a los clientes de la capa de aplicación leer el campo “from” que se incluye en los datagramas que utilizan protocolo UDP y de esta forma conocer la dirección del emisor del mensaje (No se trata de la dirección real del emisor, simplemente se suministra la dirección del router de salida del túnel Outbound que el emisor ha utilizado para la entrega del mensaje). Esto permite extender un poco los campos que se pueden incluir en un mensaje I2NP, dado que estos mensajes son “crudos” y no suministran este tipo de información por “seguridad”.

No hay que olvidar que estos protocolos se encuentran por encima de la capa I2P Cliente, y NO dependen de los protocolos de bajo nivel como los que se encuentran en la capa de transporte dado que estos protocolos son convertidos en mensajes I2NP por el router y de esta forma estos mismos protocolos pueden ser “replicados” a las capas inferiores sin ningun problema.

Capa I2P Client:

Se trata de una capa que adiciona funcionalidad extra a todo el compendio de aplicaciones que se ejecutan en la capa de presentación, de tal forma que cualquier cliente pueda utilizar las funcionalidades I2P sin requerir el uso directo del API del router. El protocolo soportado en esta capa es I2CP que permite mensajería segura y asíncrona enviando cada mensaje sobre un socket TCP de I2CP. Este concepto es muy similar al Control Protocol de TOR en donde se abre un puerto elegido por el usuario, para que un relay determinado pueda acceder a la instancia y posteriormente administrarla de forma remota, en este caso sucede algo similar, este protocolo permite que clientes que se ejecuten por fuera de la máquina virtual de Java que administra el proceso de I2P en ejecución puedan conectarse remotamente. Es importante anotar en este punto, que por defecto este protocolo se encuentra ACTIVADO y no implementa ningún mecanismo de autenticación, lo que deja el servicio abierto a cualquiera, evidentemente no es una situación recomendable, por lo tanto se aconseja establecer autenticación por password en la interfaz de administración de I2P en: http://127.0.0.1:7657/configclients tal como muestra la siguiente imagen:

Capa de Interfaz de Aplicación I2P

Se trata librerías adicionales que permiten una fácil integración de los clientes que pertenecen a la capa de aplicación del modelo de referencia OSI con las capas inferiores del modelo. En esta capa se encuentran aplicaciones de las que ya se ha hablado con anterioridad como I2PTunnel y otros de los que se hablará en próximas entradas tales como BOB y SAM/SAMv2/SAMv3.

Capa de Proxy de Aplicación I2P.

Como su nombre lo indica, son simplemente todos los elementos que se establecen en medio de clientes y la aplicación, frecuentemente estos elementos suele ser un proxy SOCKS, HTTP o HTTPS

La siguiente imagen enseña el modelo completo de la arquitectura de I2P con todos sus elementos incluyendo aquellos que no hacen parte de forma estricta a la pila de protocolos base.

Como se puede apreciar, en rojo aparecen las extensiones adicionales a la pila de protocolos y su función en el modelo.