forked from oxen-io/lokinet
-
Notifications
You must be signed in to change notification settings - Fork 0
/
high-level.txt
147 lines (79 loc) · 4.86 KB
/
high-level.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
THIS DOCUMENT IS 3 YEARS OUT OF DATE AND NEEDS TO BE REWRITTEN
LLARP - Low Latency Anon Routing Protocol
TL;DR edition: an onion router with a tun interface for transporting ip packets
anonymously between you and the internet and internally inside itself to other users.
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 provides.
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 (except 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.