aboutsummaryrefslogtreecommitdiff
path: root/template/dev_pages/t3sserakt.html.j2
blob: 0d1e48e936a2fe1af080ad957a1a54d43a5e0599 (plain) (blame)
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
{% extends "common/base.j2" %}
{% block body_content %}
<!-- Jumbotron -->
<div>
  <div class="container">
    <div class="row">
      <div class="container text-center">
        <h1>{{ _("Developer page: t3sserakt") }}</h1>
      </div>
    </div>

    <div class="container text-center">
      <img src="{{ url_static('images/t3sserakt.jpg') }}"  alt="t3sserakt" />
    </div>
  </div>
</div>
<div class="container-fluid greybox">
  <div class="container">
    <div class="row">
      <div class="col-lg-2"></div>
      <div class="col-lg-6">
        <section>
        <h2>{{ _("Current Work") }}</h2>
        <p>
        {% trans %}
          At the moment I am working on Transport Next Generation (TNG). The current GNUnet TRANSPORT architecture with its pluggable transport mechanism (TCP, UDP, HTTP(S) and other protocols) together with the ATS subsystem for bandwidth allocation and choosing plugins has several issues with its design. With the Layer-2-Overlay project we like to implement the design goals of the future GNUnet TRANSPORT Next Generation (TNG) subsystem. For details have a look on the <a href="https://www.gnunet.org/en/l2o/">project page</a>.
      {% endtrans %}
        </p>
        </section>
      </div>
    </div>
  </div>
</div>
<div class="container-fluid">
  <div class="container">
      <div class="row">
      <div class="col-lg-2"></div>
      <div class="col-lg-6">
      <section>
        <h2>{{ _("Future Work") }}</h2>
        <p>
          {% trans %}
            The next project I will work on is named "Probabilistic NAT Traversal".
          {% endtrans %}
        </p>
	<p>
	  {% trans %}
	     Today consumer devices are behind a NAT quite often, restricting internet connectivity. There are several methods to reach peers being
behind a NAT, but there are as many reasons those existing methods might fail. We will implement a new way of NAT traversal that we
think of being independent from the existing network configuration, and does not require a third party which is not natted helping two
peers to connect to each other. 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.
     	  {% endtrans %}
	</p>
	 <p>
          {% trans %}
            There are two problems a NAT traversal method has to solve. First there needs to be a method to know the global IP address of a peer A
another peer B wants to connect to. Second – because inbound connections from the outside are blocked by the NAT firewall of peer A,
peer A needs to be informed of a connection attempt by peer B. The most common solution for both problems is to have a third party C
which is not behind a NAT. This third party C obviously knows the global IP address of natted peers, after peer A is trying to connect to
C. Peer B tells C it likes to connect to peer A, and C informs A about it. 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.
          {% endtrans %}
        </p>
	<p>
          {% trans %}
            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 L2O 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". Also in the L2O project we introduced a new test framework for GNUnet to test network setups with peers having
restricted connectivity. This test framework will be used to create test setups suitable to test possible NAT configurations. A challenge for
this NAT traversal method will be how to handle the burst in terms of network load, thus we need to experiment with different
frequencies and the amount of connection attempts.
          {% endtrans %}
        </p>
        </section>
      </div>
    </div>
  </div>
</div>
<div class="container-fluid greybox">
  <div class="container">
      <div class="row">
      <div class="col-lg-2"></div>
      <div class="col-lg-6">
      <section>
        <h2>{{ _("Past Work") }}</h2>
        <p>
          {% trans %}
            In the past I have tried to help making the vision of the <a href="http://secushare.org">secushare</a> project a reality. To achieve this the GNUnet framework was the perfect match for a solution to fullfill the privacy preserving part of that vision, and we could concentrate to build a tool for social communication that deserves its name. While trying to use GNUnet, we found and fixed bugs. For example there was one <a href="https://bugs.gnunet.org/view.php?id=5822">bug</a> in CADET which prevented the re-establishment of a connection after a communication partner suddenly stopped communicating. From our perspective there is no alternativ to GNUnet, which led us to first bring the parts of GNUnet needed by secushare to a state that they can be used prouctively.
          {% endtrans %}
        </p>
        </section>
      </div>
    </div>
  </div>
</div>
<div class="container-fluid">
  <div class="container">
      <div class="row">
      <div class="col-lg-2"></div>
      <div class="col-lg-6">
      <section>
        <h2>{{ _("Contact Information") }}</h2>
        <p>
	  <div class="container">
	    <div class="row">
	      <div class="col-lg-2">Mail:</div>
      	      <div class="col-lg-6">t3sserakt@gnunet.org</div>
	    </div>
	    <div class="row">
	      <div class="col-lg-2">Mastodon:</div>
      	      <div class="col-lg-6"><a rel="me" href="https://c3d2.social/@t3sserakt">@t3sserakt@c3d2.social</a></div>
	    </div>
	    <div class="row">
	      <div class="col-lg-2">Matrix:</div>
      	      <div class="col-lg-6">@t3sserakt:tchncs.de</div>
	    </div>
	    <div class="row">
	      <div class="col-lg-2">PGP:</div>
      	      <div class="col-lg-6"><a href="https://keyoxide.org/hkp/34156165BAC792A688C990CFC9A2D9D808FF308D">keyoxide</a></div>
	    </div>
	  </div>
        </p>
        </section>
      </div>
    </div>
  </div>
</div>
{% endblock body_content %}