mirror of
https://github.com/oxen-io/lokinet.git
synced 2024-10-31 09:20:21 +00:00
147 lines
5.5 KiB
Plaintext
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
|
|
|
|
|
|
|