I2P es un proyecto para construir, desplegar y mantener una red que soporte comunicación segura y anónima. Los usuarios de I2P pueden administrar el balance entre el anonimato, fiabilidad, uso de ancho de banda y latencia. No hay un punto central en la red sobre el cual se pueda ejercer presión para comprometer la integridad, seguridad y anonimato del sistema. La red soporta reconfiguración dinámica en respuesta a diversos ataques, y ha sido diseñada para hacer uso de recursos adicionales según vayan estando disponibles. Por supuesto, todos los aspectos de la red son abiertos y están a libre disposición.
A diferencia de la mayoría de las redes anónimas, I2P no intenta proporcionar anonimato ocultando al autor de una comunicación y no al destinatario, o vice versa. Al contrario: I2P está diseñada para permitir a los pares comunicarse unos con otros anónimamente - ambos, quien envía y quien recibe, no son identificables entre ellos y tampoco por terceras partes. Por ejemplo, actualmente hay sitios web I2P internos (permitiendo publicación y hospedaje anónimo) además de proxies HTTP hacia la web normal (permitiendo navegación anónima). Disponer de la posibilidad de correr servidores internamente en I2p es esencial, ya que es bastante probable que cualquier proxy de salida hacia el Internet normal pueda ser monitorizado, desactivado o incluso comprometido para luego intentar más ataques maliciosos.
La red es en sí misma está orientada a mensajes - es en esencia una capa IP segura y anónima donde los mensajes son direccionados hacia claves criptográficas (Destinos) y pueden ser considerablemente más largos que los paquetes IP. Algunos ejemplos del uso de la red incluyen "eepsites" (servidores web hospedando aplicaciones web normales dentro de I2P), un cliente BitTorrent ("I2PSnark"), o un sistema de almacenaje de datos distribuido. Con la ayuda de la aplicación I2PTunnel, somos capaces de correr aplicaciones TCP/IP tradicionales sobre I2P, como SSH, IRC, un proxy Squid, e igualmente streaming de audio. Mucha gente no usará I2P directamente, o mismamente no necesitarán saber que lo están usando. En vez de eso, su percepción será la de una de las aplicaciones I2P habilitadas, o quizá la de una pequeña aplicación de control para activar y desactivar varios proxies que permitan funcionalidades de anonimato.
Una parte esencial de diseñar, desarrollar y probar una red anónima es definir el modelo de amenaza, si partimos de que no existe lo que podría ser considerado anonimato auténtico, solamente se puede hacer más costoso el identificar a alguien. Brevemente, el propósito de I2P es permitir comunicarse a la gente en ambientes arbitrariamente hostiles suministrando buen anonimato, mezclado con suficiente tráfico de cobertura proporcionado por la actividad de gente que requiere menos anonimato. De esta forma algunos usuarios pueden evitar ser detectados por poderosos adversarios, mientras otros intentarán ocultar su identidad de forma más débil, todo en la misma red, donde los mensajes de cada uno son esencialmente indistinguibles de los del resto.
¿Por qué?
Hay múltiples razones por las que necesitamos un sistema que soporte comunicaciones anónimas, y además cada uno tiene si propias razones. Hay muchos otros proyectos en Internet trabajando para encontrar formas de ofrecer varios niveles de anonimato para la gente, pero no habíamos encontrado ninguno que cumpliera nuestras necesidades o el modelo de amenazas.
¿Cómo?
Un vistazo a la red muestra que se compone de una instalación de nodos ("ruters") con un número de rutas virtuales unidireccionales entrantes y salientes (Túneles, como se describen en la página tunnel routing). Cada ruter está identificado por una RouterIdentity cifrada que es e normalmente permanente. Estos ruters se comunican entre ellos a través de mecanismos de transporte existentes (TCP, UDP, etc) enviándose distintos mensajes. Las aplicaciones clientes tienen su propio identificador criptográfico ("Destino") que las habilita para enviar y recibir mensajes. Estos clientes pueden conectarse a cualquier ruter y autorizar la asignación temporal ("arrendamiento") de varios túneles que serán usados para enviar y recibir mensaje a través de la red. I2P tiene su propia base de datos de red (utilizando una modificación del algoritmo Kademlia) para distribuir información de rutas y contactos de forma segura.
En la imagen, Alice, Bob, Charlie y Dave están corriendo ruters con una simple Destinación en su ruter local. Cada uno de ellos tiene un par de túneles de dos saltos entrantes por destino (etiquetados como 1, 2, 3, 4, 5 y 6), y una pequeña parte del grupo de los túneles de salida de esos ruters se representa con túneles de salida de dos saltos. Para simplificar, los túneles entrantes de Charlie y los de salida de Dave no se muestran, tampoco está el resto del grupo de túneles de salida de cada ruter (típicamente compuesto por varios túneles a la vez). Cuando Alice y Bob se comunican entre ellos, Alice envía un mensaje por uno de sus túneles de salida (rosa) en dirección a uno de los túneles entrantes (verde) de Bob (túnel 3 o 4). Ella sabe cómo enviar a los túneles del ruter correcto mediante consultas a la base de datos de red, que está constantemente actualizándose tan pronto cómo son autorizados nuevos contactos y expiran los viejos.
Si Bob quiere contestar a Alice, simplemente utilizará el mismo proceso - envía un mensaje por uno de sus túneles de salida en dirección hacia uno de los túneles de entrada de Alice (túnel 1 o 2). Para hacer las cosas más sencillas, la mayor parte de los mensajes enviados entre Alice y Bob usan el envoltorio de ajo, garlic, incluyendo la información del contrato, lease, del propio remitente para que el receptor pueda responder inmediatamente sin tener que mirar en la base de datos de la red por ellos.
Para tratar con un amplio rango de ataques, I2P es completamente distribuida sin recursos centralizados - no hay servidores manteniendo estadísticas sobre el rendimiento y fiabilidad de los ruters dentro de la red. De esta forma cada ruter debe guardar y mantener los perfiles de varios ruters y es responsable de seleccionar los pares apropiados para satisfacer el anonimato, rendimiento y fiabilidad requeridos por los usuarios tal y como se describe en la página de selección de pares.
La red hace uso de un gran número de técnicas criptográficas y algoritmos - una lista completa incluye el cifrado El Gamal de 2048 bits, AES de 256 bits en modo CBC con relleno PKCS#5, firmas DSA de 1024 bits, hashes SHA256, negociación de conexiones Diffie-Hellman de 2048 bits con autenticación estación a estación y ElGamal / AES+SessionTag.
El contenido enviado sobre I2P está cifrado a través del cifrado garlic de tres capas (usado para verificar la entrega del mensaje a destinatario), cifrado de túnel (todos los mensajes cruzando a través de un túnel están cifrados desde el túnel de salida hasta el túnel de destino final) y cifrado de la capa de transporte inter-router (e. g. el transporte TCP usa AES256 con claves efímeras).
End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a" to Bob's router "h" remains. Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end encrypted! A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.
El uso específico de estos algoritmos está descrito en otra parte.
Los dos mecanismos principales que permiten usar la red a gente que necesita un fuerte anonimato son explícitamente mensajes enrutados garlic con retardo y túneles más completos que incluyan agrupamiento y mezcla de mensajes. Estos están actualmente planeados para la release 3.0, pero los mensajes enrutados garlic sin retardo y túneles FIFO están ya implementados. Adicionalmente la versión 2.0 permitirá a los usuarios establecerse y operar detrás de ruters restrictivos (puede que con pares de confianza), así como el despliegue de transportes más flexibles y anónimos.
Han surgido algunas preguntas referentes a la escalabilidad de I2P. Habrá ciertamente más análisis con el tiempo, pero la búsqueda e integración de pares debería ser limitado por O(log(N)) debido al algoritmo de base de datos de red, mientras que los mensajes punto a punto serían O(1) (escala libre), puesto que los mensajes pasan por K saltos a través del túnel de salida y otros K saltos por el túnel de entrada, donde K no es mayor de 3. El tamaño de la red (N) no acarrea impacto.
¿Cuándo?
I2P comenzó inicialmente en 2003 como una propuesta de modificar
Freenet para permitir el uso de transportes alternativos, como puede ser
¿Quiénes?
Tenemos un pequeño equipo desperdigado por varios continentes y trabajando en el avance de diferentes aspectos del proyecto. Estamos abiertos a otros desarrolladores que deseen involucrarse en el proyecto, y a cualquier otra persona que quiera contribuir de cualquier forma, como críticas, revisión de pares, pruebas, programación de aplicaciones compatibles I2P, o documentación. El sistema completo es código abierto - el ruter y la mayor parte del SDK tienen licencia de dominio público con algo de código licenciado con BSD y Cryptix, mientras que aplicaciones como I2PTunnel e I2PSnark son GPL. Casi todo está escrito en Java (1.5+), aunque algunas aplicaciones de terceros están siendo escritas en Python u otros lenguajes. El código funciona en Sun Java SE y otras máquinas virtuales Java.
¿Dónde?
Cualquier interesado debe unirse a nosotros en el IRC en el canal #i2p-dev (alojado concurrentemente en irc.freenode.net, irc.postman.i2p, irc.echelon.i2p, irc.dg.i2p and irc.oftc.net). Actualmente no hay reuniones de desarrollo programadas, sin embargo los archivos están disponibles.
The current source is available in git.