Archives/lokinet
2
0
Fork 0
mirror of https://github.com/oxen-io/lokinet.git synced 2024-11-05 21:20:38 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #7 from KeeJef/patch-3

Browse Source 
Spelling/formatting/wording cleanup
This commit is contained in:
Jeff 2018-06-18 06:47:12 -04:00 committed by GitHub
commit 9d15dab5bc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 138 additions and 135 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
doc/high-level.txt
View File

@ -1,51 +1,64 @@
LLARP - Low Latency Anon Routing Protocol LLARP - Low Latency Anon Routing Protocol
This document describes the high level outline of LLARP, specific ally the
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. project's goals, non-goals and network architecture from a bird's eye view.
Preface: Preface:
Working on I2P has been a really big learning experience for everyone involved. 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 After much deliberation I have decided to start making a "next generation" onion
routing protocol. Specifically LLARP is (currently) my PERSONAL research project routing protocol. Specifically LLARP is (currently) a research project
to explore the question: to explore the question:
"What if I2P was made in the current year (2018)? What would be different?" "What if I2P was made in the current year (2018)? What would be different?"
Project Non Goals: Project Non Goals:
This project does not attempt to solve traffic shape correlation or active nation 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 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 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 "solve". The latter is a threat that lies outside the scope of what the current
toolset that is available to me at the moment. toolset that is available to me at the moment.
This project does not attempt to be a magical application level cure-all for 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 application or end user security. At the end of the day that is a problem that
exists between chair and keyboard. exists between chair and keyboard.
The Single Project Goal: The Single Project Goal:
LLARP is a protocol suite meant to anonymize IP by providing an anonymous LLARP is a protocol suite meant to anonymize IP by providing an anonymous
network level (IPv4/IPv6) tunnel broker for both "hidden serivces" and network level (IPv4/IPv6) tunnel broker for both "hidden services" and
communication back to "the clearnet" (the normal internet). Both hidden service communication back to "the clearnet" (the normal internet). Both hidden service
and clearnet communication MUST permit both outbound and inbound traffic on the 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 network level without any NAT (expect for IPv4 in which NAT is permitted due to
lack of address availability). lack of address availability).
In short We want to permit both anonymous exit and entry network level traffic In short We want to permit both anonymous exit and entry network level traffic
between LLARP enabled networks and the internet. between LLARP enabled networks and the internet.
Rationale for starting over: Rationale for starting over:
Despite Tor Project's best efforts to popularize Tor use, Tor2Web seems to be 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 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 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 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 the existing protocols in Tor or if it is possible or advisable to attempt such
as I am not familiar with their ecosystem. as I am not familiar with their ecosystem.
I2P could have beeen used as a medium for encrypted anonymous IP transit but the
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 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 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 with less progress than desired. Like some before me, I have concluded that it
@ -54,85 +67,75 @@ 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 encrypted anonymous IP transit traffic in a future where I2P finishes their
protocol migrations, I just don't want to wait. 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 In short, I want to take the "best parts" from Tor and I2P and make a new
protocol suite. protocol suite.
For both Tor and I2P I have 2 categories for the attributes they have. For both Tor and I2P I have 2 categories for the attributes they have.
the good the good
the bad and the ugly the bad and the ugly
The good (I2P): The good (I2P):
I2P aims to provide an anonymous unspoofable load balanced network layer. I2P aims to provide an anonymous unspoofable load balanced network layer.
I want this feature. I want this feature.
I2P is trust agile, it does not have any hard coded trusts in its network 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 architecture. Even network boostrap can be done from a single router if the user
desires to (albiet this is currenly ill advised). desires to (albeit this is currently ill advised).
I want this feature. I want this feature.
The good (Tor): The good (Tor):
Tor embraces the reality of the current intneret infrastructure by having a
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 client/server architecture. This allows very low barriers of entry in using the
Tor network and a higher barrier of entry for contributing routing Tor network and a higher barrier of entry for contributing routing
infrastructure. This promotes a healthy network shape of high capacity servers infrastructure. This promotes a healthy network shape of high capacity servers
serving low capacity clients that "dangle off of the side" of the network. serving low capacity clients that "dangle off of the side" of the network.
I want this feature. I want this feature.
The bad and the ugly (I2P): The bad and the ugly (I2P):
Bad: I2P uses old cryptography, specically 2048 bit ElGamal using non standard primes.
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 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 exists at every level of it. Removing it is a massive task that is taking a long
LONG time. LONG time.
I don't want this feature. I don't want this feature.
Ugly: I2P cannot currently mitigate most sybil attacks with their current network Ugly: I2P cannot currently mitigate most sybil attacks with their current network
architecture. Recently I2P has added some blocklist solutions signed by release 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 signers but this probably won't scale in the event of a "big" attack. In
addition I2P isn't staffed for such attacks either. 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. 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): The bad and the ugly (Tor):
Bad: Tor is strictly TCP oriented. Bad: Tor is strictly TCP oriented.
I don't want this feature. 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.