Esta página fue actualizada por última vez el Noviembre de 2016.

Tor / Onion Routing

[Tor] [Onion Routing]

Tor y el rutado Onion son ambas redes de proxies anónimas, que permiten a la gente salir a través de su red ya mezclada de baja latencia. Las dos primeras diferencias entre Tor/Onion-Routing e I2P están de nuevo relacionas con las diferencias en el modelo de amenazas y el diseño de los outproxies (a través de Tor soporta también servicios ocultos). Además, Tor usa un enfoque basado en directorios - creando un punto central para manejar la 'vista' general de las redes, y además se obtienen más estadísticas, al contrario que la base de datos de la red dsitribuida de I2P y la selección de pares.

El outproxy de I2P/Tor tiene varias debilidades contra cierto tipo de ataques - una vez que la comunicación deja la red Tor, adversarios pasivos pueden hacer más fácilmente ataques de análisis. Además los outproxies tienen acceso al texto en claro transferido en las dos direcciones, y los outproxies son propensos a abusos, y además tenemos que tener en cuenta otros ataques posibles dentro del Internet normal.

Aún así, mucha gente no tiene por que preocuparse por estas situaciones, ya que no están dentro del modelo de amenazas. Y además esto está fuera del alcance (formal) de I2P (si la gente desea construir un outproxy sobre la capa de comunicación anónima, pueden hacerlo). De hecho, actualmente algunos usuarios utilizan el outproxy de Tor.

Comparación de la terminología de I2P y Tor

Mientras que Tor e I2p tienen algunas similitudes, mucha de la terminología cambia.

TorI2P
CeldaMensaje
ClienteRuter o Cliente
CircuitoTúnel
DirectorioNetDb, base de datos de la red
Servidor de directoriosRuter Floodfill o de relleno
Control de entradasPares rápidos
Nodo de entradaInproxy, proxy de entrada
Nodo de salidaOutproxy, o proxy de salida
Servicio ocultoServicio oculto, I2P Site or Destination
Descriptor de servicio ocultoLeaseSet
Punto de introducciónPuerta de salida de entrada
NodoRuter
Proxy OnionCliente de I2PTunnel (más o menos)
Servicio OnionServicio oculto, I2P Site or Destination
RelayRuter
Punto de reuniónalgo así como inbound Gateway + Outbound Endpoint, puerta de salida de entrada + punto final de salida
Descriptor del ruterInformación del ruter
ServidorRuter

Beneficios de Tor sobre I2p

  • El número de usuarios es mucho mayor; mucho más visible en entorno académicos y comunidades de hackers; tiene los beneficios de tener estudios formales sobre el anonimato, resistencia y rendimiento; y tienen un líder no anónimo universitario y visible
  • Ha resuelto ya algunos problemas de escalado que I2P aún debe arreglar.
  • Tiene muchos fondos
  • Tiene más desarrolladores, incluso algunos con fondos
  • Tiene un bloqueo de nivel de estado más resistente debido la capa de transporte TLS y a los puentes (I2P tienen propuestas de "rutas completamente restringidas" pero estas aún no están implementadas)
  • Es tan grande que incluso se ha adaptado para bloquear los intentos de DOS
  • Diseñado para optimizar el tráfico de salida, con un gran número de nodos de salida
  • Mejor documentación, tiene estudios formales y especificaciones, una web mejor, y muchas traducciones
  • Más eficiente con el uso de la memoria
  • Los nodos cliente de Tor tienen muy poco gasto de ancho de nada
  • El control centralizado reduce la complejidad de cada nodo y puede evitar ataques Sybil fácilmente
  • Un núcleo de nodos de gran capacidad proporciona una mayor rendimiento y menor latencia
  • C, no java (ey!)

Beneficios de I2P sobre Tor

  • Diseñado para optimizar los servicios ocultos, que son mucho más rápidos que los de Tor
  • Totalmente distribuido y auto organizado
  • Los pares son seleccionados continuamente según el rendimiento y categoría, en vez de confiar en la capacidad indicada
  • Los pares Floodfill ("servidores de directorios") cambian, en vez de estar siempre fijos.
  • Tan pequeña que no ha sido bloqueada o Dosed.
  • Amigable con las aplicaciones p2p
  • Conmutado por paquete en vez de conmutado por circuito
    • Implica control de carga transparente de los mensajes a través de múltiples pares, en vez de por un sólo camino.
    • Resistencia contra fallos ya que usa varios túneles en paralelo, además de rotar los túneles
    • el número de conexiones en i2p vienen dado por O(1) en vez de O(N) (por ejemplo, Alice tiene 2 túneles de entrada que son usados por todos los pares con lo que habla Alice, en vez de un circuito por cada par)
  • Túneles unidireccionales en vez de circuitos bidireccionales, usando el doble de nodos un par se compromete más para obtener la misma información. Contra-argumentos y discusión adicional aquí.
  • Protección contra la detección de la actividad de un cliente, incluso cuando un atacante participa en el túnel, ya que los túneles no son sólo usados para pasar el mensaje de punto a punto (por ejemplo, netDB, administración de túneles, pruebas en los túneles)
  • Los túneles de I2P tienen una vida corta, reduciendo el número de muestras que un atacante puede usar para lograr un ataque activo, al contrario que con los circuitos en Tor, que son típicamente de larga duración.
  • Los APIs de I2P están específicamente diseñados para el anonimato y la seguridad, mientras que SOCKS está diseñado para su funcionalidad.
  • Básicamente todos los pares participan en el rutado de otros
  • El uso de ancho de banda de cualquier par completo es bajo, mientras que en Tor, aunque un nodo cliente no necesita mucho ancho de banda, realmente no participan completamente en la red.
  • Sistema integrado de actualizaciones automáticas
  • Ambos tipos de transporte, TCP y UDP
  • Java, en vez de C (ewww)

Otros beneficios potenciales de I2P aún no implementados

...y puede ser que nunca lleguen a ser implementados, ¡osea que no cuente con ellos!

  • Defensa contra el análisis de conteo de mensajes envolviendo múltiples mensajes dentro de la red garlic
  • Defensa contra la intersección a largo plazo añadiendo demoras en varios saltos (donde las demoras no son perceptibles por los otros saltos)
  • Varias estrategias de mezclado a nivel del túnel (por ejemplo, creando túneles que manejarán 500 mensajes al minuto, donde el punto final inyectará mensajes de relleno si no hubiese suficientes mensajes, etc)