lokinet/doc/high-level.txt

LLARP - Low Latency Anon Routing Protocol

This document describes the high level outline of LLARP, specific ally 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) my PERSONAL 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 serivces" 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 (expcet 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 additon 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 beeen 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
archetecture. Even network boostrap can be done from a single router if the user
desires to (albiet this is currenly ill advised).

I want this feature.

The good (Tor):

Tor embraces the reality of the current intneret 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, specically 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.
More research is needed.

The bad and the ugly (Tor):

Bad: Tor is strictly TCP oriented.
I don't want this feature.

Ugly: Tor isn't very trust agile. Tor has a hard coded directory authority list.
It cannot be altered trivially by the end user.

This is also a hard problem to solve that the loki network also may be able to
help with. More research is needed.


Conclusion:

LLARP attempts to be a Low Latency, Client/Server based, Anonymous Unspoofable
Load Balanced Packet based Network Layer with Inbound (Entry), Outbound (Exit)
and Hidden Service (Internal) IP connectivity.

There is a Possibilty of using the Loki Network's Service Nodes for Sybil
Mitigation. More research is needed.

The immediate future:

The Loki network recently approached me with their white paper and has peaked my
interest in some of the sybil attacks they claimed to have solved with their
protocol. I will attempt to some how make LLARP utilize their technology in the
future.

For now, it is easier to do an i2p network fork with some i2pd specific features
applied network wide. Specifically bidirectional tunnels, full replacement of
ElGamal 2048 with curve25519/EdIES from all levels of the protocol and possibly
implementing a new UDP based i2np transport. Changing the i2p network id and
deploying on an internal test network is implied.

More research is needed.