NOTA: Este documento fue escrito originalmente por jrandom en 2003. Aunque nos esforzamos por mantenerlo actualizado, parte de la información puede estar obsoleta o incompleta. Las secciones de transporte y criptografía están actualizadas a partir de enero de 2025.
Introducción
I2P es una capa de red anónima escalable, auto-organizada y resistente que utiliza conmutación de paquetes, sobre la cual puede operar cualquier número de aplicaciones diferentes que se preocupen por el anonimato o la seguridad. Cada una de estas aplicaciones puede hacer sus propios compromisos 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 están ejecutándose sobre I2P.
Las aplicaciones ya disponibles proporcionan la gama completa de actividades típicas de Internet — navegación web anónima, alojamiento web, chat, intercambio de archivos, correo electrónico, blogging 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 impulsados por 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 papel del middleware orientado a mensajes — las aplicaciones indican que quieren enviar algunos datos a un identificador criptográfico (un “destination”) e I2P se encarga de asegurar que lleguen allí 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 en orden, ofreciendo de manera transparente un algoritmo de control de congestión basado en TCP ajustado para el alto producto de ancho de banda y retraso 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 garantizar su operación adecuada 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 a tiempo completo y un grupo dedicado de contribuyentes a tiempo parcial de todo el mundo. Todo el trabajo realizado en I2P es de 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 hace uso de algunas rutinas criptográficas bajo licencias estilo BSD. Las personas que trabajan en I2P no controlan bajo qué licencia las personas publican las aplicaciones cliente, y hay varias aplicaciones con licencia GPL disponibles (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 también anónimos.
Operación
Resumen
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 normalmente no es un secreto. Lo que se oculta es información sobre lo que está haciendo el usuario, si es que está haciendo algo, así como a qué router está conectado un destination particular. Los usuarios finales típicamente tendrán varios destinations locales en su router — por ejemplo, uno que hace proxy hacia 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 a 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 pueden enviarse solo 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 hacia el creador del tunnel. Combinando estos dos tunnels, los usuarios pueden 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 hacia el gateway del tunnel de entrada. Para hacer esto, el remitente (“Alice”) agrega instrucciones a su mensaje cifrado. Una vez que el endpoint del tunnel de salida descifra el mensaje, tendrá las instrucciones para reenviar el mensaje al gateway de entrada correcto (el gateway hacia “Bob”).
Un tercer concepto crítico que se debe entender es la “network database” (o “netDb”) de I2P — un par de algoritmos utilizados para compartir metadatos de la 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 un número de “leases”. Cada uno de estos leases especifica una pasarela de túnel, 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.
- Tiempo cuando 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 su routerInfo directamente a la netDb, mientras que los leaseSets se envían a través de tunnels de salida (los leaseSets necesitan ser enviados 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 la 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 hace una búsqueda en la netDb para encontrar el leaseSet de Bob, obteniendo así sus gateways de túnel de entrada actuales. Luego elige 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 de túnel de entrada de Bob lo recibe, se reenvía a través del túnel al 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 tunnels en sí tienen cifrado por capas para prevenir la divulgación no autorizada a pares dentro de la red (como la capa de transporte misma lo hace 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 tunnel de salida y la puerta de enlace del tunnel de entrada. Este “garlic encryption” permite que el router de Alice empaquete múltiples mensajes en un solo “mensaje garlic”, cifrado con una clave pública particular para que los pares intermediarios no puedan determinar ni cuántos mensajes hay dentro del garlic, qué dicen esos mensajes, o hacia 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 con 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 se beneficiarían más reutilizando la biblioteca de streaming proporcionada para ver I2P como una red basada en flujos.
Tunnels
Tanto los túneles entrantes como salientes funcionan según principios similares. El gateway del túnel acumula varios mensajes de túnel, eventualmente preprocesándolos en algo para la entrega del túnel. A continuación, el gateway cifra esos datos preprocesados y los reenvía al primer salto. Ese peer y los participantes posteriores del túnel agregan una capa de cifrado después de verificar que no sea un duplicado antes de reenviarlo al siguiente peer. Eventualmente, el mensaje llega al endpoint donde los mensajes se dividen nuevamente y se reenvían según se solicite. La diferencia surge en lo que hace el creador del túnel: para los túneles entrantes, el creador es el endpoint y simplemente descifra todas las capas agregadas, mientras que para los túneles salientes, el creador es el gateway y pre-descifra todas las capas para que después de que se agreguen todas las capas de cifrado por salto, el mensaje llegue en claro al endpoint del túnel.
La elección de peers específicos para transmitir mensajes, así como su ordenamiento particular, es importante para entender tanto las características de anonimato como de rendimiento de I2P. Mientras que la network database (netDb) (base de datos de red) tiene sus propios criterios para elegir qué peers consultar y en cuáles almacenar entradas, los creadores de tunnel pueden usar cualquier peer 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 ordenamiento estarían impulsados por las necesidades particulares del cliente en conjunto con su modelo de amenazas. Desafortunadamente, los datos de latencia y capacidad no son triviales de recopilar de forma anónima, y depender de peers no confiables para proporcionar esta información tiene sus propias serias implicaciones de anonimato.
Desde una perspectiva de anonimato, la técnica más simple sería elegir peers aleatoriamente de toda la red, ordenarlos aleatoriamente y usar esos peers en ese orden por toda la eternidad. Desde una perspectiva de rendimiento, la técnica más simple sería elegir los peers más rápidos con la capacidad libre necesaria, distribuyendo la carga entre diferentes peers para manejar la conmutación por error transparente, y reconstruir el tunnel cuando cambie la información de capacidad. Mientras que el primero es tanto frágil como ineficiente, el último requiere información inaccesible y ofrece anonimato insuficiente. I2P está trabajando en ofrecer una gama 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 consulta netDb en 1.3 segundos, esa latencia de ida y vuelta se registra en los perfiles de todos los routers involucrados en los dos túneles (entrante y saliente) a través de los cuales pasaron la solicitud y respuesta, así como en el perfil del peer consultado. No se utiliza la medición directa, como la latencia de la capa de transporte o la congestión, 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 alta capacidad, alta capacidad, sin fallas, y con fallas. 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 pares más simple y razonable es elegir pares aleatoriamente del nivel superior (rápidos y de alta capacidad), y esto está actualmente desplegado para túneles cliente. Los túneles exploratorios (usados para netDb y gestión de túneles) eligen pares aleatoriamente del nivel “no fallando” (que incluye también routers de niveles ‘mejores’), permitiendo al par muestrear routers de manera más amplia, en efecto optimizando la selección de pares a través de escalada aleatoria de colinas . Sin embargo, estas estrategias por sí solas filtran información sobre los pares en el nivel superior del router a través de ataques de recolección de predecesores y netDb. A su vez, existen varias alternativas que, aunque no equilibran la carga tan uniformemente, 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 fallas de los peers y la rotación del nivel. Otra estrategia simple para lidiar con ataques de recolección de netDb es simplemente fijar las gateway de túneles de entrada pero aleatorizar los peers más adelante en los túneles. Para lidiar con ataques de predecesor por parte de adversarios que el cliente contacta, los endpoints de túneles 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 ajustarse de manera reactiva o evitarse de manera proactiva para imitar un tiempo medio medido entre fallas 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, usando peers individuales solo 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. Se puede encontrar una discusión más detallada de los mecanismos involucrados en la operación, gestión y selección de pares de túneles en la especificación de túneles .
Base de Datos de Red (netDb)
Como se mencionó anteriormente, la 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 de 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 llaman ‘floodfills’. Los routers pueden configurarse manualmente como floodfills, o convertirse automáticamente en floodfill si tienen suficiente capacidad y cumplen otros criterios para una operación 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’ actualmente funcionan de manera diferente, para evitar un problema de seguridad importante. Cuando se realiza una búsqueda, el router floodfill no reenviará la búsqueda 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 temporización, 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 de pool.ntp.org por defecto) y detectando desfases entre routers en la capa de transporte.
Algunas observaciones adicionales también son importantes.
LeaseSet 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 la netDb. Sin embargo, tendrás que transmitir el destino por otros medios. Esto es compatible con los ’encrypted leaseSets’. 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 a 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 determinado. Los detalles particulares de cómo los routers se comunican con otros routers no son críticos — se han utilizado tres protocolos separados en diferentes momentos para proporcionar esas necesidades básicas.
I2P actualmente admite 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 admiten tanto IPv4 como IPv6. Al admitir transportes tanto TCP como UDP, I2P puede atravesar eficazmente 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 encriptación modernos, mejorar la resistencia a la identificación de tráfico, aumentar la eficiencia y seguridad, y hacer que el atravesado de NAT sea más robusto. Los routers publican cada transporte admitido y dirección IP en la base de datos de red. Los routers con acceso a redes IPv4 e IPv6 públicas usualmente publicarán cuatro direcciones, una para cada combinación de NTCP2/SSU2 con IPv4/IPv6.
SSU2 soporta y extiende 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 sobre UDP, SSU2 proporciona facilidades especializadas para detección cooperativa de direcciones IP punto a punto, detección de cortafuegos 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 para terceros. Debe soportar comunicación de alto grado así como control de congestión compatible con TCP y puede incluir detección PMTU. Debe ser capaz de mover datos masivos de manera eficiente 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 soporta 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 soporta múltiples transportes simultáneamente. Un transporte particular para una conexión saliente se selecciona con “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 extremo a extremo (garlic). El diseño original de I2P utilizaba un conjunto pequeño 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 soporte. Esto nos permite actualizar y extender periódicamente el soporte de la red para criptografía moderna y preparar la red para el futuro con nuevas primitivas, sin romper la compatibilidad hacia atrás o requerir un “día de 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, las firmas EdDSA, el cifrado simétrico autenticado ChaCha20/Poly1305 y los hashes SHA-256. AES256 aún 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 soportadas por la mayoría de las implementaciones para mantener 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 a 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 pasan a través de los transportes tienen su propio cifrado en capas. Varios otros mensajes se pasan dentro de “garlic messages”, que también están cifrados.
Mensajes Garlic
Los mensajes garlic son una extensión del cifrado por 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 siempre que el mensaje pasaría en texto plano a través de un par 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 encriptación incluyen la capacidad de solicitar que el clove sea reenviado localmente, a un router remoto, o a un túnel remoto en un router remoto. Hay campos en esas instrucciones que permiten a un par solicitar que la entrega se retrase hasta que se cumpla 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 túneles, o incluso reencaminar mensajes de túnel envolviéndolos en mensajes garlic y reenviándolos un número de saltos antes de entregarlos al siguiente salto en el túnel, pero estas técnicas no se utilizan 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 garlic messages. 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 sigue siendo compatible, la mayor parte 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 agregan 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 no cifrada, así como una cantidad de “session tags” — 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 seleccionan uno de los session tags previamente entregados y cifran la carga útil con AES como antes, usando la clave de sesión utilizada con ese session tag, precedida por el session tag mismo. Cuando un router recibe un mensaje cifrado garlic, verifican los primeros 32 bytes para ver si coincide con un session tag disponible — si coincide, simplemente descifran el mensaje con AES, pero si no coincide, descifran el primer bloque con ElGamal.
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 agrupando 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 tunnel entrante, por supuesto). Cuando el remitente original recibe este mensaje de estado de entrega, sabe que las etiquetas de sesión agrupadas en el mensaje garlic fueron entregadas exitosamente.
Los session tags en sí mismos 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í mismas: si llegan demasiadas, pueden descartarse mensajes nuevos o antiguos. El remitente realiza un seguimiento de si los mensajes que usan session tags están llegando a destino, y si no hay comunicación suficiente puede descartar los que previamente 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 perjudicada 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 el cifrado simétrico autenticado. Las claves de cifrado son “double ratcheted” 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 HMAC SHA-256, y se inicializa desde el resultado DH X25519. 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 de sesión o clave porque no se envían por adelantado; pueden generarse bajo demanda. Al mantener este PRNG aproximadamente sincronizado entre el emisor y el destinatario (el destinatario precalcula una ventana de las siguientes, por ejemplo, 50 etiquetas), se elimina la sobrecarga de agrupar periódicamente un gran número 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 mejoras adicionales para satisfacer las necesidades de aquellos que enfrentan adversarios poderosos patrocinados por el estado, y para hacer frente a las amenazas de los continuos avances criptográficos y el poder computacional en constante aumento. Dos posibles características, 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 de extremo a extremo para ofrecer anonimato y seguridad. Aunque Internet ya no adopta completamente el principio de 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 a lo largo de los bordes ejecutándose usando rutas restringidas, pero I2P no incluye un algoritmo de enrutamiento apropiado para el caso degenerado donde la mayoría de peers no son accesibles. Sin embargo, funcionaría sobre una red que emplee tal algoritmo.
La operación de rutas restringidas, donde existen límites a 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 fue abordado en gran medida integrando el perforado distribuido de holes 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 pueden simplemente ser introducidos al peer a través del introductor publicado.
Más allá del manejo funcional de rutas restringidas, hay dos niveles de operación restringida que pueden usarse para limitar la exposición de la dirección IP de uno — usando túneles específicos del router para comunicación, y ofreciendo ‘client routers’. Para el primero, los routers pueden construir un nuevo pool de túneles o reutilizar su pool exploratorio, publicando las puertas de enlace 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 esas puertas de enlace de túnel en la netDb y simplemente envía el mensaje relevante a través de uno de los túneles 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 túneles de salida. Cuando los routers a los que el peer tiene conexiones directas quieren alcanzarlo (para reenviar mensajes de túnel, por ejemplo), simplemente priorizan su conexión directa sobre la puerta de enlace de túnel publicada. El concepto de ‘client routers’ 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 autofirmado a los peers que contacta (necesario para pasar las claves públicas del router).
Existen compromisos para aquellos detrás de rutas restringidas, ya que probablemente participarían en los túneles 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 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 ampliamente abandonado. Varias mejoras relacionadas han reducido considerablemente la necesidad de las mismas. Ahora soportamos UPnP para abrir automáticamente 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 se construya el tunnel. GeoIP y la identificación por 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 pensando en servicios de latencia variable. A 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. Sin embargo, internamente, I2P puede ofrecer su propia comunicación de latencia media y alta a través del garlic encryption, especificando que el mensaje debe ser enviado después de cierto retraso, en un momento determinado, después de que haya pasado cierto número de mensajes, o con otra estrategia de mezcla. Con el cifrado en capas, solo el router 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 en sí mismo probablemente sería un mensaje garlic) simplemente lo reenvía según se solicitó: a un router, a un tunnel, o, más 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 los 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. El valor no proviene de conceptos novedosos o algoritmos, sino de una ingeniería cuidadosa que combina los resultados de investigación de sistemas y documentos 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.
Ver también la Página de Comparaciones de Red . 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 esfuerzos en etapa temprana de Tor, muchas de las lecciones del onion routing original y los esfuerzos de ZKS fueron integradas 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 por capas y ordenadas (tunnels y circuits/streams), I2P es fundamentalmente una red de conmutación de paquetes, mientras que Tor es fundamentalmente de conmutación de circuitos, lo que permite a I2P enrutar transparentemente alrededor de la congestión u otras fallas de red, operar rutas redundantes y balancear la carga de datos a través de los recursos disponibles. Mientras que Tor ofrece la útil funcionalidad de outproxy al ofrecer descubrimiento y selección integrada de outproxy, I2P deja tales decisiones de capa de aplicación a las aplicaciones que se ejecutan sobre I2P — de hecho, I2P incluso ha externalizado la propia biblioteca de streaming similar a TCP a la capa de aplicación, permitiendo a los desarrolladores experimentar with diferentes estrategias, explotando su conocimiento específico del dominio para ofrecer mejor rendimiento.
Desde una perspectiva de anonimato, hay muchas similitudes 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 los 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 la misma ruta en Tor, mientras que en I2P los paquetes que conforman la solicitud saldrían a través de uno o más tunnels salientes y los paquetes que conforman la respuesta regresarían a través de uno o más tunnels entrantes diferentes. Aunque las estrategias de selección y ordenamiento de pares de I2P deberían abordar suficientemente los ataques predecesores, si fuera necesario cambiar a tunnels bidireccionales, simplemente podríamos construir un tunnel entrante y saliente a lo largo de los mismos routers.
Otro problema de anonimato surge en el uso de Tor de la creación de túneles telescópicos, 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. I2P utiliza creación de tunnel unidireccional con un solo mensaje para que estos datos no queden expuestos. Proteger la posición en un tunnel es importante, ya que de lo contrario un adversario podría 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 para ofrecer proxy de salida a Internet anónimo de alta velocidad, mientras que I2P trabaja para ofrecer una red descentralizada y resistente 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 podrá explotar los recursos escasos de manera más efectiva.
Freenet
Freenet jugó un papel importante en las etapas iniciales del diseño de I2P — demostrando la viabilidad de una comunidad pseudónima vibrante completamente contenida dentro de la red, probando 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 debía mantenerse estrictamente en proporcionar una capa de comunicación anónima genérica, en lugar de ser un componente de Freenet. A lo largo de los años, los desarrolladores de Freenet han llegado a ver las debilidades del diseño anterior, lo que los llevó a sugerir que requerirían una capa “premix” para ofrecer un 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 hacia los “nodos servidor” que luego obtienen y almacenan los datos según los algoritmos heurísticos de almacenamiento de datos distribuido de Freenet.
La funcionalidad de Freenet es muy complementaria a la de I2P, ya que Freenet proporciona nativamente muchas de las herramientas para operar sistemas de latencia media y alta, mientras que I2P proporciona nativamente 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, por lo que esperamos que el equipo de Freenet persiga 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í mismo no hace realmente mucho — 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 que una variedad de aplicaciones de red 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 equilibrio razonable entre los costos de ancho de banda de retransmitir mensajes perdidos y la latencia de múltiples mensajes.
Además, considerando el 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 transmitidos contengan tanta información como esté disponible. Por ejemplo, una transacción HTTP pequeña procesada 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 carga útil pequeña (una solicitud HTTP típicamente cabe) y la respuesta agrupa el SYN, FIN, ACK y la carga útil pequeña (muchas respuestas HTTP caben). Aunque un ACK adicional debe transmitirse 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 parece 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
La nomenclatura dentro de I2P ha sido un tema muy debatido desde el principio, con defensores a lo largo 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 absoluta”. En su lugar, I2P viene con una biblioteca de nomenclatura genérica y una implementación base diseñada para funcionar con un mapeo local de nombre a destination, así como una aplicación complementaria opcional llamada “Address Book” (Libreta de Direcciones). La libreta de direcciones es un sistema de nomenclatura legible por humanos, seguro, distribuido e impulsado por web of trust, sacrificando únicamente la exigencia de que todos los nombres legibles por humanos sean globalmente únicos al requerir solo unicidad local. Mientras que todos los mensajes en I2P están direccionados criptográficamente por su destination, diferentes personas pueden tener entradas locales en la libreta de direcciones para “Alice” que se refieran a destinations diferentes. Las personas aún pueden descubrir nuevos nombres importando libretas de direcciones 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 libretas de direcciones publicadas usando un sistema de registro por orden de llegada) las personas pueden elegir tratar estas libretas de direcciones como servidores de nombres, emulando el DNS tradicional.
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 la respuesta falsificada, 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 determinado. Los métodos de prueba de trabajo pueden utilizarse 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 impracticable, o si no se consulta toda la red, pueden ser alcanzables diferentes conjuntos de respuestas.
Sin embargo, al igual que con Internet, I2P mantiene el diseño y funcionamiento 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 compensaciones 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. Hay 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 “httpclient” de I2PTunnel ofrece un punto de enganche para el 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 “servidor” de I2PTunnel ejecutadas por voluntarios que han elegido explícitamente ejecutar outproxies — nadie es un outproxy por defecto, y ejecutar un outproxy no le 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 a cualquiera ejecutar su propio sitio web anónimo (o “Sitio I2P”) — un servidor web está incluido con I2P para este propósito, pero cualquier servidor web puede ser usado. Cualquiera puede ejecutar un “client” que apunte a uno de los servidores IRC alojados anónimamente, cada uno de los cuales está ejecutando un “server” que apunta a su IRCd local y comunicándose 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 la gente ha incluso 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 tanto correo electrónico interno como 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 pseudónima. Sin embargo, como la mayoría de los clientes de correo exponen información identificativa sustancial, I2P incluye el cliente susimail basado en web de susi23 que ha sido construido específicamente teniendo en cuenta las necesidades de anonimato de I2P. El servicio I2Pmail/mail.i2p ofrece filtrado de virus transparente así como prevención de denegación de servicio con cuotas aumentadas por hashcash. Además, cada usuario tiene control de su estrategia de agrupamiento 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 da acceso a las cuentas de correo o patrones de actividad del usuario.