mirror of
https://github.com/oxen-io/lokinet.git
synced 2024-11-07 15:20:31 +00:00
142 lines
4.6 KiB
Plaintext
142 lines
4.6 KiB
Plaintext
LLARP - Low Latency Anon Routing Protocol
|
|
|
|
|
|
This document describes the high level outline of LLARP, specific all the
|
|
project's goals, non-goals and network architecture from a bird's eye view.
|
|
|
|
|
|
Preface:
|
|
|
|
|
|
Working on I2P has been a really big learning experience for everyone involved.
|
|
After much deliberation I have decided to start making a "next generation" onion
|
|
routing protocol. Specifically LLARP is (currently) a research project
|
|
to explore the question:
|
|
|
|
|
|
"What if I2P was made in the current year (2018)? What would be different?"
|
|
|
|
|
|
Project Non Goals:
|
|
|
|
|
|
This project does not attempt to solve traffic shape correlation or active nation
|
|
state sponsored network attacks. The former is an inherit property of low latency
|
|
computer networks that I personally do not think is possible to properly fully
|
|
"solve". The latter is a threat that lies outside the scope of what the current
|
|
toolset that is available to me at the moment.
|
|
|
|
|
|
This project does not attempt to be a magical application level cure-all for
|
|
application or end user security. At the end of the day that is a problem that
|
|
exists between chair and keyboard.
|
|
|
|
|
|
The Single Project Goal:
|
|
|
|
|
|
LLARP is a protocol suite meant to anonymize IP by providing an anonymous
|
|
network level (IPv4/IPv6) tunnel broker for both "hidden services" and
|
|
communication back to "the clearnet" (the normal internet). Both hidden service
|
|
and clearnet communication MUST permit both outbound and inbound traffic on the
|
|
network level without any NAT (expect for IPv4 in which NAT is permitted due to
|
|
lack of address availability).
|
|
|
|
|
|
In short We want to permit both anonymous exit and entry network level traffic
|
|
between LLARP enabled networks and the internet.
|
|
|
|
|
|
Rationale for starting over:
|
|
|
|
|
|
Despite Tor Project's best efforts to popularize Tor use, Tor2Web seems to be
|
|
widely popular for people who do not wish to opt into the ecosystem. My proposed
|
|
solution would be to permit inbound traffic from "exit nodes" in addition to
|
|
allowing outbound exit traffic. I have no ideas on how this could be done with
|
|
the existing protocols in Tor or if it is possible or advisable to attempt such
|
|
as I am not familiar with their ecosystem.
|
|
|
|
|
|
I2P could have been used as a medium for encrypted anonymous IP transit but the
|
|
current network has issues with latency and throughput. Rebasing I2P atop more
|
|
modern cryptography has been going on internally inside I2P for at least 5 years
|
|
with less progress than desired. Like some before me, I have concluded that it
|
|
would be faster to redo the whole stack "the right way" than to wait for I2P to
|
|
finish rebasing. That being said, nothing is preventing I2P from be used for
|
|
encrypted anonymous IP transit traffic in a future where I2P finishes their
|
|
protocol migrations, I just don't want to wait.
|
|
|
|
|
|
In short, I want to take the "best parts" from Tor and I2P and make a new
|
|
protocol suite.
|
|
|
|
|
|
For both Tor and I2P I have 2 categories for the attributes they have.
|
|
|
|
|
|
the good
|
|
the bad and the ugly
|
|
|
|
|
|
The good (I2P):
|
|
|
|
|
|
I2P aims to provide an anonymous unspoofable load balanced network layer.
|
|
|
|
|
|
I want this feature.
|
|
|
|
|
|
I2P is trust agile, it does not have any hard coded trusts in its network
|
|
architecture. Even network boostrap can be done from a single router if the user
|
|
desires to (albeit this is currently ill advised).
|
|
|
|
|
|
I want this feature.
|
|
|
|
|
|
The good (Tor):
|
|
|
|
|
|
Tor embraces the reality of the current internet infrastructure by having a
|
|
client/server architecture. This allows very low barriers of entry in using the
|
|
Tor network and a higher barrier of entry for contributing routing
|
|
infrastructure. This promotes a healthy network shape of high capacity servers
|
|
serving low capacity clients that "dangle off of the side" of the network.
|
|
|
|
|
|
I want this feature.
|
|
|
|
|
|
The bad and the ugly (I2P):
|
|
|
|
|
|
Bad: I2P uses old cryptography, specially 2048 bit ElGamal using non standard primes.
|
|
The use of ElGamal is so pervasive throughout the I2P protocol stack that it
|
|
exists at every level of it. Removing it is a massive task that is taking a long
|
|
LONG time.
|
|
|
|
|
|
I don't want this feature.
|
|
|
|
|
|
Ugly: I2P cannot currently mitigate most sybil attacks with their current network
|
|
architecture. Recently I2P has added some blocklist solutions signed by release
|
|
signers but this probably won't scale in the event of a "big" attack. In
|
|
addition I2P isn't staffed for such attacks either.
|
|
|
|
|
|
This is a hard problem to solve that the Loki network may be able to help
|
|
with by creating a financial barrier to running multiple a relays.
|
|
|
|
|
|
|
|
The bad and the ugly (Tor):
|
|
|
|
|
|
Bad: Tor is strictly TCP oriented.
|
|
I don't want this feature.
|
|
|
|
|