NOTA: Este documento fue escrito originalmente por jrandom en 2003. Aunque nos esforzamos por mantenerlo actualizado, cierta información puede estar obsoleta o incompleta. Las secciones de transporte y criptografía están actualizadas a partir de 2025-01.
Introducción
I2P es una capa de red anónima escalable, autoorganizada y resistente basada en conmutación de paquetes, sobre la cual puede operar cualquier número de aplicaciones diferentes conscientes del anonimato o la seguridad. Cada una de estas aplicaciones puede hacer sus propias compensaciones entre anonimato, latencia y rendimiento sin preocuparse por la implementación adecuada de una mixnet de ruta libre, permitiéndoles mezclar su actividad con el conjunto de anonimato más amplio de usuarios que ya ejecutan sobre I2P.
Las aplicaciones ya disponibles proporcionan toda la gama de actividades típicas de Internet — navegación web anónima, alojamiento web, chat, intercambio de archivos, correo electrónico, blogs y sindicación de contenido, así como varias otras aplicaciones en desarrollo.
- Navegación web: usando cualquier navegador existente que soporte el uso de un proxy.
- Chat: IRC y otros protocolos
- Compartir archivos: I2PSnark y otras aplicaciones
- Correo electrónico: susimail y otras aplicaciones
- Blog: usando cualquier servidor web local, o plugins disponibles
A diferencia de los sitios web alojados en redes de distribución de contenido como Freenet o GNUnet , los servicios alojados en I2P son completamente interactivos: hay motores de búsqueda tradicionales estilo web, tablones de anuncios, blogs en los que puedes comentar, sitios basados en bases de datos, y puentes para consultar sistemas estáticos como Freenet sin necesidad de instalarlo localmente.
Con todas estas aplicaciones habilitadas para el anonimato, I2P asume el rol del middleware orientado a mensajes — las aplicaciones dicen que quieren enviar algunos datos a un identificador criptográfico (un “destination”) e I2P se encarga de asegurar que lleguen de forma segura y anónima. I2P también incluye una biblioteca de streaming simple para permitir que los mensajes anónimos de mejor esfuerzo de I2P se transfieran como flujos confiables y ordenados, ofreciendo de manera transparente un algoritmo de control de congestión basado en TCP ajustado para el alto producto de ancho de banda por retardo de la red. Aunque han estado disponibles varios proxies SOCKS simples para conectar aplicaciones existentes a la red, su valor ha sido limitado ya que casi todas las aplicaciones exponen rutinariamente lo que, en un contexto anónimo, es información sensible. La única forma segura de proceder es auditar completamente una aplicación para asegurar su funcionamiento adecuado y para ayudar en eso proporcionamos una serie de APIs en varios lenguajes que pueden usarse para aprovechar al máximo la red.
I2P no es un proyecto de investigación — académico, comercial o gubernamental — sino que es un esfuerzo de ingeniería dirigido a hacer todo lo necesario para proporcionar un nivel suficiente de anonimato a quienes lo necesitan. Ha estado en desarrollo activo desde principios de 2003 con un desarrollador de tiempo completo y un grupo dedicado de colaboradores de tiempo parcial de todo el mundo. Todo el trabajo realizado en I2P es código abierto y está disponible gratuitamente en el sitio web , con la mayoría del código liberado directamente al dominio público, aunque utiliza algunas rutinas criptográficas bajo licencias estilo BSD. Las personas que trabajan en I2P no controlan bajo qué licencias publican las aplicaciones cliente, y hay varias aplicaciones disponibles bajo GPL (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex y otras). La financiación para I2P proviene completamente de donaciones, y no recibe exenciones fiscales en ninguna jurisdicción en este momento, ya que muchos de los desarrolladores son ellos mismos anónimos.
Operación
Descripción general
Para entender el funcionamiento de I2P, es esencial comprender algunos conceptos clave. Primero, I2P hace una separación estricta entre el software que participa en la red (un “router”) y los puntos finales anónimos (“destinations”) asociados con aplicaciones individuales. El hecho de que alguien esté ejecutando I2P no suele ser un secreto. Lo que se oculta es información sobre qué está haciendo el usuario, si es que está haciendo algo, así como a qué router está conectado un destination en particular. Los usuarios finales normalmente tendrán varios destinations locales en su router — por ejemplo, uno haciendo proxy a servidores IRC, otro que soporta el servidor web anónimo del usuario (“I2P Site”), otro para una instancia de I2Phex, otro para torrents, etc.
Otro concepto crítico que hay que entender es el “tunnel”. Un tunnel es una ruta dirigida a través de una lista explícitamente seleccionada de routers. Se utiliza cifrado por capas, por lo que cada uno de los routers solo puede descifrar una sola capa. La información descifrada contiene la IP del siguiente router, junto con la información cifrada que debe ser reenviada. Cada tunnel tiene un punto de inicio (el primer router, también conocido como “gateway”) y un punto final. Los mensajes solo pueden ser enviados en una dirección. Para enviar mensajes de vuelta, se requiere otro tunnel.
Existen dos tipos de tunnels: los “tunnels de salida” envían mensajes lejos del creador del tunnel, mientras que los “tunnels de entrada” traen mensajes al creador del tunnel. Combinar estos dos tunnels permite a los usuarios enviarse mensajes entre sí. El remitente (“Alice” en la imagen anterior) configura un tunnel de salida, mientras que el receptor (“Bob” en la imagen anterior) crea un tunnel de entrada. El gateway de un tunnel de entrada puede recibir mensajes de cualquier otro usuario y los enviará hasta el endpoint (“Bob”). El endpoint del tunnel de salida necesitará enviar el mensaje al gateway del tunnel de entrada. Para hacer esto, el remitente (“Alice”) añade instrucciones a su mensaje cifrado. Una vez que el endpoint del tunnel de salida descifra el mensaje, tendrá instrucciones para reenviar el mensaje al gateway de entrada correcto (el gateway hacia “Bob”).
Un tercer concepto crítico que hay que entender es la “base de datos de red” de I2P (o “netDb”) — un par de algoritmos utilizados para compartir metadatos de red. Los dos tipos de metadatos que se transportan son “routerInfo” y “leaseSets” — el routerInfo proporciona a los routers los datos necesarios para contactar con un router en particular (sus claves públicas, direcciones de transporte, etc), mientras que el leaseSet proporciona a los routers la información necesaria para contactar con un destino en particular. Un leaseSet contiene varios “leases”. Cada uno de estos leases especifica una pasarela de tunnel, que permite alcanzar un destino específico. La información completa contenida en un lease:
- Gateway de entrada para un tunnel que permite alcanzar un destino específico.
- Momento en que un tunnel expira.
- Par de claves públicas para poder cifrar mensajes (para enviar a través del tunnel y alcanzar el destino).
Los routers envían directamente su routerInfo al netDb, mientras que los leaseSets se envían a través de túneles de salida (los leaseSets necesitan enviarse de forma anónima, para evitar correlacionar un router con sus leaseSets).
Podemos combinar los conceptos anteriores para construir conexiones exitosas en la red.
Para construir sus propios tunnels de entrada y salida, Alice realiza una búsqueda en el netDb para recopilar routerInfo. De esta manera, reúne listas de peers que puede usar como saltos en sus tunnels. Luego puede enviar un mensaje de construcción al primer salto, solicitando la construcción de un tunnel y pidiendo a ese router que reenvíe el mensaje de construcción, hasta que el tunnel haya sido construido.
Cuando Alice quiere enviar un mensaje a Bob, primero realiza una búsqueda en la netDb para encontrar el leaseSet de Bob, obteniendo así sus gateways de túnel de entrada actuales. Luego selecciona uno de sus túneles de salida y envía el mensaje a través de él con instrucciones para que el endpoint del túnel de salida reenvíe el mensaje a uno de los gateways de túnel de entrada de Bob. Cuando el endpoint del túnel de salida recibe esas instrucciones, reenvía el mensaje como se solicitó, y cuando el gateway del túnel de entrada de Bob lo recibe, es reenviado a través del túnel hacia el router de Bob. Si Alice quiere que Bob pueda responder al mensaje, necesita transmitir su propio destino explícitamente como parte del mensaje mismo. Esto se puede hacer introduciendo una capa de nivel superior, lo cual se hace en la biblioteca de streaming . Alice también puede reducir el tiempo de respuesta incluyendo su leaseSet más reciente con el mensaje para que Bob no necesite hacer una búsqueda en la netDb cuando quiera responder, pero esto es opcional.
Aunque los túneles en sí mismos tienen cifrado por capas para prevenir la divulgación no autorizada a pares dentro de la red (como lo hace la capa de transporte para prevenir la divulgación no autorizada a pares fuera de la red), es necesario agregar una capa adicional de cifrado de extremo a extremo para ocultar el mensaje del punto final del túnel de salida y la puerta de enlace del túnel de entrada. Esta “garlic encryption ” permite al router de Alice envolver múltiples mensajes en un solo “mensaje garlic”, cifrado a una clave pública particular para que los pares intermediarios no puedan determinar cuántos mensajes hay dentro del garlic, qué dicen esos mensajes, o a dónde están destinados esos dientes individuales. Para la comunicación típica de extremo a extremo entre Alice y Bob, el garlic será cifrado a la clave pública publicada en el leaseSet de Bob, permitiendo que el mensaje sea cifrado sin revelar la clave pública al propio router de Bob.
Otro hecho importante a tener en cuenta es que I2P está completamente basado en mensajes y que algunos mensajes pueden perderse en el camino. Las aplicaciones que usan I2P pueden utilizar las interfaces orientadas a mensajes y encargarse de sus propias necesidades de control de congestión y confiabilidad, pero la mayoría sería mejor servida reutilizando la biblioteca de streaming proporcionada para ver I2P como una red basada en flujos.
Tunnels
Tanto los túneles de entrada como los de salida funcionan bajo principios similares. El gateway del túnel acumula varios mensajes de túnel, procesándolos eventualmente en algo para la entrega del túnel. A continuación, el gateway encripta esos datos preprocesados y los reenvía al primer salto. Ese peer y los participantes subsecuentes del túnel agregan una capa de encriptación después de verificar que no es un duplicado antes de reenviarlo al siguiente peer. Finalmente, el mensaje llega al endpoint donde los mensajes se separan nuevamente y se reenvían según se solicite. La diferencia surge en lo que hace el creador del túnel — para túneles de entrada, el creador es el endpoint y simplemente desencripta todas las capas agregadas, mientras que para túneles de salida, el creador es el gateway y pre-desencripta todas las capas para que después de que se agreguen todas las capas de encriptación por salto, el mensaje llegue en claro al endpoint del túnel.
La elección de pares específicos para transmitir mensajes, así como su orden particular, es importante para entender tanto las características de anonimato como de rendimiento de I2P. Mientras que la network database (netDb) tiene sus propios criterios para elegir qué pares consultar y en qué almacenar entradas, los creadores de tunnels pueden usar cualquier par en la red en cualquier orden (e incluso cualquier número de veces) en un solo tunnel. Si los datos perfectos de latencia y capacidad fueran conocidos globalmente, la selección y el orden estarían impulsados por las necesidades particulares del cliente en conjunto con su modelo de amenaza. Desafortunadamente, los datos de latencia y capacidad no son triviales de recopilar de forma anónima, y depender de pares no confiables para proporcionar esta información tiene sus propias implicaciones serias para el anonimato.
Desde una perspectiva de anonimato, la técnica más simple sería seleccionar peers aleatoriamente de toda la red, ordenarlos aleatoriamente y usar esos peers en ese orden para toda la eternidad. Desde una perspectiva de rendimiento, la técnica más simple sería seleccionar los peers más rápidos con la capacidad de reserva necesaria, distribuyendo la carga entre diferentes peers para manejar la conmutación por error transparente, y reconstruir el tunnel cada vez que cambie la información de capacidad. Mientras que la primera es tanto frágil como ineficiente, la última requiere información inaccesible y ofrece anonimato insuficiente. I2P está trabajando en su lugar en ofrecer un rango de estrategias de selección de peers, junto con código de medición consciente del anonimato para organizar los peers por sus perfiles.
Como base, I2P está constantemente perfilando los peers con los que interactúa midiendo su comportamiento indirecto — por ejemplo, cuando un peer responde a una búsqueda netDb en 1.3 segundos, esa latencia de ida y vuelta se registra en los perfiles de todos los routers involucrados en los dos tunnels (entrante y saliente) a través de los cuales pasaron la solicitud y respuesta, así como en el perfil del peer consultado. La medición directa, como la latencia de la capa de transporte o la congestión, no se utiliza como parte del perfil, ya que puede ser manipulada y asociada con el router que mide, exponiéndolos a ataques triviales. Mientras se recopilan estos perfiles, se ejecuta una serie de cálculos en cada uno para resumir su rendimiento — su latencia, capacidad para manejar mucha actividad, si están actualmente sobrecargados, y qué tan bien integrados en la red parecen estar. Estos cálculos se comparan luego para los peers activos para organizar los routers en cuatro niveles — rápido y de alta capacidad, alta capacidad, sin fallos, y fallando. Los umbrales para esos niveles se determinan dinámicamente, y aunque actualmente utilizan algoritmos bastante simples, existen alternativas.
Usando estos datos de perfil, la estrategia de selección de peers más simple y razonable es elegir peers aleatoriamente del nivel superior (rápidos y de alta capacidad), y esto está actualmente implementado para los tunnels de cliente. Los tunnels exploratorios (usados para netDb y gestión de tunnels) eligen peers aleatoriamente del nivel “sin fallos” (que incluye routers de niveles ‘mejores’ también), permitiendo que el peer muestree routers más ampliamente, optimizando efectivamente la selección de peers a través de escalada de colinas aleatorizada. Sin embargo, estas estrategias por sí solas filtran información sobre los peers en el nivel superior del router a través de ataques de predecesor y recolección de netDb. A su vez, existen varias alternativas que, aunque no balancean la carga de manera tan uniforme, abordarán los ataques montados por clases particulares de adversarios.
Al elegir una clave aleatoria y ordenar los peers según su distancia XOR desde ella, la información filtrada se reduce en ataques de predecesor y recolección según la tasa de fallo de los peers y la rotación del nivel. Otra estrategia simple para lidiar con ataques de recolección de netDb es simplemente fijar la(s) puerta(s) de enlace del túnel de entrada pero aleatorizar los peers más adelante en los túneles. Para lidiar con ataques de predecesor para adversarios que el cliente contacta, los puntos finales del túnel de salida también permanecerían fijos. La selección de qué peer fijar en el punto más expuesto por supuesto necesitaría tener un límite de duración, ya que todos los peers fallan eventualmente, por lo que podría ser ajustado reactivamente o evitado proactivamente para imitar un tiempo medio medido entre fallos de otros routers. Estas dos estrategias pueden a su vez combinarse, usando un peer expuesto fijo y un ordenamiento basado en XOR dentro de los túneles mismos. Una estrategia más rígida fijaría los peers exactos y el ordenamiento de un túnel potencial, solo usando peers individuales si todos ellos acuerdan participar de la misma manera cada vez. Esto varía del ordenamiento basado en XOR en que el predecesor y sucesor de cada peer es siempre el mismo, mientras que el XOR solo asegura que su orden no cambie.
Como se mencionó anteriormente, I2P actualmente (versión 0.8) incluye la estrategia aleatoria por niveles mencionada arriba, con ordenamiento basado en XOR. Una discusión más detallada de los mecanismos involucrados en la operación, gestión y selección de pares de los tunnel se puede encontrar en la especificación de tunnel .
Base de Datos de Red (netDb)
Como se mencionó anteriormente, el netDb de I2P funciona para compartir los metadatos de la red. Esto se detalla en la página de base de datos de red , pero a continuación se proporciona una explicación básica.
Todos los routers I2P contienen una netDb local, pero no todos los routers participan en la DHT o responden a búsquedas de leaseset. Aquellos routers que sí participan en la DHT y responden a búsquedas de leaseset se denominan ‘floodfills’. Los routers pueden configurarse manualmente como floodfills, o convertirse automáticamente en floodfill si tienen suficiente capacidad y cumplen otros criterios para un funcionamiento confiable.
Otros routers I2P almacenarán sus datos y buscarán datos enviando consultas simples de ‘store’ y ’lookup’ a los floodfills. Si un router floodfill recibe una consulta ‘store’, distribuirá la información a otros routers floodfill usando el algoritmo Kademlia . Las consultas ’lookup’ funcionan actualmente de manera diferente, para evitar un problema de seguridad importante. Cuando se realiza una búsqueda, el router floodfill no reenviará la consulta a otros peers, sino que siempre responderá por sí mismo (si tiene los datos solicitados).
Dos tipos de información se almacenan en la base de datos de red.
- Un RouterInfo almacena información sobre un router I2P específico y cómo contactarlo
- Un LeaseSet almacena información sobre un destino específico (ej. sitio web I2P, servidor de correo electrónico…)
Toda esta información está firmada por la parte que la publica y verificada por cualquier router I2P que use o almacene la información. Además, los datos contienen información de tiempo, para evitar el almacenamiento de entradas antiguas y posibles ataques. Esta es también la razón por la que I2P incluye el código necesario para mantener la hora correcta, consultando ocasionalmente algunos servidores SNTP (el round robin pool.ntp.org por defecto) y detectando desviaciones entre routers en la capa de transporte.
Algunas observaciones adicionales también son importantes.
LeaseSets no publicados y encriptados: Uno podría querer que solo personas específicas puedan alcanzar un destino. Esto es posible al no publicar el destino en el netDb. Sin embargo, tendrás que transmitir el destino por otros medios. Esto es compatible con ’leaseSets encriptados’. Estos leaseSets solo pueden ser decodificados por personas con acceso a la clave de descifrado.
Bootstrapping: Hacer bootstrap de la netDb es bastante simple. Una vez que un router logra recibir un solo routerInfo de un peer alcanzable, puede consultar a ese router para obtener referencias a otros routers en la red. Actualmente, varios usuarios publican sus archivos routerInfo en un sitio web para hacer disponible esta información. I2P se conecta automáticamente a uno de estos sitios web para recopilar archivos routerInfo y hacer bootstrap. I2P llama a este proceso de bootstrap “reseeding”.
Escalabilidad de búsqueda: Las búsquedas en la red I2P son iterativas, no recursivas. Si una búsqueda desde un floodfill falla, la búsqueda se repetirá al siguiente floodfill más cercano. El floodfill no pregunta recursivamente a otro floodfill por los datos. Las búsquedas iterativas son escalables para redes DHT grandes.
Protocolos de Transporte
La comunicación entre routers necesita proporcionar confidencialidad e integridad contra adversarios externos mientras autentica que el router contactado es el que debería recibir un mensaje dado. Los detalles específicos de cómo los routers se comunican con otros routers no son críticos — se han usado tres protocolos separados en diferentes momentos para proporcionar esas necesidades básicas.
I2P actualmente soporta dos protocolos de transporte, NTCP2 sobre TCP, y SSU2 sobre UDP. Estos han reemplazado las versiones anteriores de los protocolos, NTCP y SSU , que ahora están obsoletos. Ambos protocolos soportan tanto IPv4 como IPv6. Al soportar transportes tanto TCP como UDP, I2P puede atravesar efectivamente la mayoría de firewalls, incluyendo aquellos destinados a bloquear tráfico en regímenes restrictivos de censura. NTCP2 y SSU2 fueron diseñados para usar estándares de cifrado modernos, mejorar la resistencia a la identificación de tráfico, aumentar la eficiencia y seguridad, y hacer el atravesado de NAT más robusto. Los routers publican cada transporte soportado y dirección IP en la base de datos de red. Los routers con acceso a redes públicas IPv4 e IPv6 usualmente publicarán cuatro direcciones, una para cada combinación de NTCP2/SSU2 con IPv4/IPv6.
SSU2 admite y amplía los objetivos de SSU. SSU2 tiene muchas similitudes con otros protocolos modernos basados en UDP como Wireguard y QUIC. Además del transporte confiable de mensajes de red a través de UDP, SSU2 proporciona facilidades especializadas para la detección cooperativa de direcciones IP punto a punto, detección de firewall y traversal de NAT. Como se describe en la especificación SSU :
El objetivo de este protocolo es proporcionar entrega de mensajes segura, autenticada, semi-confiable y desordenada, exponiendo solo una cantidad mínima de datos fácilmente discernibles por terceros. Debe soportar comunicación de alto grado así como control de congestión amigable con TCP y puede incluir detección PMTU. Debe ser capaz de mover eficientemente datos masivos a velocidades suficientes para usuarios domésticos. Además, debe soportar técnicas para abordar obstáculos de red, como la mayoría de NATs o firewalls.
NTCP2 apoya y extiende los objetivos de NTCP. Proporciona un transporte eficiente y completamente cifrado de mensajes de red sobre TCP, y resistencia a la identificación de tráfico, utilizando estándares de cifrado modernos.
I2P admite múltiples transportes simultáneamente. Un transporte particular para una conexión saliente se selecciona mediante “ofertas”. Cada transporte hace una oferta por la conexión y el valor relativo de estas ofertas asigna la prioridad. Los transportes pueden responder con ofertas diferentes, dependiendo de si ya existe una conexión establecida con el peer.
Los valores de oferta (prioridad) dependen de la implementación y pueden variar según las condiciones del tráfico, el número de conexiones y otros factores. Los routers también publican sus preferencias de transporte para conexiones entrantes en la base de datos de red como “costos” de transporte para cada transporte y dirección.
Criptografía
I2P utiliza criptografía en varias capas de protocolo para cifrado, autenticación y verificación. Las principales capas de protocolo son: transportes, mensajes de construcción de tunnel, cifrado de capa de tunnel, mensajes de base de datos de red y mensajes de extremo a extremo (garlic). El diseño original de I2P utilizaba un pequeño conjunto de primitivas criptográficas que en ese momento se consideraban seguras. Estas incluían cifrado asimétrico ElGamal, firmas DSA-SHA1, cifrado simétrico AES256/CBC y hashes SHA-256. A medida que aumentó la potencia de cómputo disponible y la investigación criptográfica evolucionó sustancialmente a lo largo de los años, I2P necesitaba actualizar sus primitivas y protocolos. Por lo tanto, agregamos un concepto de “tipos de cifrado” y “tipos de firma”, y extendimos nuestros protocolos para incluir estos identificadores e indicar compatibilidad. Esto nos permite actualizar y extender periódicamente la compatibilidad de red para criptografía moderna y preparar la red para nuevas primitivas, sin romper la compatibilidad hacia atrás o requerir un “día bandera” para actualizaciones de red. Algunos tipos de firma y cifrado también están reservados para uso experimental.
Las primitivas actuales utilizadas en la mayoría de las capas de protocolo son el intercambio de claves X25519, firmas EdDSA, cifrado simétrico autenticado ChaCha20/Poly1305 y hashes SHA-256. AES256 todavía se utiliza para el cifrado de la capa de tunnel. Estos protocolos modernos se usan para la gran mayoría de la comunicación de red. Las primitivas más antiguas, incluyendo ElGamal, ECDSA y DSA-SHA1, continúan siendo compatibles con la mayoría de las implementaciones para mantener la compatibilidad hacia atrás al comunicarse con routers más antiguos. Algunos protocolos antiguos han sido deprecados y/o eliminados completamente. En el futuro cercano comenzaremos la investigación sobre una migración hacia cifrado y firmas post-cuánticos (PQ) o híbridos-PQ para mantener nuestros estándares de seguridad robustos.
Estas primitivas criptográficas se combinan para proporcionar las defensas en capas de I2P contra una variedad de adversarios. En el nivel más bajo, la comunicación entre routers está protegida por la seguridad de la capa de transporte. Los mensajes de tunnel que se pasan a través de los transportes tienen su propia encriptación en capas. Varios otros mensajes se pasan dentro de “garlic messages”, que también están encriptados.
Mensajes Garlic
Los mensajes garlic son una extensión del cifrado en capas tipo “cebolla”, que permite que el contenido de un solo mensaje contenga múltiples “dientes” — mensajes completamente formados junto con sus propias instrucciones de entrega. Los mensajes se envuelven en un mensaje garlic cada vez que el mensaje pasaría en texto plano a través de un peer que no debería tener acceso a la información — por ejemplo, cuando un router quiere pedirle a otro router que participe en un tunnel, envuelven la solicitud dentro de un garlic, cifran ese garlic con la clave pública del router receptor, y lo reenvían a través de un tunnel. Otro ejemplo es cuando un cliente quiere enviar un mensaje a un destino — el router del remitente envolverá ese mensaje de datos (junto con algunos otros mensajes) en un garlic, cifrará ese garlic con la clave pública publicada en el leaseSet del destinatario, y lo reenviará a través de los tunnels apropiados.
Las “instrucciones” adjuntas a cada clove dentro de la capa de cifrado incluyen la capacidad de solicitar que el clove sea reenviado localmente, a un router remoto, o a un tunnel remoto en un router remoto. Hay campos en esas instrucciones que permiten a un peer solicitar que la entrega se retrase hasta que se cumpla un cierto tiempo o condición, aunque no serán respetados hasta que se implementen los retrasos no triviales . Es posible enrutar explícitamente mensajes garlic cualquier número de saltos sin construir tunnels, o incluso reenrutar mensajes de tunnel envolviéndolos en mensajes garlic y reenviándolos varios saltos antes de entregarlos al siguiente salto en el tunnel, pero estas técnicas no se usan actualmente en la implementación existente.
Etiquetas de Sesión
Como un sistema no confiable, desordenado y basado en mensajes, I2P utiliza una combinación simple de algoritmos de cifrado asimétrico y simétrico para proporcionar confidencialidad e integridad de datos a los mensajes garlic. La combinación original se denominaba ElGamal/AES+SessionTags, pero esa es una forma excesivamente verbosa de describir el uso simple de ElGamal de 2048 bits, AES256, SHA256 y nonces de 32 bytes. Aunque este protocolo todavía es compatible, la mayoría de la red ha migrado a un nuevo protocolo, ECIES-X25519-AEAD-Ratchet. Este protocolo combina X25519, ChaCha20/Poly1305 y un PRNG sincronizado para generar los nonces de 32 bytes. Ambos protocolos se describirán brevemente a continuación.
ElGamal/AES+SessionTags
La primera vez que un router quiere cifrar un mensaje garlic a otro router, cifran el material de clave para una clave de sesión AES256 con ElGamal y anexan la carga útil cifrada AES256/CBC después de ese bloque ElGamal cifrado. Además de la carga útil cifrada, la sección cifrada AES contiene la longitud de la carga útil, el hash SHA256 de la carga útil sin cifrar, así como un número de “etiquetas de sesión” — nonces aleatorios de 32 bytes. La próxima vez que el remitente quiere cifrar un mensaje garlic a otro router, en lugar de cifrar con ElGamal una nueva clave de sesión simplemente escogen una de las etiquetas de sesión entregadas previamente y cifran AES la carga útil como antes, usando la clave de sesión utilizada con esa etiqueta de sesión, precedida por la etiqueta de sesión misma. Cuando un router recibe un mensaje cifrado garlic, verifican los primeros 32 bytes para ver si coincide con una etiqueta de sesión disponible — si coincide, simplemente descifran AES el mensaje, pero si no, descifran ElGamal el primer bloque.
Cada etiqueta de sesión puede usarse solo una vez para evitar que adversarios internos correlacionen innecesariamente diferentes mensajes como si fueran entre los mismos routers. El remitente de un mensaje cifrado ElGamal/AES+SessionTag elige cuándo y cuántas etiquetas entregar, abasteciendo previamente al destinatario con suficientes etiquetas para cubrir una ráfaga de mensajes. Los mensajes garlic pueden detectar la entrega exitosa de etiquetas al incluir un pequeño mensaje adicional como un clove (un “mensaje de estado de entrega”) — cuando el mensaje garlic llega al destinatario previsto y se descifra exitosamente, este pequeño mensaje de estado de entrega es uno de los cloves expuestos y tiene instrucciones para que el destinatario envíe el clove de vuelta al remitente original (a través de un túnel entrante, por supuesto). Cuando el remitente original recibe este mensaje de estado de entrega, sabe que las etiquetas de sesión incluidas en el mensaje garlic fueron entregadas exitosamente.
Los session tags en sí tienen un tiempo de vida muy corto, después del cual se descartan si no se usan. Además, la cantidad almacenada para cada clave está limitada, al igual que el número de claves en sí — si llegan demasiadas, se pueden descartar mensajes nuevos o antiguos. El remitente hace seguimiento de si los mensajes que usan session tags están llegando correctamente, y si no hay suficiente comunicación puede descartar los que anteriormente se asumían como entregados correctamente, volviendo al cifrado ElGamal completo y costoso.
ECIES-X25519-AEAD-Ratchet
ElGamal/AES+SessionTags requería una sobrecarga sustancial de varias maneras. El uso de CPU era alto porque ElGamal es bastante lento. El ancho de banda era excesivo porque grandes cantidades de session tags tenían que ser entregadas por adelantado, y porque las claves públicas ElGamal son muy grandes. El uso de memoria era alto debido al requisito de almacenar grandes cantidades de session tags. La confiabilidad se veía afectada por la pérdida en la entrega de session tags.
ECIES-X25519-AEAD-Ratchet fue diseñado para abordar estos problemas. X25519 se utiliza para el intercambio de claves. ChaCha20/Poly1305 se utiliza para cifrado simétrico autenticado. Las claves de cifrado son “doblemente ratcheteadas” o rotadas periódicamente. Las etiquetas de sesión se reducen de 32 bytes a 8 bytes y se generan con un PRNG. El protocolo tiene muchas similitudes con el protocolo signal utilizado en Signal y WhatsApp. Este protocolo proporciona una sobrecarga sustancialmente menor en CPU, RAM y ancho de banda.
Las etiquetas de sesión se generan a partir de un PRNG sincronizado determinístico que se ejecuta en ambos extremos de la sesión para generar etiquetas de sesión y claves de sesión. El PRNG es un HKDF que utiliza un SHA-256 HMAC, y se inicializa a partir del resultado X25519 DH. Las etiquetas de sesión nunca se transmiten por adelantado; solo se incluyen con el mensaje. El receptor almacena un número limitado de claves de sesión, indexadas por etiqueta de sesión. El emisor no necesita almacenar ninguna etiqueta o clave de sesión porque no se envían por adelantado; pueden generarse bajo demanda. Al mantener este PRNG aproximadamente sincronizado entre el emisor y el receptor (el receptor precalcula una ventana de las próximas 50 etiquetas, por ejemplo), se elimina la sobrecarga de agrupar periódicamente una gran cantidad de etiquetas.
Futuro
Los protocolos de I2P son eficientes en la mayoría de plataformas, incluyendo teléfonos móviles, y seguros para la mayoría de modelos de amenaza. Sin embargo, hay varias áreas que requieren mayor mejora para satisfacer las necesidades de aquellos que enfrentan adversarios poderosos patrocinados por estados, y para hacer frente a las amenazas de los continuos avances criptográficos y el poder computacional en constante aumento. Dos características posibles, rutas restringidas y latencia variable, fueron propuestas por jrandom en 2003. Aunque ya no planeamos implementar estas características, se describen a continuación.
Operación de Ruta Restringida
I2P es una red superpuesta diseñada para ejecutarse sobre una red funcional de conmutación de paquetes, aprovechando el principio extremo a extremo para ofrecer anonimato y seguridad. Aunque Internet ya no adopta completamente el principio extremo a extremo (debido al uso de NAT), I2P sí requiere que una porción sustancial de la red sea accesible — puede haber varios peers en los bordes ejecutándose con rutas restringidas, pero I2P no incluye un algoritmo de enrutamiento apropiado para el caso degenerado donde la mayoría de los peers son inaccesibles. Sin embargo, funcionaría sobre una red que emplee tal algoritmo.
La operación de rutas restringidas, donde hay límites sobre qué peers son alcanzables directamente, tiene varias implicaciones funcionales y de anonimato diferentes, dependiendo de cómo se manejen las rutas restringidas. En el nivel más básico, las rutas restringidas existen cuando un peer está detrás de un NAT o firewall que no permite conexiones entrantes. Esto se abordó en gran medida integrando hole punching distribuido en la capa de transporte, permitiendo que las personas detrás de la mayoría de NATs y firewalls reciban conexiones no solicitadas sin ninguna configuración. Sin embargo, esto no limita la exposición de la dirección IP del peer a los routers dentro de la red, ya que simplemente pueden ser introducidos al peer a través del introductor publicado.
Más allá del manejo funcional de rutas restringidas, existen dos niveles de operación restringida que pueden usarse para limitar la exposición de la dirección IP propia — usar tunnels específicos del router para la comunicación, y ofrecer ‘routers cliente’. Para el primero, los routers pueden construir un nuevo grupo de tunnels o reutilizar su grupo exploratorio, publicando los gateways de entrada a algunos de ellos como parte de su routerInfo en lugar de sus direcciones de transporte. Cuando un peer quiere ponerse en contacto con ellos, ve esos gateways de tunnel en la netDb y simplemente envía el mensaje relevante a través de uno de los tunnels publicados. Si el peer detrás de la ruta restringida quiere responder, puede hacerlo directamente (si está dispuesto a exponer su IP al peer) o indirectamente a través de sus tunnels de salida. Cuando los routers con los que el peer tiene conexiones directas quieren alcanzarlo (para reenviar mensajes de tunnel, por ejemplo), simplemente priorizan su conexión directa sobre el gateway de tunnel publicado. El concepto de ‘routers cliente’ simplemente extiende la ruta restringida al no publicar ninguna dirección de router. Tal router ni siquiera necesitaría publicar su routerInfo en la netDb, simplemente proporcionando su routerInfo auto-firmado a los peers que contacta (necesario para pasar las claves públicas del router).
Existen compromisos para aquellos que están detrás de rutas restringidas, ya que probablemente participarían en los tunnels de otras personas con menos frecuencia, y los routers a los que están conectados podrían inferir patrones de tráfico que de otro modo no estarían expuestos. Por otro lado, si el costo de esa exposición es menor que el costo de hacer disponible una IP, puede valer la pena. Esto, por supuesto, asume que los peers que el router detrás de una ruta restringida contacta no son hostiles — ya sea que la red sea lo suficientemente grande como para que la probabilidad de usar un peer hostil para conectarse sea lo suficientemente pequeña, o que se usen peers confiables (y quizás temporales) en su lugar.
Las rutas restringidas son complejas, y el objetivo general ha sido en gran medida abandonado. Varias mejoras relacionadas han reducido considerablemente la necesidad de ellas. Ahora soportamos UPnP para abrir automáticamente los puertos del firewall. Soportamos tanto IPv4 como IPv6. SSU2 mejoró la detección de direcciones, la determinación del estado del firewall y el NAT hole punching cooperativo. SSU2, NTCP2 y las verificaciones de compatibilidad de direcciones aseguran que los saltos del tunnel puedan conectarse antes de que el tunnel sea construido. GeoIP y la identificación de países nos permiten evitar peers en países con firewalls restrictivos. El soporte para routers “ocultos” detrás de esos firewalls ha mejorado. Algunas implementaciones también soportan conexiones a peers en redes superpuestas como Yggdrasil.
Latencia Variable
Aunque la mayor parte de los esfuerzos iniciales de I2P se han centrado en la comunicación de baja latencia, fue diseñado desde el principio teniendo en cuenta servicios de latencia variable. En el nivel más básico, las aplicaciones que se ejecutan sobre I2P pueden ofrecer el anonimato de la comunicación de latencia media y alta mientras siguen mezclando sus patrones de tráfico con el tráfico de baja latencia. Internamente, sin embargo, I2P puede ofrecer su propia comunicación de latencia media y alta a través de la garlic encryption — especificando que el mensaje debe enviarse después de cierto retraso, en un momento determinado, después de que haya pasado cierto número de mensajes, o mediante otra estrategia de mezcla. Con el cifrado por capas, solo el router al que el clove expuso la solicitud de retraso sabría que el mensaje requiere alta latencia, permitiendo que el tráfico se mezcle aún más con el tráfico de baja latencia. Una vez que se cumple la precondición de transmisión, el router que retiene el clove (que probablemente sería en sí mismo un mensaje garlic) simplemente lo reenvía según se solicita — a un router, a un tunnel, o, muy probablemente, a un destino de cliente remoto.
El objetivo de los servicios de latencia variable requiere recursos sustanciales para los mecanismos de almacenamiento y reenvío que lo soporten. Estos mecanismos pueden ser y son soportados en varias aplicaciones de mensajería, como i2p-bote. A nivel de red, redes alternativas como Freenet proporcionan estos servicios. Hemos decidido no perseguir este objetivo a nivel del router I2P.
Sistemas Similares
La arquitectura de I2P se basa en los conceptos de middleware orientado a mensajes, la topología de DHTs, el anonimato y la criptografía de mixnets de ruta libre, y la adaptabilidad de las redes de conmutación de paquetes. Sin embargo, el valor no proviene de conceptos o algoritmos novedosos, sino de una ingeniería cuidadosa que combina los resultados de investigación de sistemas y artículos existentes. Aunque hay algunos esfuerzos similares que vale la pena revisar, tanto para comparaciones técnicas como funcionales, dos en particular se destacan aquí: Tor y Freenet.
Consulta también la Página de Comparaciones de Redes . Ten en cuenta que estas descripciones fueron escritas por jrandom en 2003 y puede que no sean precisas actualmente.
Tor
A primera vista, Tor e I2P tienen muchas similitudes funcionales y relacionadas con el anonimato. Aunque el desarrollo de I2P comenzó antes de que fuéramos conscientes de los primeros esfuerzos en Tor, muchas de las lecciones del enrutamiento cebolla original y los esfuerzos de ZKS se integraron en el diseño de I2P. En lugar de construir un sistema esencialmente confiable y centralizado con servidores de directorio, I2P tiene una base de datos de red auto-organizativa donde cada peer asume la responsabilidad de perfilar otros routers para determinar cómo explotar mejor los recursos disponibles. Otra diferencia clave es que, aunque tanto I2P como Tor usan rutas en capas y ordenadas (tunnels y circuits/streams), I2P es fundamentalmente una red de conmutación de paquetes, mientras que Tor es fundamentalmente una de conmutación de circuitos, lo que permite a I2P enrutar de manera transparente alrededor de la congestión u otras fallas de red, operar rutas redundantes y equilibrar la carga de datos a través de los recursos disponibles. Mientras que Tor ofrece la útil funcionalidad de outproxy mediante el descubrimiento y selección integrados de outproxy, I2P deja tales decisiones de capa de aplicación a las aplicaciones que se ejecutan sobre I2P — de hecho, I2P ha incluso externalizado la propia librería de streaming similar a TCP a la capa de aplicación, permitiendo a los desarrolladores experimentar con diferentes estrategias, explotando su conocimiento específico del dominio para ofrecer mejor rendimiento.
Desde una perspectiva de anonimato, existe mucha similitud cuando se comparan las redes principales. Sin embargo, hay algunas diferencias clave. Al tratar con un adversario interno o la mayoría de adversarios externos, los tunnels símplex de I2P exponen la mitad de datos de tráfico que se expondrían con los circuitos dúplex de Tor simplemente observando los flujos en sí mismos — una solicitud y respuesta HTTP seguiría el mismo camino en Tor, mientras que en I2P los paquetes que componen la solicitud saldrían a través de uno o más tunnels de salida y los paquetes que componen la respuesta regresarían a través de uno o más tunnels de entrada diferentes. Aunque las estrategias de selección y ordenación de pares de I2P deberían abordar suficientemente los ataques de predecesor, si fuera necesario cambiar a tunnels bidireccionales, simplemente podríamos construir un tunnel de entrada y salida a lo largo de los mismos routers.
Otro problema de anonimato surge en el uso de Tor de la creación telescópica de túneles, ya que el simple conteo de paquetes y las mediciones de tiempo mientras las celdas en un circuito pasan a través del nodo de un adversario expone información estadística sobre dónde se encuentra el adversario dentro del circuito. La creación de túneles unidireccionales de I2P con un solo mensaje hace que estos datos no se expongan. Proteger la posición en un túnel es importante, ya que de lo contrario un adversario sería capaz de montar una serie de poderosos ataques de predecesor, intersección y confirmación de tráfico.
En general, Tor e I2P se complementan en su enfoque — Tor trabaja hacia ofrecer proxy de salida anónimo de Internet de alta velocidad, mientras que I2P trabaja hacia ofrecer una red resiliente descentralizada en sí misma. En teoría, ambos pueden usarse para lograr ambos propósitos, pero dados los recursos de desarrollo limitados, ambos tienen sus fortalezas y debilidades. Los desarrolladores de I2P han considerado los pasos necesarios para modificar Tor para aprovechar el diseño de I2P, pero las preocupaciones sobre la viabilidad de Tor bajo escasez de recursos sugieren que la arquitectura de conmutación de paquetes de I2P será capaz de explotar los recursos escasos de manera más efectiva.
Freenet
Freenet jugó un papel importante en las etapas iniciales del diseño de I2P, proporcionando prueba de la viabilidad de una comunidad pseudónima vibrante completamente contenida dentro de la red, demostrando que los peligros inherentes en los outproxies podían evitarse. La primera semilla de I2P comenzó como una capa de comunicación de reemplazo para Freenet, intentando separar las complejidades de una comunicación punto a punto escalable, anónima y segura de las complejidades de un almacén de datos distribuido resistente a la censura. Sin embargo, con el tiempo, algunos de los problemas de anonimato y escalabilidad inherentes en los algoritmos de Freenet dejaron claro que el enfoque de I2P debería mantenerse estrictamente en proporcionar una capa de comunicación anónima genérica, en lugar de como un componente de Freenet. A lo largo de los años, los desarrolladores de Freenet han llegado a ver las debilidades en el diseño más antiguo, lo que los llevó a sugerir que requerirán una capa “premix” para ofrecer anonimato sustancial. En otras palabras, Freenet necesita ejecutarse sobre una mixnet como I2P o Tor, con “nodos cliente” solicitando y publicando datos a través de la mixnet a los “nodos servidor” que luego obtienen y almacenan los datos según los algoritmos heurísticos de almacenamiento de datos distribuidos de Freenet.
La funcionalidad de Freenet es muy complementaria a la de I2P, ya que Freenet proporciona de forma nativa muchas de las herramientas para operar sistemas de latencia media y alta, mientras que I2P proporciona de forma nativa la red de mezcla de baja latencia adecuada para ofrecer anonimato adecuado. La lógica de separar la mixnet del almacén de datos distribuido resistente a la censura sigue pareciendo evidente desde una perspectiva de ingeniería, anonimato, seguridad y asignación de recursos, así que esperamos que el equipo de Freenet continúe esfuerzos en esa dirección, si no simplemente reutilizando (o ayudando a mejorar, según sea necesario) mixnets existentes como I2P o Tor.
Apéndice A: Capa de Aplicación
I2P en sí no hace mucho realmente — simplemente envía mensajes a destinos remotos y recibe mensajes dirigidos a destinos locales — la mayor parte del trabajo interesante ocurre en las capas superiores. Por sí solo, I2P podría verse como una capa IP anónima y segura, y la biblioteca de streaming incluida como una implementación de una capa TCP anónima y segura encima de ella. Más allá de eso, I2PTunnel expone un sistema genérico de proxy TCP para entrar o salir de la red I2P, además de una variedad de aplicaciones de red que proporcionan funcionalidad adicional para los usuarios finales.
Biblioteca de Streaming
La biblioteca de streaming de I2P puede verse como una interfaz de streaming genérica (que refleja los sockets TCP), y la implementación soporta un protocolo de ventana deslizante con varias optimizaciones, para tener en cuenta la alta latencia sobre I2P. Los streams individuales pueden ajustar el tamaño máximo de paquete y otras opciones, aunque el valor por defecto de 4KB comprimido parece un compromiso razonable entre los costos de ancho de banda de retransmitir mensajes perdidos y la latencia de múltiples mensajes.
Además, en consideración del costo relativamente alto de los mensajes posteriores, el protocolo de la biblioteca de streaming para programar y entregar mensajes ha sido optimizado para permitir que los mensajes individuales pasados contengan tanta información como esté disponible. Por ejemplo, una pequeña transacción HTTP proxificada a través de la biblioteca de streaming puede completarse en un solo viaje de ida y vuelta — el primer mensaje agrupa un SYN, FIN y la pequeña carga útil (una petición HTTP típicamente cabe) y la respuesta agrupa el SYN, FIN, ACK y la pequeña carga útil (muchas respuestas HTTP caben). Mientras que un ACK adicional debe ser transmitido para informar al servidor HTTP que el SYN/FIN/ACK ha sido recibido, el proxy HTTP local puede entregar la respuesta completa al navegador inmediatamente.
En general, sin embargo, la biblioteca de streaming se asemeja mucho a una abstracción de TCP, con sus ventanas deslizantes, algoritmos de control de congestión (tanto arranque lento como prevención de congestión), y comportamiento general de paquetes (ACK, SYN, FIN, RST, etc).
Biblioteca de Nombres y Libreta de Direcciones
Para más información consulta la página de Nomenclatura y Libreta de Direcciones .
Desarrollado por: mihi, Ragnarok
El sistema de nombres dentro de I2P ha sido un tema ampliamente debatido desde el principio, con defensores a través de todo el espectro de posibilidades. Sin embargo, dada la demanda inherente de I2P por comunicación segura y operación descentralizada, el sistema tradicional de nombres estilo DNS está claramente descartado, al igual que los sistemas de votación de “mayoría de reglas”. En su lugar, I2P viene con una biblioteca genérica de nombres y una implementación base diseñada para funcionar con un mapeo local de nombres a destinos, así como una aplicación complementaria opcional llamada “Address Book” (libreta de direcciones). La address book es un sistema de nombres seguro, distribuido y legible por humanos basado en web-of-trust, sacrificando únicamente la exigencia de que todos los nombres legibles por humanos sean globalmente únicos al requerir solo unicidad local. Aunque todos los mensajes en I2P son direccionados criptográficamente por su destino, diferentes personas pueden tener entradas en su address book local para “Alice” que se refieren a diferentes destinos. Las personas aún pueden descubrir nuevos nombres importando address books publicadas de pares especificados en su web of trust, agregando las entradas proporcionadas a través de un tercero, o (si algunas personas organizan una serie de address books publicadas usando un sistema de registro de primero en llegar, primero en ser servido) las personas pueden elegir tratar estas address books como servidores de nombres, emulando el DNS tradicional.
Sin embargo, I2P no promueve el uso de servicios similares a DNS, ya que el daño causado por el secuestro de un sitio puede ser tremendo, y los destinos inseguros no tienen valor. DNSsec en sí mismo aún depende de registradores y autoridades de certificación, mientras que con I2P, las solicitudes enviadas a un destino no pueden ser interceptadas o las respuestas falsificadas, ya que están cifradas con las claves públicas del destino, y un destino en sí mismo es solo un par de claves públicas y un certificado. Los sistemas estilo DNS por otro lado permiten que cualquiera de los servidores de nombres en la ruta de búsqueda monte ataques simples de denegación de servicio y suplantación. Agregar un certificado que autentique las respuestas como firmadas por alguna autoridad de certificación centralizada abordaría muchos de los problemas de servidores de nombres hostiles, pero dejaría abiertos los ataques de repetición, así como los ataques de autoridades de certificación hostiles.
El estilo de nomenclatura por votación también es peligroso, especialmente dada la efectividad de los ataques Sybil en sistemas anónimos — el atacante puede simplemente crear un número arbitrariamente alto de pares y “votar” con cada uno para apoderarse de un nombre dado. Los métodos de proof-of-work pueden usarse para hacer que la identidad no sea gratuita, pero a medida que la red crece, la carga requerida para contactar a todos para realizar votaciones en línea es implausible, o si no se consulta toda la red, pueden alcanzarse diferentes conjuntos de respuestas.
Sin embargo, al igual que con Internet, I2P mantiene el diseño y la operación de un sistema de nombres fuera de la capa de comunicación (similar a IP). La biblioteca de nombres incluida incorpora una interfaz simple de proveedor de servicios en la que sistemas de nombres alternativos pueden conectarse, permitiendo a los usuarios finales decidir qué tipo de compromisos de nombres prefieren.
I2PTunnel
Desarrollado por: mihi
I2PTunnel es probablemente la aplicación cliente más popular y versátil de I2P, permitiendo proxying genérico tanto hacia dentro como hacia fuera de la red I2P. I2PTunnel puede verse como cuatro aplicaciones de proxying separadas — un “client” que recibe conexiones TCP entrantes y las reenvía a un destino I2P dado, un “httpclient” (también conocido como “eepproxy”) que actúa como un proxy HTTP y reenvía las solicitudes al destino I2P apropiado (después de consultar el servicio de nombres si es necesario), un “server” que recibe conexiones de streaming I2P entrantes en un destino y las reenvía a un host+puerto TCP dado, y un “httpserver” que extiende el “server” analizando las solicitudes y respuestas HTTP para permitir una operación más segura. Existe una aplicación adicional “socksclient”, pero su uso no se recomienda por las razones mencionadas anteriormente.
I2P en sí mismo no es una red de outproxy — las preocupaciones de anonimato y seguridad inherentes en una red de mezcla que reenvía datos hacia y desde la mezcla han mantenido el diseño de I2P enfocado en proporcionar una red anónima capaz de satisfacer las necesidades del usuario sin requerir recursos externos. Sin embargo, la aplicación I2PTunnel “httpclient” ofrece un gancho para outproxying — si el nombre de host solicitado no termina en “.i2p”, selecciona un destino aleatorio de un conjunto de outproxies proporcionado por el usuario y reenvía la solicitud a ellos. Estos destinos son simplemente instancias de I2PTunnel “server” ejecutadas por voluntarios que han elegido explícitamente ejecutar outproxies — nadie es un outproxy por defecto, y ejecutar un outproxy no dice automáticamente a otras personas que hagan proxy a través de ti. Aunque los outproxies tienen debilidades inherentes, ofrecen una prueba de concepto simple para usar I2P y proporcionan cierta funcionalidad bajo un modelo de amenaza que puede ser suficiente para algunos usuarios.
I2PTunnel habilita la mayoría de las aplicaciones en uso. Un “httpserver” que apunta a un servidor web permite que cualquiera ejecute su propio sitio web anónimo (o “Sitio I2P”) — un servidor web viene incluido con I2P para este propósito, pero se puede usar cualquier servidor web. Cualquiera puede ejecutar un “client” que apunte a uno de los servidores IRC alojados de forma anónima, cada uno de los cuales ejecuta un “server” que apunta a su IRCd local y se comunica entre IRCds a través de sus propios tunnels “client”. Los usuarios finales también tienen tunnels “client” que apuntan a los destinos POP3 y SMTP de I2Pmail (que a su vez son simplemente instancias “server” que apuntan a servidores POP3 y SMTP), así como tunnels “client” que apuntan al servidor CVS de I2P, permitiendo desarrollo anónimo. A veces las personas incluso han ejecutado proxies “client” para acceder a las instancias “server” que apuntan a un servidor NNTP.
I2PSnark
I2PSnark desarrollado por: jrandom, et al, portado del cliente Snark de mjw
Incluido con la instalación de I2P, I2PSnark ofrece un cliente BitTorrent anónimo simple con capacidades multitorrent, exponiendo toda la funcionalidad a través de una interfaz web HTML simple.
I2Pmail / Susimail
Desarrollado por: postman, susi23, mastiejaner
I2Pmail es más un servicio que una aplicación — postman ofrece correo electrónico interno y externo con servicio POP3 y SMTP a través de instancias de I2PTunnel que acceden a una serie de componentes desarrollados con mastiejaner, permitiendo a las personas usar sus clientes de correo preferidos para enviar y recibir correo de forma seudónima. Sin embargo, como la mayoría de los clientes de correo exponen información identificativa sustancial, I2P incluye el cliente web susimail de susi23 que ha sido construido específicamente teniendo en cuenta las necesidades de anonimato de I2P. El servicio I2Pmail/mail.i2p ofrece filtrado transparente de virus así como prevención de denegación de servicio con cuotas aumentadas por hashcash. Además, cada usuario tiene control de su estrategia de agrupación antes de la entrega a través de los outproxies de mail.i2p, que están separados de los servidores SMTP y POP3 de mail.i2p — tanto los outproxies como los inproxies se comunican con los servidores SMTP y POP3 de mail.i2p a través del propio I2P, por lo que comprometer esas ubicaciones no anónimas no proporciona acceso a las cuentas de correo o patrones de actividad del usuario.