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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
{% extends "common/base.j2" %}
{% block body_content %}
<main id="maincontent">
<article class="container">
<header>
<h1>{{ _("NGI Assure project: Probabilistic NAT Traversal") }}</h1>
</header>
<div class="row">
<div class="col-2 d-none d-lg-block"><!-- for large viewports show menu for better orientation -->
<nav class="nav subnav position-fixed flex-column border-right" style="position:fixed">
<a class="nav-link" href="#idea">{{ _("Project motivation") }}</a>
<a class="nav-link" href="#milestones">{{ _("Milestones") }}</a>
<a class="nav-link" href="#milestone1">{{ _("Milestone 1") }}</a>
<a class="nav-link" href="#milestone2">{{ _("Milestone 2") }}</a>
<a class="nav-link" href="#milestone3">{{ _("Milestone 3") }}</a>
<a class="nav-link" href="#milestone4">{{ _("Milestone 4") }}</a>
<a class="nav-link" href="#milestone5">{{ _("Milestone 5") }}</a>
<a class="nav-link" href="#milestone6">{{ _("Milestone 6") }}</a>
<a class="nav-link" href="#milestone6">{{ _("Milestone 7") }}</a>
</nav>
</div>
<div class="col">
<section>
<p>
{% trans %}
This project was funded through the NGI Assure Fund, a fund established by <a href="https://nlnet.nl/project/ProbabilisticNAT">NLnet</a>.</br>
{% endtrans %}
</p>
</section>
<h2><a name="idea" class="subnav-anchor"></a>{{ _("Project motivation") }}</h2></br>
<section>
<h4>The Problem</h4></br>
<p>
{% trans %}
For establishing a peer to peer (p2p) network among regular internet users, unhindered connectivity is anything but self-evident. Today consumer devices are often not directly reachable via the internet but quite often are behind a so called NAT delivering only indirect internet connectivity.
{% endtrans %}
</p></br>
</section>
<section>
<h4>NAT Traversal Methods</h4></br>
<p>
{% trans %}
There are several methods to reach peers who are behind a NAT, but there are as many reasons those existing methods might fail. Manual configuration for example, as it is possible for example with home routers, often does not work for mobile devices like mobile phones. A further category of methods is subsumed under the term NAT hole punching. This exploits a behavior of the gateway that keeps the port of an outgoing packet open for a potential response. To make this port known to another peer a third peer is needed who is not behind a NAT. Using this method for a privacy preserving network like GNUnet, this could facilitate eclipse attacks (isolating a peer) which then can be used for deanonymization attacks and cencorship. Also any additional infrastructure needed to provide some kind of functionality has to be maintained by someone, becoming a target and/or point of failure. Therefore this method is not suitable. More sophisticated methods like "Autonomous NAT Traversal (pwnat)" using ICMP fake message, which do not need a third party for the initiation of the connection, are not successful in all circumstances, because this method depend on the behavior of the NAT firewall. All methods have in common that the external IP address of the peer behind the NAT must be known.
{% endtrans %}
</p></br>
</section>
<section>
<h4>Alternative Solution</h4></br>
<p>
{% trans %}
Two peers trying to connect to each other will send out a burst of connection attempts to the other peer on different ports. The sheer vast amount of connections attempts from both side will lead to a high probability that two connection attempts from both peers onto the same port will be at the same time leading to a successful connection between those peers. If two natted peers are using the method to start a burst of connection attempts, this method still needs the global IP of the other peer and a “start signal” to coordinate. In the NGI Assure project <a href="../l2o">L2O</a> we are establishing a backchannel with neighbourhood routing over an ad-hoc distance vector protocol to solve the problem of not directly connected peers. The peers serving as hops to a distant peer which are a direct neighbour of the start or end peer on that path do know the global IP address of the start or end peer. If those two peers like to use the burst method for hole punching the global IP address is known. Via the distance vector protocol we are also able to communicate the "start signal".
{% endtrans %}
</p></br>
</section>
<h2><a name="milestones" class="subnav-anchor"></a>{{ _("Milestones") }}</h2></br>
<p>The next milestone to be reached is milestone 1.</p></br>
<h3><a name="milestone1" class="subnav-anchor"></a>{{ _("Milestone 1 Test Infrastructure") }}</h3></br>
<section>
<p>
{% trans %}
Extending the testing framework, which was already designed and implemented for the L2O
project.
<ul>
<li>Enhance the testing framework with a new kind of component (NAT component).</li>
<li>Implement logic to keep ports open used during network translation.</li>
<li>Extend the test framework configuration to configure the new components.</li>
</ul></br>
{% endtrans %}
</p>
<h4>Deliverable</h4></br>
<p>
{% trans %}
Test case which tests the new testing functionality. Adding documentation.
{% endtrans %}
</p></br>
</section>
<h3><a name="milestone2" class="subnav-anchor"></a>{{ _("Milestone 2 Synchronization") }}</h3></br>
<section>
<p>
{% trans %}
This task is to implement the protocol that is doing the signaling for synchronizing two peers
which do like to connect to each other.
<ul>
<li>Two peers which got connected via DV signaling each other being behind a NAT.</li>
<li>Learning the external IP address+port from already connected peers, exchange with the
peers that want to connect.</li>
<li>Set a common start time. One peer is selected to be leading (comparing peer ids like it is
done in CADET)</li>
</ul>
{% endtrans %}
</p></br>
<h4>Deliverable</h4></br>
<p>
{% trans %}
Deliverable of this milestone is integrating the protocol implementation into the GNUnet
stack, a test case which tests that two peers successfully exchange the messages of the
implemented protocol until the condition is reached that both nodes are ready for the burst
mode. Additionally there will be a protocol documentation.
{% endtrans %}
</p></br>
</section>
<h3><a name="milestone3" class="subnav-anchor"></a>{{ _("Milestone 3 Burst Protocol") }}</h3></br>
<section>
<p>
{% trans %}
Burst to establish connectivity (IP_RAW, SYN send for TCP; normal for UDP). A burst of
synchronized (same ports on each peer) connection attempts on all available ports will lead to a
high probability for a successful connection.The connection in the TCP case is not final, because
the TCP connection is only done in the user space.
{% endtrans %}
</p></br>
<h4>Deliverable</h4>
<p>
{% trans %}
The protocol implementation will be integrated into the GNUnet stack, one Test case will
test two peers are finaly connected (UDP case), another test case for TCP tests if both
peers end up at the same port and the protocol will be documented.
{% endtrans %}
</p></br>
</section>
<h3><a name="milestone4" class="subnav-anchor"></a>{{ _("Milestone 4 TCP Repair") }}</h3></br>
<section>
<p>
{% trans %}
For the TCP case the connection was established sending packages from user space using raw
sockets. To let the kernel know about the TCP connection we will use the “repair mode” of the
setsockopt() system call.
{% endtrans %}
</p></br>
<h4>Deliverable</h4></br>
<p>
{% trans %}
Integration into the GNUnet stack and a test case testing two peers are finaly (kernel TCP
socket) connected.
{% endtrans %}
</p></br>
</section>
<h3><a name="milestone5" class="subnav-anchor"></a>{{ _("Milestone 5 Privilege Minimization") }}</h3><br/>
<section>
<p>
{% trans %}
Privilege minimization, using SUID/SGID helpers with required capabilities. We need privileged
access to system resources for some parts of the protocol, e.g. the TCP repair mode. This task
will implement helper executables which are doing this privileged access, to be used by other
components not having special privileges. (see § 2.2.1 Access Control, The GNUnet System,
https://grothoff.org/christian/habil.pdf)
{% endtrans %}
</p><br/>
<h4>Deliverable</h4><br/>
<p>
{% trans %}
Helper executables and cli applications using the helpers. Integration into the GNUnet
stack. Man pages for the cli applications. First release of all the implementation.
{% endtrans %}
</p><br/>
</section>
<h3><a name="milestone6" class="subnav-anchor"></a>{{ _("Milestone 6 Android Test Infrastructure") }}</h3><br/>
<section>
<p>
{% trans %}
In this milestone the test framework will be enhanced to run a headless android studio emulator on a namespace node. With this emulator an android device running on that node shall be emulated. Two devices running on different nodes should reach each other via the test framework network. For doing the network connection an app should run on each device. This app should do the networking with a small c library. With this c library we like to test if networking and file access is possible with a c library running using the NDK of Android.
{% endtrans %}
</p><br/>
<h4>Deliverable</h4><br/>
<p>
{% trans %}
The deliverable of this milestone is twofold: the scripts for automation and the automated tests themselves, and a report on the outcome of these tests. If the test case starting an Android app on two nodes doing network communication between those two apps and each app accessing its own filesystem will not work as expected, the task includes an overview of potential approaches for achieving the desired outcomes in other ways.
{% endtrans %}
</p><br/>
</section>
<h3><a name="milestone6" class="subnav-anchor"></a>{{ _("Milestone 7 GNUnet event loop on Android") }}</h3><br/>
<section>
<p>
{% trans %}
The c library should also start the GNUnet event loop. Therefore the library will be enhanced by a minimal part of the GNUnet stack to start the event loop. The testing code will be enhanced to use the event loop.
{% endtrans %}
</p><br/>
<h4>Deliverable</h4><br/>
<p>
{% trans %}
The deliverable of this milestone is twofold: the scripts for automation and the automated tests themselves, and a report on the outcome of these tests. If the test case testing the same functionality as in milestone 6, but using the GNUnet event loop, will not work as expected, the task includes an overview of potential approaches for achieving the desired outcomes in other ways.
{% endtrans %}
</p><br/>
</section>
<h3><a name="milestone6" class="subnav-anchor"></a>{{ _("Milestone 8 Enhance GNUnet stack on Android") }}</h3><br/>
<section>
<p>
{% trans %}
The working test cases of milestone 6 and 7 are prerequisites to tackle this milestone! The library will be enhanced to incorporate the parts of the GNUnet stack necessary to run the test case implemented in the milestones 1 -4.
{% endtrans %}
</p><br/>
<h4>Deliverable</h4><br/>
<p>
{% trans %}
Test case testing the same functionality as in milestone 1 - 4 running on Android.
{% endtrans %}
</p><br/>
</section>
</div>
</div>
</article>
{% endblock body_content %}
|
