mirror of
https://github.com/oxen-io/lokinet.git
synced 2024-11-17 15:25:35 +00:00
Merge pull request #7 from KeeJef/patch-3
Spelling/formatting/wording cleanup
This commit is contained in:
commit
9d15dab5bc
@ -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.
|
|
||||||
|
Loading…
Reference in New Issue
Block a user