Added info about finished final milestone to L2O page, added project page for new nlnet project, changed dev page

3 files changed, 225 insertions, 43 deletions

diff --git a/template/dev_pages/t3sserakt.html.j2 b/template/dev_pages/t3sserakt.html.j2
index 93e9c39f..3a4116a3 100644
--- a/template/dev_pages/t3sserakt.html.j2
+++ b/template/dev_pages/t3sserakt.html.j2
@@ -24,8 +24,11 @@
         <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 %}
+             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. For details have a look on the <a href="../probnat/">project page</a>
+          {% endtrans %}
         </p>
         </section>
       </div>
@@ -38,48 +41,14 @@
       <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>
+        <h2>{{ _("Past Project") }}</h2>
+
+        <h3>{{ _("Transport Next Generation") }}</h3>
         <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 %}
+          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="../l2o/">project page</a>.
+      {% 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>
@@ -91,7 +60,7 @@ frequencies and the amount of connection attempts.
       <div class="col-lg-2"></div>
       <div class="col-lg-6">
       <section>
-        <h2>{{ _("Past Work") }}</h2>
+        <h2>{{ _("Voluntary 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.
diff --git a/template/l2o/index.html.j2 b/template/l2o/index.html.j2
index bfc37f50..17644fde 100644
--- a/template/l2o/index.html.j2
+++ b/template/l2o/index.html.j2
@@ -74,7 +74,7 @@
 
       <h2><a name="milestones" class="subnav-anchor"></a>{{ _("Milestones") }}</h2></br>
 
-      <p>The next milestone to be reached is milestone 5.</p></br>
+      <p>All milestones are finished.</p></br>
 
       <h3><a name="milestone1" class="subnav-anchor"></a>{{ _("Milestone 1 Test Infrastructure and minimal Test Case") }}</h3></br>
       <section>
diff --git a/template/probnat/index.html.j2 b/template/probnat/index.html.j2
new file mode 100644
index 00000000..077543e3
--- /dev/null
+++ b/template/probnat/index.html.j2
@@ -0,0 +1,213 @@
+{% 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 Port Range Optimization") }}</h3><br/>
+      <section>
+        <p>
+          {% trans %}
+            Detect likely port ranges (peers exchanging lists of 'working' IP+Port combinations).
+            {% endtrans %}
+        </p><br/>
+        <h4>Deliverable</h4><br/>
+        <p>
+          {% trans %}
+                Test case with setup using specific port ranges testing use of port subset. First
+optimization release.
+          {% endtrans %}
+        </p><br/>
+      </section>
+
+      <h3><a name="milestone6" class="subnav-anchor"></a>{{ _("Milestone 7 Optimization") }}</h3><br/>
+      <section>
+        <p>
+          {% trans %}
+            Prioritize likely working IP addresses (no point in trying to go from 10.x to 192.168.x). There might
+be optimization we do not know anything about yet.
+            {% endtrans %}
+        </p><br/>
+        <h4>Deliverable</h4><br/>
+        <p>
+          {% trans %}
+                Test case with setup using specific IP addresses testing if not all available IP addresses
+are used. Test cases testing general optimization. Second optimization release.
+          {% endtrans %}
+        </p><br/>
+      </section>
+
+      
+
+    </div>
+  </div>
+
+</article>
+{% endblock body_content %}