lokinet/docs/spanish/vision-general.txt

147 lines
5.5 KiB
Plaintext

LLARP - Low Latency Anon Routing Protocol - Protocolo de Enrutado Anónimo de Baja Latencia
Resumen TL;DR: un router onion con una interfaz tun para transportar paquetes ip
de forma anónima entre usted y la internet, y desde dentro de ella hacia otros usuarios.
Este documento describe la visión general de LLARP, detalla todas las metas
del proyecto, lo que no son metas y la arquitectura de la red desde una perspectiva
general.
Prefacio
Trabajar en I2P ha sido experiencia realmente grande para todo el que se involucra.
Después bastante deliberación, yo decidí empezar a construir un protocolo onion de
"proxima generacion". LLARP es específicamente (en la actualidad) un proyecto de
investigación para explorar la siguiente cuestión:
"¿Que hubiera sido si I2P fuera construido en el año presente (2018)? ¿Que hubiera
sido diferente?"
Lo que No son Metas del Proyecto:
Este proyecto no intenta resolver la correlación por la forma del tráfico o ataques a
la red patrocinadas por el estado. Lo primero es una propiedad inherente de las redes
computacionales de baja latencia que yo personalmente no pienso que es posible
completamente "resolver" de forma apropiada. Lo segundo es una amenaza que por el
momento se encuentra fuera de los alcances de las herramientas actuales que me están
disponibles.
Este proyecto no pretende ser la aplicación mágica de nivel curalotodo para la
aplicación o la seguridad del usuario final. Después de todo, eso es un problema que
existe entre la silla y el teclado.
La Única Meta del Proyecto:
LLARP en una suite de protocolos que pretende mantener anónima la IP mediante el
ofrecimiento de un agente de túnel anónimo a nivel red (IPv4/IPv6) tanto para
"servicios ocultos" y la comunicación de regreso a la "red transparente" (la Internet
comun). Tanto las comunicación del servicio oculto y la red transparente DEBEN
permitir tanto el trafico de salida y el tráfico de entrada a nivel red sin implementar
NAT alguna (con excepción de la IPv4 de la cual la NAT es permitida debido a la
escasez de direcciones).
En concreto, Queremos permitir tanto la salida y la entrada anonima del trafico
a nivel red entre las redes habilitadas por LLARP y la Internet.
Las razones de porque empezar desde cero:
A pesar de los mejores esfuerzos del Proyecto Tor para popularizar el uso de Tor,
Tor2Web parece ser ampliamente popular para las personas que no desean optar estar
dentro del ecosistema. Mi solucion propuesta seria permitir el tráfico de entrada desde
los "nodos de salida" en adición de permitir el tráfico de salida. No tengo idea
en cómo pudiera hacer esto los protocolos actuales en Tor, o si es posible o
recomendable intentar tal cosa ya que no estoy familiarizado con su ecosistema.
I2P se hubiera usado como un medio para transito anonimo IP cifrado pero la red actual
tiene problemas con la latencia y el rendimiento. Avanzar I2P sobre criptografía
moderna está en proceso dentro de I2P, proceso que ya lleva por lo menos 5 años y con
menos progreso que lo deseado. Así como algunos antes de mi, yo he llegado a la
conclusión que seria mas rapido rehacer todo el stack "de la forma correcta" que estar
esperando a que I2P termine sus avances. Dicho esto, nada está previniendo a I2P en ser
usado para el transito de trafico anonimo IP cifrado dentro de un futuro en que I2P
termine sus migraciones de protocolo, pero yo no quiero esperarlo.
En concreto, yo quiero tomar las "mejores partes" de Tor e I2P, y hacer una nueva
suite de protocolos.
Para ambos, tanto Tor e I2P, les tengo 2 categorías de sus atributos.
lo bueno
lo malo y lo feo
Lo bueno (I2P):
I2P apunta a proveer una capa de red anónima de carga balanceada insuplantable.
Yo quiero esta característica
I2P tiene agilidad de confianza, no necesita tener alguna confianza integrada en el
código dentro de su arquitectura de red. Incluso la fase de arranque de la red puede
realizarse desde un solo router, si el usuario lo desea (aunque esto esté desaconsejado)
Yo quiero esta característica
Lo bueno (Tor):
Tor abarca la realidad de la actual infraestructura de la Internet al tener una
arquitectura cliente/servidor. Esto permite tener barreras de acceso muy bajas
para usar la red Tor, y barreras más altas de acceso para contribuir a la
infraestructura de enrutado. Esto promueve una forma saludable de red con servidores
de alta capacidad ofreciendo servicios a clientes de baja capacidad que "se cuelgan
del extremo" de la red.
Yo quiero esta característica
Lo malo y lo feo (I2P):
Malo: I2P usa criptografia vieja, en especial ElGamal de 2048 bits usando primos no
estandares. El uso de ElGamal es tan constante a traves del stack del protocolo I2P
que existe en cada nivel suyo. Removerlo es una tarea masiva que está tomando
mucho MUCHO tiempo.
Yo no quiero esta característica
Feo: I2P no puede actualmente mitigar la mayoría de los ataques Sybil, con su
actual arquitectura de red. I2P recientemente añadió algunas soluciones de listas de
bloqueo que están firmadas por los firmantes de lanzamiento, pero esto es probable que
no escale en el evento de una ataque "grande". Además I2P tampoco tiene el personal
para ese tipo de ataques.
Este es un problema difícil de resolver en que la red Loki pudiera ayudar con la
creación de una barrera financiera para correr múltiples relays.
Lo malo y lo feo (Tor):
Malo: Tor está estrictamente orientado al TCP.
Yo no quiero esta característica