Introducción

I2P es una capa de red auto organizada, resistente, anónima, dentro de la cual pueden funcionar un gran número de aplicaciones con diferentes modelos de seguridad y anonimato. Cada una de estas aplicaciones pueden usar sus propios niveles de seguridad y sus propios niveles de rendimiento, sin preocuparse por crear una implementación apropiada de una red libre, permitiendoles mezclar sus actividades con un gran número de usuarios anónimos que ya utilizan I2P.

Las aplicaciones ya disponibles proveen un espectro completo de aplicaciones usadas típicamente en Internet - navegación web anónima, alojamiento web, chat, compartición de ficheros, correo electrónico, blogs y sindicación de contenidos, grupos de noticias (news), así como otras cuantas aplicaciones en desarrollo.

  • Navegación web: usando cualquier navegador que soporte un proxy.
  • Chat: IRC, Jabber. VOIP, I2P-Messenger.
  • Compartir archivos: I2PSnark, Robert, iMule, I2Phex, PyBit, I2P-bt y otros
  • Email: susimail and I2P-Bote.
  • Blogs: usando el pluguin pebble o la aplicación distribuida
  • Almacenamiento de datos distribuido: Guarde sus datos redundantemente en Tahoe-LAFS sobre I2P.
  • Grupos de noticias: Usando cualquier lector de grupos de noticias (news) que soporte el uso de proxy.

Unlike web sites hosted within content distribution networks like Freenet or GNUnet, the services hosted on I2P are fully interactive - there are traditional web-style search engines, bulletin boards, blogs you can comment on, database driven sites, and bridges to query static systems like Freenet without needing to install it locally.

Con todos estas aplicaciones anónimas habilitadas, I2P toma el rol de aplicación mensajera, una aplicación, por ejemplo, dice que quiere enviar datos a un identificador criptográfico (un "destino") e I2P se encarga de asegurarse de que lleguen seguros y anónimos. I2P también ofrece un librería simple de streaming que permite que los mensajes sean enviados como streams fiables y ordenados, ofreciendo transparentemente algoritmos de control de congestión TCP ajustados para el retardo de alto de bandda de producto de la red. Aunque hay proxys SOCKS para usar casi cualquier aplicación con I2P estas se han limitado, ya que la mayoría de las aplicaciones muestran, lo que se llama en el contexto anónimo, información sensible. La única forma segura de usar aplicaciones externas sería comprobar completamente la aplicación para asegurarse que funciona bien, y para ayudar con este problema proporcionamos una serie de APIs en varios idiomas que pueden usarse para sacarle el mayor provecho a la red.

I2P no es un proyecto de investigación - académico, comercial o gubernamental. En cambio es un esfuerzo de ingeniaría enfocado en hacer lo posible para ofrecer un nivel decente de anonimato para aquellos que lo necesitan. Lleva en desarrollo activo desde el 2003 con un programador a tiempo completo y un grupo de contribuidores a tiempo parcial de todo el mundo. Todo el trabajo realizado es software libre y disponible gratuitamente en la web. La mayoría del código es de dominio público, excepto algunas rutinas de cifrado que usan licencias del estilo BSD. La gente trabajando en I2P no controla bajo qué licencias libera la gente sus aplicaciones clientes, y hay varias aplicaciones GPL disponibles (I2PTunnel, susimail, I2PSnark, I2P-Bote, I2Phex y otras.). El financiamiento viene en su totalidad de donaciones, y por el momento no recibe ninguna rebaja de impuestos en ninguna jurisdicción, ya que la mayoría de los programadores son anónimos.

Cómo funciona

Vista general

Para entender como funciona I2p es esencial entender varios conceptos. Primero, I2P hace una separación completa entre las aplicaciones usadas en la red (un "ruter") y los puntos finales anónimos ("destinaciones") asociados a las aplicaciones individuales. El hecho de que alguien ejecute I2P normalmente no es un secreto. Lo que se oculta es la información y lo que hace el usuario, así como las destinaciones particulares a la que se conecta el ruter. Los usuarios finales tendrán normalmente varias destinaciones locales en su ruter - por ejemplo, una destinación conectando con servidores IRC, otras para las webs anónimas (eepsites), otra para I2Phex, otra para los torrets, etc.

Otro concepto crítico a entender es el concepto de "túnel". Un túnel es un camino directo a través de una lista seleccionada y explícita de ruters. Se usa un cifrado por capas, por lo cual cada ruter sólo puede descifrar una capa. La información descifrada contiene la IP del ruter siguiente, así como la información cifrada para ser enviada. Cada túnel tiene un punto de inicio (el primer ruter, también conocido como "gateway") y un punto final. Los mensajes sólo se pueden enviar en una dirección. Para enviar un mensaje de respuesta se debe crear un nuevo túnel.

Esquema de túneles de entrada y salida

Figura 1: Existen 2 tipos de túneles: de entrada y de salida.

Existen 2 tipos de túneles: túneles "outbound", de salida envían mensajes hacia fuera desde el creador de túneles, mientras que túneles "inbound", de entrada llevan los mensajes hasta el creador de túneles . Combinando estos 2 túneles los usuarios pueden enviar mensajes a otros usuarios. El remitente ("Alice" en la imagen anterior) crea un túnel de salida, mientras que el receptor ("Bob" en la imagen de arriba) crea un túnel entrante. La puerta de salida de un túnel de entrada puede recibir mensajes de cualquier usuario que serán enviados hasta en punto final ("Bob"). El punto final del túnel de salida necesita enviar el mensaje a la puerta de salida del túnel de entrada. Para conseguir esto, el remitente ("Alice") añade instrucciones al mensaje cifrado. Una vez que el punto final y el túnel de salida descifran el mensaje, tendrán las instrucciones para poder enviar el mensaje la puerta de salida de entrada correcta (la puerta de salida hacia "Bob").

Un tercer concepto crítico es el de la "base de datos de la red" (o "netDb") - un par de algoritmos hechos para compartir los datos de la red. Los 2 tipos de datos compartidos son "routerInfo" y "leaseSets" - la información del ruter, ruterinfo, da a los ruters la información necesaria para poder contactar con un ruter en particular (sus claves públicas, dirección de transporte, etc), mientras que el leaseSet le da a los ruters un número de "leases", asignaciones. Cada una de estas asignaciones especifica una puerta de salida de un túnel, la cual permite alcanzar una destinación específica. La información completa en un lease es:

  • Gateway de entrada para un túnel que permite alcanzar una destinación específica.
  • Tiempo de espiración del túnel.
  • Par de claves públicas para poder cifrar el mensaje (para enviarlo a través del túnel y alcanzar su destino).

Los ruters envían su routerInfo directamente a la netDB, mientras que los leaseSets son enviados a través de los túneles de salida (los leaseSets tienen que ser enviados anónimamente para evitar la correlación del ruter con sus leaseSets)

Podemos combinar los anteriores conceptos para construir conexiones dentro de la red.

Para crear sus propios tuneles de entrada y salida, Alice no mira en la netDB para obtener la información. Ella obtiene listas de pares que puede usar como saltos en sus túneles. Entonces puede enviar un mensaje de construcción al primer salto, solicitando la construcción de un túnel y pidiendo a ese ruter que siga adelante con la construcción del mensaje, hasta que el túnel ha sido construido.

Obtiene indormacón sobre otros ruters                     Construye el túnel usando la información del ruter

Figura 2: La información del ruter es usada para construir túneles.

Cuando Alice quiere enviar un mensaje a Bob, primero mira en la netDB hasta encontrar la leaseSet de Bob, dando sus propias gateways de entrada. Entonces ella elije uno de los túneles de salida y envía su mensaje con instrucciones para que el punto final de túnel de salida reenvíe el mensaje a unos de las gateways de entrada de BoB. Cuando el punto final del túnel de salida recibe estas instrucciones, reenvía el mensaje como se ha pedido, y cuando el la gateway del túnel de entrada de Bob lo recibe, es enviado hasta el ruter de Bob. Si Alice quiere que Bob pueda responder al mensaje necesita transmitir explícitamente su propia destinación como parte del mensaje. Esto puede hacerse introduciendo una capa de nivel superior, lo cual se hace en la librearía de streaming. Alice también puede acortar el tiempo de respuesta construyendo su LeaseSet mas reciente con el mensaje, con lo cual Bob no necesita mirar en la netDB para responder, pero esto es opcional.

Conectando túneles usando LeaseSets

Figura 3: Los LeaseSets son usados para conectar los túneles de entrada y salida.

Mientras que los túneles están cifrados en capas para prevenir ser revelados sin permiso a otros pares de la red (ya que la capa de transporte en sí misma no previene la muestra no autorizada a pares fuera de la red), es necesario añadir un final adicional a la capa de cifrado final para ocultar el mensaje del punto final del túnel de salida y de la puerta de salida del túnel de entrada. Este "cifrado garlic" permite al ruter de Alice envolver varios mensajes en un simple "mensaje garlic", cifrado para una calve pública en particular y así los pares intermediarios no pueden determinar cuantos mensajes hay dentro del mensaje garlic, que dicen esos mensajes, o a donde están destinados los mensajes individuales. Para una comunicación típica entre Alice y Bob, el garlic será cifrado con la clave pública publicada en el leaseSet de bob, permitiendo que el mensaje sea cifrado sin dar la clave pública al dueño del ruter de Bob.

Otra cosa importante a tener en cuenta es que I2P esta totalmente basado en mensajes y que algunos mensajes se pueden perder a lo largo del camino. Las aplicaciones que usan I2P pueden usar el interfaz orientado a mensajes y cuidar de su propio control de congestión y necesidades de fiabilidad, pero la mayoría estaría más satisfecha reutilizando la librería de streaming que proveemos para ver I2P como una red basada en streams.

Túneles

Ambos túneles, de entrada y de salida funcionan con los mismos principios. La puerta de salida del túnel acumula un número de mensajes, eventualmente pre procesandolos para poder ser entregados. Después, la puerta de salida cifra esa información pre procesada y la envía al primer salto. El par y los siguientes túneles participantes añaden una capa de cifrado después de verificar que no es duplicado y antes de enviarlo al siguiente par. Eventualmente, este mensaje llega al punto final, donde el mensaje es dividido de nuevo y enviado conforme a lo solicitado. La diferencia surge en lo que hace el creador del túnel - para los túneles de entrada, el creador es el punto final y simplemente descifra todas las capas añadidas, mientras que para los túneles de salida, el creador es la puerta de salida y pre descifra todas las capas con lo que después de que todos las capas de cifrado por salto son añadidas, el mensaje llega en claro al túnel de punto final.

La elección de los pares específicos par pasar los mensajes al igual que su orden es importante para entender el anonimato y el rendimiento de I2P. Mientras que la base de datos de la red (debajo) tiene su propio criterio al elegir en qué pares consultar y almacenar entradas, los creadores de los túneles pueden usar cualquier par en la red y en cualquier orden (e incluso cualquier número de veces) en un solo túnel. Si se conocen globalmente la latencia exacta y capacidad de datos, la selección del orden vendrá dada por las necesidades particulares del cliente y su modelo de seguridad. Desafortunadamente, no es trivial obtener anónimamente la latencia y la capacidad de datos, y al dependerse de pares no confiables para obtener esta información crea serios problemas en el anonimato.

Desde la perspectiva del anonimato, la técnica más simple sería elegir pares aleatoriamente de toda la red, ordenarlos aleatoriamente y usar esos pares en ese orden eternamente. Desde la perspectiva del rendimiento, la técnica más simple sería elegir los pares más rápidos con la capacidad necesaria, repartiendo la carga entre varios pares para manejar transparentemente los fallos, y para reconstruir el túnel cuando cambie la información sobre la capacidad disponible. Mientras que el primer modelo es frágil y deficiente, el segundo necesita información no accesible y no ofrece suficiente anonimato. I2P en cambio funciona ofreciendo un amplio abanico de estrategias de selección de pares, junto con código que tienen en cuenta el nivel de anonimato para organizar los pares y sus perfiles.

Por defecto I2P está constantemente comprobando los pares con los que interactúa y midiendo su comportamiento - por ejemplo, cuando un par responde a una búsqueda de netBD en 1,3 segundos, la latencia de vuelta es guardada en los perfiles de todos los ruters implicados en los 2 túneles (de entrada y de salida) por los que la respuesta ha pasado, así como el perfil del par consultado. Las mediciones directas, como el retardo de la capa de transporte o la congestión, no se usan como parte del perfil, ya que puede manipularse y ser asociada con el ruter que está midiendo, exponiéndolo a ataques triviales. Mientras se calculan estos perfiles, una serie de cálculos se ejecutan en cada uno para resumir su rendimiento - su latencia, su capacidad para manejar la pérdida de actividad, si está saturado, y cómo de bien está integrado dentro de la red. Estos cálculos son entonces comparados por los pares activos para organizar los ruters en 4 niveles - rápido y con gran capacidad, gran capacidad, sin caídas y con caídas. Los umbrales de estos niveles son determinados dinámicamente, y mientras que se usan algoritmos bastantes sencillos también existen otras alternativas.

Using this profile data, the simplest reasonable peer selection strategy is to pick peers randomly from the top tier (fast and high capacity), and this is currently deployed for client tunnels. Exploratory tunnels (used for netDb and tunnel management) pick peers randomly from the "not failing" tier (which includes routers in 'better' tiers as well), allowing the peer to sample routers more widely, in effect optimizing the peer selection through randomized hill climbing. These strategies alone do however leak information regarding the peers in the router's top tier through predecessor and netDb harvesting attacks. In turn, several alternatives exist which, while not balancing the load as evenly, will address the attacks mounted by particular classes of adversaries.

Tomando una clave aleatoria y ordenando los pares de acuerdo a su distancia XOR de ella, la información expuesta es reducida en los ataques del predecesor y de cosechado conforme a la velocidad de fallo del par y de su mezcla de niveles. Otra estrategia simple para tratar con el ataque del cosechado de la netDB es simplemente fijando la puerta de salida(s) de túnel de entrada, ya sea aleatorizando los pares más lejos o en los túneles. Para tratar con el ataque del predecesor por adversarios con los que contacta el cliente, los puntos finales del túnel de salida deberían permanecer también fijos. Para seleccionar que par fijar en el punto más expuesto se necesitará, por supuesto, un límite de duración ya que todos los pares fallan más tarde o más temprano, con lo cual podría ser ajustado de manera reactiva o evitado de manera activa, para imitar el tiempo medio de los fallos de otros ruters. Estas 2 estrategias pueden ser combinadas en turnos, usando un par expuesto fijo y un orden basado en XOR dentro de los propios túneles. Una estrategia más rígida sería fijar los pares justos y ordenarlos en un túnel potencial, sólo usando pares individuales si todos están de acuerdo en participar de la misma forma cada vez. Esto varía del ordenado basado en XOR en que el predecesor y sucesor de cada par es siempre el mismo, mientras que el XOR asegura que el orden no cambie.

Como se ha mencionado anteriormente, actualmente I2P (versión 0.8) incluye la estrategia anterior de nivelado aleatorio, con ordenado basado en XOR. Una discusión más detallada en los mecanismos de la utilización, administración y selección de los pares de los túneles puede ser encontrada en las especificaciones del túnel.

Base de datos de la red

Como se ha dicho antes, las netDB de I2P trabaja para compartir los metadatos de la red. Esto se detalla en the network database, pero una explicación básica está disponible debajo.

Un porcentaje de los usuarios de I2P son designados como 'pares floodfill'. Actualmente, las instalaciones de I2P que tienen un gran ancho de banda y son suficientemente rápidas se designarán ellas mismas como floodfills tan pronto como el número de de ruters floodfill existentes decrezca demasiado.

Otros rutes I2P almacenarán sus datos y sus datos de búsqueda simplemente enviando consultas 'store' y 'lookup' a los floodfills. Si un floodfill recibe una consulta 'store', este difundirá la información a otros ruters floodfill usando el algoritmo Kademlia. Las consultas 'lookup' funcionan de manera diferente para evitar un problema de seguridad importante. Cuando se hace una búsqueda, el ruter floodfill no re enviará la búsqueda a otros pares, pero siempre responderá él mismo (si tiene la información requerida).

En la base de datos de la red se almacenan dos tipos de información.

  • RouterInfo almacena información sobre un ruter I2P determinado y como contactar con él.
  • LeaseSet almacena información sobre una destinación específica (e.g. web I2P, servidor de correo...)

Toda esta información es firmada par la parte publicadora y verificada por cualquier ruter I2P que use o almacene la información. Además, los datos contienen información de la hora para evitar el almacenamiento de entradas antiguas y posibles ataques. Esto es por que I2P empaqueta el código necesario para mantener la fecha correcta, a veces consultando algunos servidores SNTP (por defecto pool.ntp.org) y detectando diferencias entre los ruters y la capa de transporte.

Hay algunos comentarios adicionales que también son importantes:

  • Leasesets cifrados y no publicados:

    Uno puede desear que sólo determinada gente sea capaz de alcanzar una destinación. Esto es posible si no publica su destinación en la netDB. Pero entonces deberá transmitir la destinación de alguna otra forma. Una alternativa son los 'leaseSets' cifrados. Estos leaseSets' sólo pueden ser decodificados por la gente con acceso a la clave de descrifrado.

  • Obteniendo los pares iniciales o Bootstrapping:

    Bootstrapping en la netDB es muy simple. Una vez que un ruter recibe un routerInfo de un par accesible, puede consultar a ese ruter por referencias de otros ruters en la red. Actualmente varios usuarios comparten sus archivos routerInfo en una web para hacer que la información esté disponible. I2P se conecta automáticamente a una de estas webs para obtener los archivos routerInfo y obtener los primeros pares, bootstrap.

  • Escalabilidad de las búsquedas:

    Las búsquedas en la red I2P no son enviadas a otras netDBs de otros ruters. Actualmente no hay ningún problema ya que la red no es muy grande. Aún así, según vaya creciendo la red no todos los routerInfos y leaseSets estarán presentes en cada netDB de cada ruter. Esto causaría un deterioro en el porcentaje de búsquedas con éxito. A causa de esto en las prósimas versiones se mejorará la netDB.

Protocolos de transporte

La comunicación entre ruters necesita proporcionar confidencialidad e integridad contra cualquier adversario externo mientras se autentifica que el ruter contactado es el que debe recibir el mensaje. Los detalles de como se comunican los ruters con otros ruters no son críticos - se han usado tres protocolos diferentes en varios puntos para suplir estas necesidades.

I2P comenzó con un protocolo basado en TCP que ha sido deshabilitado. Luego, para adaptarse a las necesidades de comunicaciones de alto nivel (ya que un cierto número de routers I2P terminarán hablando con otros muchos), I2P cambió de un transporte basado en TCP a uno basado en UDP - "Secure Semireliable UDP" (UDP seguro semifiable) o "SSU".

Como se describe en la especificación de SSU:

La meta de este protocolo es proporcionar la entrega de mensajes de forma segura, con autentificación, semifiable y no ordenada, revelando sólo una pequeña cantidad de datos fácilmente discernible para terceras partes. Debe soportar comunicaciones de alto nivel así como sistemas de control de congestión adaptados-a-TCP, y puede incluir también detección de PMTU (máxima unidad de transferencia de la red). Debe ser capaz de mover eficientemente un gran volumen de datos a velocidades suficientes para los usuarios domésticos. Además debe soportar técnicas para afrontar los obstáculos en la red, como la mayoría de NATs (traductores de direcciones de red) o de cortafuegos (firewalls).

Tras la introducción de SSU, y después de aparecer algunos problemas de congestión, se implementó un nuevo transporte TCP basado en NIO llamado NTCP. Está activado por defecto sólo para las conexiones de salida. Aquellos que configuran sus NAT/firewall para permitir conexiones de entrada y especifican el puerto y host externo (dyndns/etc es válido) en /config.jsp pueden recibir conexiones de entrada. Al estar NTPC basado en NIO no sufre del problema de "1 hilo por conexión" del viejo protocolo de transporte TCP.

I2P soporta simultáneamente varios tipos de transportes. Para conexiones de salida se selecciona un determinado tipo de transporte a través de "pujas". Cada tipo de transporte puja por la conexión y el valor relativo de esa puja asignará la prioridad. Los transportes pueden responder con varias apuestas, dependiendo de si ya hay una conexión establecida con el par.

La implementación actual clasifica en la mayoría de las situaciones a NTPC como el sistema de transporte de mayor prioridad para conexiones de salida. SSU está activo para las conexiones de entrada y de salida. Su cortafuegos y su ruter I2P tienen estar configurados para permitir conexiones de entrada NTCP. Para más información vea la ṕagina de NTCP.

Cifrado

Un conjunto mínimo de cifrados son combinados para proveer a I2P defensas contra varios adversarios. En el nivel más bajo la comunicación entre ruters es protegida por la capa de seguridad de transporte - SSU cifra cada paquete con AES256/CBC incluyendo un IV explícito y MAC (HMAC-MD5-128), después de haber acordado una clave de sesión efímera a través de un intercambio Diffie-Hellman de 2048bit, autenticación de estación a estación con la clave DSA de los otros ruters, y además cada mensaje de red tiene su propio hash para comprobar la integridad local. Los mensajes de túnel ya transportados tienen su propio cifrado por capas AES256/CBC con un IV explícito verificado en el punto final del túnel con un hash adicional SHA256. Otros ciertos mensajes son pasados dentro del "mensaje garlic" y son cifrados con ElGamal/AES+Etiquetas de sesión (explicado más abajo).

Mensajes Garlic

Los mensajes Garlic son una extensión de la capa de cifrado "onion", permitiendo que el contenido de un simple mensaje contenga múltiples "dientes" - mensajes formados completamente y con sus propias instrucciones para el envío. Los mensajes son envueltos dentro de un mensaje Garlic ya que de otra forma deberían enviarse en texto plano a través de un par que no tiene que por que tener acceso a esa información - por ejemplo, cuando un ruter quiere preguntar a otro ruter si participa en un túnel, envuelven la solicitud dentro del garlic, y lo envían a través de un túnel. Otro ejemplo es cuando un cliente quiere enviar un mensaje a una destinación - el ruter del remitente envolverá los datos del mensaje (junto con otros mensajes) dentro de un garlic, cifrará ese garlic con la clave pública de 2048bit ElGamal publicada en el leaseSet del beneficiario, y lo enviará a través de los túneles apropiados.

Las "instrucciones" adjuntas a cada diente, 'clove', dentro de la capa de cifrado incluyen la habilidad de solicitar que el diente sea enviado localmente a un ruter remoto, o a un túnel remoto en un ruter remoto. Hay campos en esas instrucciones que permiten a un par solicitar que el envío sea retrasado un cierto tiempo o hasta que se cumpla cierta condición, pero no funcionará hasta que los retardos no triviales funcionen en estas versiones. Es posible enrutar explícitamente mensajes garlic de cualquier número de saltos sin construir túneles, o incluso re enrutar mensajes de túnel envolviéndolos en un mensaje garlic y enviándolos por unos cuantos saltos antes de enviarlos al siguiente salto en el túnel, pero estas técnicas no se usan en en las implementaciones existentes.

Etiquetas de sesión

Como el sistema basado en mensajes no ordenados y no fiables que es, I2P usa una simple combinación de algoritmos de cifrado simétricos y asimétricos para proporcionar la confidencialidad de los datos y la integridad de los mensajes garlic. En conjunto, a la combinación se le llama ElGamal/AES+SessionTags, pero es una forma excesivamente larga de describir el uso del 2048bit ElGamal, AES256, SHA256 y nonces (números de único uso) de 32 bytes.

La primera vez que un ruter quiere cifrar un mensaje para otro ruter, estos cifran las claves para una clave de sesión AES256 con ElGamal y adjunta la payload ya cifrado AES256/CBC después del bloque cifrado ElGamal. Además del payload cifrado, las sección del cifrado AES contiene el tamaño de la carga, el hash SHA256 del payload no cifrado, así como el número de "etiquetas de sesión" - nonces aleatorios de 32 bits. La siguiente vez que el remitente desea cifrar un mensaje garlic para otro ruter, en vez de de cifrar una nueva clave de sesión con ElGamal, simplemente elijen una de las etiquetas enviadas de la sesión anterior y cifran con AES el payload como anteriormente, usando la clave de sesión usada con la etiqueta de la sesión, antepuesto con la misma etiqueta de sesión. Cuando un ruter recibe un mensaje cifrado garlic, comprueba los primeros 32 bytes para ver si coinciden con una etiqueta de sesión disponible - si lo hace, simplemente descifran el mensaje con AES, pero si no, descifran el primer bloque con ElGamal

Cada etiqueta de sesión puede usarse sólo una vez para evitar que adversarios internos puedan relacionar diferentes mensajes al enviarse estos entre los mismos ruters. El remitente de un mensaje cifrado con etiqueta de sesión + ElGamal/AES elije cuando y cuantas etiquetas a enviar, poniendo a disposición del que recibe suficientes etiquetas para trabajar con un buen número de mensajes. Los mensajes Garlic pueden detectar la llegada exitosas de las etiquetas construyendo un mensaje adicional tipo clove (un "mensaje de estado de entrega") - cuando el mensaje llega al destinatario elegido y es descifrado correctamente, este pequeño mensaje de estado de entrega es uno de los dientes expuestos y tiene instrucciones para el destinatario para que retorne al remitente original (a través de un túnel de entrada, claro). Cuando el remitente original recibe el mensaje de estado de envío, sabe que la etiqueta de sesión incluida en el mensaje garlic ha sido enviada exitosamente.

Las etiquetas de sesión tienen un vida muy corta, después de la cual son descartadas y no se usan más. Además, el número almacenado de ellas por cada clave es limitado, como también está limitado el número de claves - si llegan demasiadas, serán descartados los mensajes nuevos o los viejos. El remitente lleva el seguimiento de los mensajes con etiquetas de sesión que pasan a través suyo, y si no hay comunicación suficiente podría descartar los mensajes supuestamente enviados correctamente, volviendo al costoso cifrado ElGamal.

Una alternativa sería transmitir sólo una etiqueta de sesión, y desde ahí sembrar un PRNG determinista para determinar que etiquetas usar o esperar. Manteniendo este PRNG bien sincronizado entre el remitente y el receptor (el receptor precalcula por ejemplo las siguiente 50 etiquetas) se evita la saturación de tener que calcular un gran número de etiquetas, permitiendo más opciones en ese espacio/tiempo de intercambio, y quizás reduciendo el número de cifrados necesarios de ElGamal. Sin embargo, dependerá de la fortaleza de PRNG de proteger contra adversarios internos, quizás limitando las veces que se usa cada PRNG se podrían limitar las debilidades. Hasta el momento no hay planes inmediatos para cambiar a estos PRNGs sincronizados.

El futuro

Mientras que I2P es suficientemente funcional en mucho escenarios, hay varias áreas en las que requiere mejoras, como cubrir las necesidades de aquellos que se enfrentan a adversarios poderosos o mejorar la experiencia del usuario.

Funcionamiento restringido del ruter

I2P es una red designada para ejecutarse sobre una red conmutada de paquetes funcionales, usando el principio de fin a fin para ofrecer anonimato y seguridad. Mientras que Internet ya no abraza el principio de fin a fin (por el uso de NAT), I2P necesita tener a su disposición una gran parte de la red - puede haber algunos pares ejecutándose en los bordes usando ruters restringidos no accesibles, pero I2P no incluye un algoritmo apropiado de enrutamiento para el extraño caso de que la mayoría de los pares no sean accesibles. Aún así podría funcionar sobre una red que utilizase dicho algoritmo.

El funcionamiento restringido del ruter, donde hay límites en el número de ruters que son accesibles directamente, tiene varias funciones e implicaciones en el anonimato dependiendo do como sean manejados los ruters restringidos. En el nivel más básico los ruters restringidos existen cuando un par está tras un NAT o cortafuegos que no permiten conexiones entrantes. Esto fue solucionado en I2P 0.6.0.6 al integrar "perforación" distribuida en la capa de transporte, permitiendo a la gente tras NATs o cortafuegos recibir conexiones no solicitadas sin ninguna configuración. Aún así esto no limita la exposición de la IP de lo pares a los ruters dentro de la red, ya que estos pueden presentarse a sí mismos al par a través del introductor ya publicado.

Más allá del manejo funcional de ruters restringidos hay 2 niveles de operaciones restringidas que pueden usarse para limitar la exposición de la dirección IP - usando túneles específicos para la comunicación y ofreciendo 'ruters cliente'. En el primer caso, los ruters pueden, o construir un nuevo conjunto de túneles o reutilizar su conjunto de túneles publicando la gateway de entrada a algunos de ellos como parte de su routerInfo en lugar de su dirección de transporte. Cuando un par quiere ponerse en contacto con él, puede ver esas puertas de salida de los túneles en la netDb y simplemente enviar el mensaje a través de uno de los túneles publicados. Si el par detrás del ruter restringido quiere conectarse, puede hacerlo directamente (si desea exponer su IP al otro par) o indirectamente a trabés de sus túneles de salida. Cuando los ruters con los tienen conexión directa quieren contactarlo (por ejemplo para enviar mensajes de túnel), simplemente prioriza su conexión directa sobre la puerta la puerta de salida del túnel ya publicada. El concepto de 'ruters cliente' simplemente amplía la ruta restringida no publicando ninguna dirección de ruter. Este tipo de ruters ni siquiera necesita publicar si routerInfo en la netDb, simplemente proveyendo su routerInfo firmado por sí mismo al par con el que contacta (esto es necesario para pasar las claves públicas del ruter). Ambos niveles de operaciones restringidas del ruter están planeadas para la versión 2.0 de I2P.

Existen inconvenientes para aquellos detrás de ruters restringidos ya que participarán menos frecuentemente en los túneles de otra gente, y los ruters a los que está conectado podrían ser capaces de descubrir patrones en el tráfico que de otra forma no podrían verse. Por otro lado, si el coste de exponer esos patrones es menor que el coste de de hacer que la IP esté disponible, puede valer la pena. Esto, por supuesto, suponiendo que los pares de los ruters con los que contacta el ruter restringido no son hostiles - o por que la red es suficientemente grande como para que la probabilidad de conectarse a un ruter hostil sea muy pequela, o porque se usan pares de confianza (y quizás temporales).

Latencia variable

Incluso aunque la mayoría de los esfuerzos iniciales han sido para que I2P tenga una comunicación de baja latencia, fue diseñado desde el principio para servicios de latencia variable. Al nivel más básico, las aplicaciones corriendo sobre I2P pueden ofrecer anonimato en comunicaciones de media y alta latencia mientras mezcla su tráfico con tráfico de baja latencia. Sin embargo, internamente I2P puede ofrecer sus comunicaciones de media y alta latencia a través de su cifrado garlic - especificando que el mensaje debe ser enviado después de un cierto retraso, en un determinado momento, después de que hayan pasado cierto número de mensajes o cualquier otra estrategia de mezclado. Con el cifrado por capas sólo el ruter que hizo la petición de retraso sabrá que el mensaje requiere alta latencia, permitiendo que el tráfico se mezcle más con el tráfico de baja latencia. Una vez que la condición de transmisión se cumple, el ruter que mantiene el 'clove' (que en sí mismo podría ser como un mensaje garlic) simplemente envía su petición - a un ruter, a un túnel, o, lo más probable, a una destinación cliente remota.

Hay un número bastante grande de formas de explotar esta capacidad de comunicación de alta latencia en I2P, por el momento, hacerlo se ha postergado hasta la versión 3.0 de I2P. Mientras tanto, aquellos que requieran el anonimato que las comunicaciones de alta latencia pueden ofrecer deben mirar en la capa de aplicación para obtenerlo.

Preguntas sin resolver

  • ¿Cómo deshacerse de la restricción de tiempo?
  • ¿Podemos manejar más eficientemente las etiquetas de sesión?
  • ¿Cuales, si hay alguna, estrategias de mezclado deberían estar disponibles en los túneles?
  • ¿Qué otras estrategias de selección de túneles de pares deberian estar disponibles?

Sistemas similares

La arquitectura de I2P está basada en el concepto de software orientado a mensajes, la topología de DHTs, el cifrado y anonimato de redes de mezcla libres, y la adaptabilidad de las redes conmutadas de paquetes. Su valor no reside en nuevos conceptos o algoritmos, sino en la cuidadosa combinación de resultados de investigación de trabajos y sistemas ya existentes. Mientras que hay varios esfuerzos similares a los que vale la pena echar un ojo, se han elegido 2 en particular para comparaciones técnicas y funcionales - Tor y Freenet.

Ver también la web de comparación entre redes.

Tor

página web

A primera vista, Tor e I2P tienen muchas similitudes en lo que se refiere a funcionamiento y anonimato. Aunque I2P se empezó a desarrollar antes eramos conscientes de los esfuerzos hechos al inicio de Tor, muchas de las lecciones aprendidas de la red onion original y ZKS fueron integradas en el diseño de I2P. En vez de construir un sistema centralizado y de confianza con servidores de directorios, I2P tiene su propia base de datos de red auto organizable en la que cada par toma la responsabilidad de acceder al perfil de otros ruters para determinar como aprovechar los recursos disponibles. Otra diferencia básica es que mitras I2P y Tor usan rutas ordenadas y en capas (túneles y circuitos/streams), I2P es fundamentalmente una red conmutada de paquetes, mientras que Tor es fundamentalmente un circuito conmutado, permitiendo a I2P enrutar evitando congestiones y otros fallos de la red transparentemente , operar en vías redundantes, y hacer balance de carga de los datos a través de los recursos disponibles. Mientras que Tor ofrece una funcionalidad tan útil como el outproxy ofreciendo el descubrimiento y selección de outproxy integrado, I2P deja esas decisiones sobre la capa de aplicación a las aplicaciones ejecutándose sobre I2P - de hecho, I2P incluso ha exteriorizado la librería de streaming tipo TCP a la capa de aplicación, permitiendo a los desarrolladores el experimentar con diferentes estrategias, usando el conocimiento específico de dominio para ofrecer mejores rendimientos.

Desde el punto de vista del anonimato, cuando comparamos el núcleo de las redes hay muchas similaridades entre ellos. Pero hay unas cuantas diferencias claves. Cuando se trata de lidiar con adversario interno o varios adversarios externos observando los propios flujos de datos, los túneles simples de I2P exponen la mitad de información en el tráfico de lo que exponen los circuitos dobles de Tor - una petición y respuesta HTTP seguirían el mismo camino en Tor, mientras que I2P el paquete que hace la consulta iría a través de uno o más túneles y el paquete con la respuesta regresarían a través de otro o más túneles de entrada diferentes. Mientras que la selección del orden y estrategias por parte del par deberían ser suficientes para enfrentarse a los ataques de predecesor, podríamos simplemente construir un túnel de entrada y de salida a través de los mismos ruters.

Otro problema para el anonimato aparece en el uso por parte de Tor de la creación telescópica de túnel, un simple contador y medidor de tiempo de los paquetes que pasan a través de un nodo enemigo puede obtener información estadística sobre la posición de la víctima en el circuito. La creación unidireccional para cada mensaje en I2P hace que esta información no sea expuesta. Ocultar la posición de un túnel es importante, ya que un adversario podría montar una serie de potentes ataques como el de predecesores, intersección y confirmación de tráfico.

El soporte de Tor de un segundo nivel de "onion proxies" ofrece un grado de anonimato nada trivial, mientras que requiere un bajo coste de entrada, mientras que I2P no ofrecerá este tipo de topoligía hasta la versión 2.0.

En conjunto, Tor e I2P se complementan el uno al otro - Tor funciona ofreciendo outproxing a Internet de alta velocidad y anónimo, mientras que I2P ofrece una red resistente y descentralizada dentro de sí mismo. En teoría se pueden usar los 2 para obtener los mismos fines, pero dados los limitados recursos de desarrollo, ambos tienen sus ventajas e inconvenientes. Los desarrolladores de I2P han considerado los pasos necesarios para modificar Tor para para la mejora del diseño de I2P, pero preocupaciones sobre la viabilidad de Tor con bajo escasos recursos sugiere que la arquitectura de enrutamiento de paquetes de I2P será capaz de funcionar más eficientemente con recursos escasos.

Freenet

página web

Freenet jugó un rol importante en los primeros pasos del diseño de I2P - mostrando pruebas de la viabilidad de una comunidad vibrante completamente dentro de la red, mostrando que los peligros inherentes de los outproxies podían ser evitados. La primera semilla de I2P comenzó como el remplazo de una capa de comunicación para Freenet, al intentar extraer la complejidad de una comunicación de punto a punto segura y anónima de las complicaciones del almacenamiento distribuido resistente a la censura. Aunque la final, algunos de los problemas de escalabilidad y anonimato inherentes a los algoritmos de Freenet dejó claro que debería enfocarse I2P para proveer una capa de comunicación anónima por sí misma en vez de ser un componente de Freenet. A través de los años, los desarrolladores de Freenet se han dado cuenta de las debilidades del viejo diseño, provocando que sugiriese la necesidad de una capa de "pre mezcla" para ofrecer el suficiente anonimato. En otras palabras, Freenet debe ejecutarse sobre una mixnet como I2P o Tor, con "nodos cliente" solicitando y publicando datos a través de la mixnet a los "nodos servidores" los cuales entonces almacenan los datos de acuerdo con la heurística de los algoritmos de almacenamiento de datos distribuidos de Freenet.

Las funcionalidades de Freenet son muy complementarias a las de I2P, ya que Freenet provee nativamente muchas herramientas para operar en sistemas de media y alta latencia, mientras que I2P provee nativamente una red de baja latencia adecuada para ofrecer anonimato. La lógica para separar la mixnet de los datos distribuidos resistentes a censura, son muy evidentes desde la perspectiva del anonimato, seguridad y de la asignación de los recursos, con lo que esperamos que el equipo de Freenet ponga sus esfuerzos en esta dirección, aunque sea reutilizando (o ayudando a mejorar, si es necesario) las redes existentes como I2P y Tor.

Vale la pena mencionar que recientemente ha habido discusiones y trabajos realizados por los desarrolladores de Freenet sobre una "darknet escalable global" usando pares restringidos entre pares de varias confianzas. Mientras que no se ha hecho pública suficiente información sobre como funcionará ese sistema para una revisión completa, pero lo que se ha dicho del anonimato y la escalabilidad parecen ser muy dudoso. En particular, el uso apropiado de su uso contra regímenes hostiles ha sido exagerado, y cualquier análisis de las implicaciones sobre la escasez de recursos sobre la escalabilidad de la red han sido aparentemente evitados. Existen otras preguntas sobre la posibilidad de análisis del tráfico, confianza y otros temas, pero hace falta una revisión más profunda de esta "darknet escalable global", pero deberán esperar hasta que el equipo de Freenet ponga más información a disposición.

Appendix A: Application layer

En sí, I2p no hace mucho - simplemente envía mensajes a destinaciones remotas y recibe mensajes hacia destinaciones locales - la mayoría del trabajo interesante es sobre las capas que hay sobre I2P. Por sí mismo I2P puede verse como una capa de IP anónima y segura, y la librería streaming incluida como una implementación de una capa TCP segura y anónima sobre I2P. Más allá de esto, el I2PTunnel expone un sistema genérico TCP para entrar dentro o salir de la red I2P, más una gran variedad de aplicaciones para proveer más funcionalidades a los usuarios finales.

Librería de streaming

La librería de streaming de I2P puede verse como un interfaz genérico de streaming (reflejando sockets TCP), y la implementación soporta el protocolo sliding window con varias optimizaciones, para tener en cuenta los altos retardos en I2P. Los streams individuales pueden ajustar el tamaño máximo de paquetes y otras opciones, aunque la compresión por defecto de 4KB parece una compensación razonable entre el coste de ancho de banda de reenviar los mensajes perdidos y la latencia de múltiples mensajes.

Además, considerando el alto coste de un mensaje, la librería de streaming para programar y enviar mensajes ha sido optimizada para permitir que los mensajes individuales enviados contengan tanta información como esté disponible. Por ejemplo, una pequeña transacción HTTP enviada a través de la librería de streaming puede ser completada en una simple vuelta - el primer mensaje empaqueta a SYN, FIN y un pequeña carga (normalmente encaja una solicitud HTTP) y la respuesta empaqueta el SYN, FIN, ACK y una pequeña carga (muchas respuestas HTTP encajan). Mientras que el ACK adicional debe ser transmitido para decirle al servido HTTP que el SYN/FIN/ACK ha llegado, el proxy HTTP local puede enviar al navegador inmediatamente la respuesta completa.

En conjunto, la librería de streaming se parece mucho a una abstracción de TCP, con sus sliding windows, algoritmos de control de congestión (inicio lento e impedimento de congestiones), y comportamiento general de paquetes (ACK, SYN, FIN, RST, etc).

Naming library and address book

For more information see the Naming and Address Book page.

Desarrolado por: mihi, Ragnarok

Los nombres de dominio en I2P han sido debatidos a menudo desde el principio, con defensores para todos los tipos de posibilidades. Sin embargo, y dada la necesidad de comunicaciones seguras y descentralizadas, el sistema tradicional al estilo DNS no es viable, al igual que no lo son los sistemas de votos en los que la "mayoría manda". Por el contrario, I2P incluye una librería genérica para nombres de dominios y una implementación básica diseñados para trabajar con nombres locales y mapearlos, así como un pluguin opcional llamado "addressbook", lista de direcciones. La lista de direcciones es un sistema de dominios distribuido, basado en un sistema de confianza seguro basado en web y legible, sólo sacrificando el hecho de que los dominios puedan ser leídos por los humanos globalmente para ser sólo entendibles localmente. Ya que todos los mensajes en I2P están dirigidos criptográficamente por su destinación, diferentes personas pueden tener entradas en la lista de direcciones para "Alice", pero refiriéndose a destinaciones diferentes. La gente puede descubrir nuevos nombres importando lista de direcciones publicadas por pares específicos de su web de confianza, añadiendo estas entradas a través de una tercera parte, o (si alguien organiza listas de direcciones usando sistema de registro tipo el primero que entra el primero es servido) la gente puede escoger tratar estas lista de direcciones como servidores de dominio, emulando los DNS tradicionales.

I2P no recomienda el uso de servicios tipo DNS, ya que el daño hecho por una web maliciosas puede ser enorme - una destinación insegura no tiene valor. DNSsec sigue apoyándose en autoridades certificadas, mientras que con I2P las solicitudes a una destinación no pueden ser interceptadas o la respuesta suplantada ya que están cifradas con la clave pública de la destinación, y una destinación en sí misma no es más que un par de claves y un certificado. Por otra parte, los sistemas del tipo DNS permiten que cualquiera de los servidores en el camino de búsqueda pueda montar ataques de denegación de servicio o ataques de suplantación. Añadiendo sobre un certificado autentificándose la respuesta firmada por alguna autoridad centralizada de certificados, podría solucionar muchos de los problemas con los servidores de dominio hostiles, pero lo dejaría abierto a ataques de respuesta y a ataques de autoridad certificada hostil.

El sistema de dominios por votos también es peligroso, sobre todo por la efectividad de los ataques Sybil en sistemas anónimos- el atacante puede simplemente crear un número aleatorio muy grande de pares y "votar" con cada uno para apoderarse de un dominio cualquiera. Existen métodos que pueden usarse para hacer que crear una identidad no sea gratis, pero a medida que la red crece la carga que se necesita para contactar a todos y hacer votación online es enorme, o si no hace falta la red completa, se podrían encontrar otras soluciones.

Aún así, al igual que con Internet, I2P mantiene el diseño y funcionamiento de un sistema de dominios aparte de la capa de comunicación (como IP). La librería de dominios incluye un interfaz simple de servicio al cual puede conectarse cualquier sistema de dominios, permitiendo a los usuarios finales elegir qué tipo de sistema de dominios prefieren.

Syndie

El viejo Syndie incluido con I2P ha sido reemplazado con un nuevo Syndie, el cual es distribuido aparte. Para más información vea la web de Syndie.

Syndie es un sistema seguro y anónimo de blogueo / publicación de contenidos / agregación de contenidos. Le permite crear información, compartirla con otros, y leer lo que publican aquellas personas en las que esté interesado, y todo mientras se tiene en cuenta sus necesidades de seguridad y anonimato. En lugar de construir su propia red de distribución de contenidos, Syndie está diseñado para ejecutarse sobre redes ya existentes, sindicando el contenido a través de eepsites, servicios ocultos de Tor, freesites de Freenet, sitios webs normales, grupos de noticias (news) de usenet, listas de correo, suscripciones RSS (feeds), etc. Con los datos publicados con Syndie se hace así para ofrecer autentificación con pseudónimo a cualquiera que lea o archive datos.

I2PTunnel

Desarrolado por: mihi

I2pTunnel es probablemente la aplicación más versátil y popular de I2P, permitiendo 'proxificar' dentro y fuera de la red I2P. Se puede ver I2PTunnel como cuatro aplicaciones de proxy diferentes - un cliente que recibe conexiones TCP de entrada y las envía a una destinación I2P, un "cliente http" ("eeproxy") que funciona con un proxy HTTP y envía las peticiones a la destinación I2P apropiada (Después de preguntar a un servicio de dominios si es necesario), un "servidor" el cual recibe conexiones de entrada de I2P en una destinación y los envía a un host+puerto TCP dado, y un "servidor http" el cual amplía el "servidor" pasando las solicitudes y respuestas HTTP para permitir un funcionamiento seguro. Hay una aplicación adicional "socksclient", pero su uso no se fomenta por razones mencionadas anteriormente.

En sí mismo I2P no es una red creada para outproxy - los problemas de seguridad de una red que envía datos dentro y fuera de esta han hecho que el diseño de I2P se haya centrado en crear una red anónima con capacidad para cubrir las necesidades de los usuarios sin necesitar recursos externos. Aún así la aplicación de "httpclient" I2PTunnel ofrece la posibilidad de 'outproxying' - si el nombre de dominio no termina en .i2p, elije una destinación aleatoria de una lista de outproxies para el usuario dado y se lo envía. Estas destinaciones son simplemente "servidores" I2PTunnels ejecutados por voluntarios que han decidido explícitamente ejecutar outproxies - nadie es un outproxy por defecto, y ejecutar un outproxy no hace que nadie pase automáticamente a través de su ruter. Aunque los outproxys tienen debilidades inherentes, ofrecen un servicio para I2P que tiene un modelo de seguridad que puede ser suficiente para algunos usuarios.

I2PTunnel es el que permite el funcionamiento de la mayoría de las aplicaciones. Un "servidor http" apuntando a un servidor web permite a cualquiera tener su propia web anónima ( o "eepsite") - un servidor web se incluye por defecto en I2P para este propósito, pero se puede utilizar cualquier servidor web. Cualquiera puede ejecutar un "cliente" apuntando a cualquiera de los servidores IRC, todos ellos ejecutan un "servidor" apuntando a su demonio IRCd local y comunicándose entre servidores IRCd a través de sus propios túneles "cliente". Los usuarios finales también tienen túneles clientes apuntando a las destinaciones POP3 y SMTP de I2Pmail ( que realmente sólo son simples instancias "servidores" apuntando a servidores POP3 y SMTP), también hay túneles apuntando al servidor CVS de I2P, permitiendo el desarrollo anónimo. Incluso a veces hay gente que ha ejecutado proxies "clientes" para acceder instancias de "servidores" apuntando a servidores NNTP.

i2p-bt

Desarrolado por: duck, et al

i2p-bt is a port of the mainline python BitTorrent client to run both the tracker and peer communication over I2P. Tracker requests are forwarded through the eepproxy to I2P Sites specified in the torrent file while tracker responses refer to peers by their destination explicitly, allowing i2p-bt to open up a streaming lib connection to query them for blocks.

Ademas de i2p-bt, se ha creado un port de bytemonsoon para I2P, haciendo las modificaciones necesarias para separar las información comprometedora de la aplicación y tomar en consideración el hecho de que las IPs no pueden usarse para identificar los pares.

I2PSnark

I2Psnark es programado por jrandom y otros, portado desde el cliente Snark de mjw.

Incluido en la instalación de I2P, I2PSnark ofrece un cliente anónimo de BitTorrent con capacidades para multitorrents, mostrando todas sus funcionaliudades a través de in unterfaz web HTML.

Robert

Desarrolado por: sponge

Robert es un cliente Bittorrent escrito en Python. Se aloja en http://bob.i2p.xyz/Robert.html

PyBit

Desarrolado por: Blub

PyBit es un cliente Bittorrent escrito en Python. Está hospedado en http://echelon.i2p.xyz/pybit/

I2Phex

Desarrolado por: sirup

I2Phex es un port de Phex, el cliente de para compartir archivos Gnutella, para ser ejecutado en I2P. Aunque se han deshabilitado algunas funciones de Phex, como la integración los los webcaches de GNUtella, los sistemas básicos de compartición y chateo son funcionales.

iMule

Desarrolado por: mkvore

iMule es un port del cliente p2p aMule, que funciona completamente dentro de I2P.

I2Pmail/susimail

Desarrolado por: postman, susi23, mastiejaner

I2Pmail es más un servicio que una aplicación - postman ofrece correos internos y externos con servicios POP3 y SMTP a través de instancias de I2PTunnel que acceden a una serie de componentes desarrollados con mastiejaner, permitiendo a la gente usar su cliente de correo favorito para enviar y recibir seudoanónimamente. Ya que la mayoría de los clientes de mail muestran demasiado información identificativa, I2P incluye el cliente susimail basado en web de susi23 construido específicamente para las necesidades de anonimato de I2P. El servicio de I2Pmail/mail.i2p ofrece filtrado transparente de virus así como protección contra ataques DOS con cuotas de hashcash. Además, cada usuario tiene control de su estrategia de lotes antes de enviar a través de los outproxies de mail.i2p, que están separados de los servidores de SMTP y POP3 de mail.i2p - los inproxies y outproxies se comunican con los servidores SMTP y POP3 a través de I2P, con lo cual si se comprometen localizaciones no anónimas no se da acceso a la actividad de las cuentas de correo o las pautas del usuario. En este momento los desarrolladores trabajan en un sistema de correo descentralizado, llamado "v2mail". Se puede encontrar más información en hq.postman.i2p.xyz.

I2P-Bote

Desarrolado por: HungryHobo

I2P-Bote es un aplicación distribuida de correo. No usa el modelo tradicional de enviar un correo a un servidor y obtenerlo de ese servidor. En cambio, usa el sistema distribuido de tablas hash Kademila para almacenar los correos. Un usuario puede enviar el correo al DHT, mientras que otro puede obtener al correo del DHT. Y todos los correos enviados con la red I2P-Bote son automáticamente cifrados de fin a fin.
Además, I2P-Bote ofrece una función de remailer sobre I2P, para el anonimato de alta latencia.

I2P-Messenger

I2P-Messenger es un aplicación de comunicación cifrada de fin a fin. Para la comunicación entre 2 usuarios sólo necesitan compartir entre ellos las claves de destino. Soporta transferencia de archivos y búsqueda de otros usuarios, basado en Seedlees.