i2p.www/www.i2p2/pages/todo_de.html

{% extends "_layout_de.html" %}
{% block title %}To Do Liste{% endblock %}
{% block content %}<p>Hier ist eine detailietere (und dennoch unvollst&auml;ndige)
Diskussion der wichigsten Gebiete zur zuk&uuml;nftigen Entwicklung des grundlegenden
I2P Netzwerkes, &uuml;bergreifend &uuml;ber die zuk&uuml;nftigen geplanten Versionen.
Dieses beinhaltet nicht steganographische Transporte, anpassen auf kabellose Ger&auml;te
oder Werkzeuge zum sichern der lokale Computer. Ebenfalls sind die Klientenanwendungen
nicht dabei, die unverzichtbar f&uuml;r den Erfolg von I2P sind. Es werden mehr Themen
folgen, besonders alsbald I2P mehr &Uuml;berpr&uuml;fungen bekommt, aber hier sind
zumindest die "grossen Themen" aufgelistet.
Schaue ebenfalls in <a href="roadmap_de.html">den Zeitplan</a>.
M&ouml;chtest du helfen? <a href="getinvolved_de.html">Beteilige Dich</a>!
</p>

<ul>
 <li><a href="#core">Grundlegende Funktionen</a><ul>
  <li><a href="#nat">NAT/Firewall &uuml;berwindung via 1-hop beschr&auml;nkte Routen</a></li>
  <li><a href="#transport">Hochentwicklete Transportschicht mittels UDP, NBIO, oder NIO</a></li>
  <li><a href="#netdb">NetworkDB und Profile Optimierung und Entfernungsregeln f&uuml;r grosse Netz</a></li>
  </ul></li>
 <li><a href="#security">Sicherheit / Anonymit&auml;t</a><ul>
  <li><a href="#tunnelId">Pro-hop Tunnel ID &amp; neue permutierte TunnelVerificationStructure verschl&uuml;sselung</a></li>
  <li><a href="#ordering">Strenges Sortieren der Teilnehmer in Tunneln</a></li>
  <li><a href="#tunnelLength">Zuf&auml;llig variierte Tunnell&auml;nge</a></li>
  <li><a href="#fullRestrictedRoutes">Ganz ausgenutzte n-hop beschr&auml;nkte Routen mit optionalen vertrauten Verbindungen</a></li>
  <li><a href="#hashcash">Hashcash zur routerIdentity, destination  und Tunnel Nachfrage</a></li>
  <li><a href="#batching">Fortgeschrittene Tunnel Operationen (Zusammenfassen/Mixen/Limitieren/Auff&uuml;llen)</a></li>
  <li><a href="#stop">Stop &amp; Go Mix mit Garlic &amp; Tunnel</a></li>
  </ul></li>
 <li><a href="#performance">Performance</a><ul>
  <li><a href="#sessionTag">Umstellung von Sessiontag auf synchronisiertes PRNG</a></li>
  <li><a href="#streaming">Komplettes Streaming Protokoll Erweiterung</a></li>
  </ul></li>
</ul>



<ul>
<li><h2 id="core">Grundlegende Funktionen</h2><ul>

 <li><h3 id="nat">NAT/Firewall &uuml;berwindung via 1-hop beschr&auml;nkte Routen</h3>
<b><i>Implementiert in I2P 0.6.0.6</i></b>

<p>Um Knoten hinter nicht kontrollierten NATs oder Firewalls dennoch
mit voller Funktionalit&auml;t am Netzwerk teilnehmen zu lassen brauchen wir
ein wenig der Funktionalit&auml;t der Beachr&auml;nkten Routen (da diese 
Knoten keine eigehenden Verbindungen empfangen k&ouml;nnen). Um dieses erfolgreich
zu machen, teilt man die Knoten in 2 Gruppen auf:</p><ul>
<li><b>Knoten mit erreichbarem Interface</b> - diese Knoten m&uuml;ssen nichts
       besonderes machen</li>
<li><b>Knoten mit nicht erreichbarem Interface</b> - Diese Knoten m&uuml;ssen
       einen Tunnel zu sich aufbauen von einem anderen Gateway aus. Dieser andere
       Gateway muss mit ihnen eine Verbindung aufgebaut haben, eine &ouml;ffentlich
       erreichbares Interface haben und zugestimmt haben, ein "Introducer" zu sein.</li>
</ul>

<p>Um dieses zu erreichen, verbinden diese Knoten einfach mit ein paar anderen 
Knoten, bauen einen Tunnel durch diese auf und ver&ouml;ffentlichen eine
Referenz auf diese Tunnel in Ihrer RouterInfo Struktur in der Netzwerk Datenbank.
</p>

<p>Falls jemand einen bestimmten Router erreichen will, muss dieser erst
dessen Routerinfo aus der Netzwerk Datenbank bekommen. Diese teilt ihm mit, ob der 
Router direkt (z.B. hat der Knoten ein &ouml;ffentlich erreichbares Interface)
erreichbar ist oder indirekt erreicht werden muss. Direkte Verbindungen passieren
wie sonst normal auch, w&auml;hrend indirekte durch einen der publizierten
Tunnel aufgebaut werden m&uuml;ssen.</p>

<p>Falls ein Router nur ein oder zwei Nachrichten an einen bestimmten
versteckten Knoten senden will, kann dieser einfach diese indirekten Tunnel
zum Senden der Nutzdaten benutzen. Falls jedoch der Router &ouml;fters zu dem
versteckten Knoten sprechen m&ouml;chte (z.B. als Teil eines Tunnels), sendet er
eine garlic geroutete Nachricht durch den indirekten Tunnel zu dem verstecktem
Knoten, welcher den Inhalt, der eine Nachricht zum zur&uuml;ckschicken an den
Ausgangsrouter enth&auml;lt, auspackt. Dieser verteckte Knoten baut dann eine
ausgehende Verbindung zu dem Ausgangsrouter auf und &uuml;ber diese direkte
Verbindung k&ouml;nnen die beiden Router dann miteinander kommunizieren.</p>

<p>Nat&uuml;rlich funktioniert dieses nur, wenn der Ausgnagsrouter 
Verbindungen empfangen kann (nicht auch versteckt ist). Falls das der Fall ist,
kann er einfach die garlic geroutete Nachricht &uuml;ber den Eingangstunnel des
Ausgangsrouter zur&uuml;ckrouten..</p>

<p>Dieses ist nicht dazu gedach, die IP eines Knotens zu verstecken, es ist
eher eine M&ouml;glichkeit um Leuten hinter NATs und Firewalls ganz am 
Netzwerk teilnehmen zu lassen. IPs zu verstecken braucht etwas mehr Arbeit,
wie weiter <a href="#fullRestrictedRoutes">unten beschrieben.</a></p>

<p>Mit dieser Technik kann jeder Router in einem Tunnel jede Aufgabe annehmen.
Aus Effizienzgr&uuml;nden ist ein versteckter Knoten eine schlechte Wahl als
Eingangsgateway und innerhalb eines Tunnels, zwei benachbarte Knoten 
sollten nicht versteckt sein, aber das ist technisch nicht n&ouml;tig.</p>

 </li>
 <li><h3 id="transport">Hochentwicklete Transportschicht mittels UDP, NBIO, oder NIO</h3>
<b><i>Sowohl UDP als auch NIO sind in I2P implementiert</i></b>

<p>Standard TCP Kommunikation in Java braucht normalerweise blockierende Socket Aufrufe.
Damit diese Aufrufe nicht das gesamte System blockieren, sind sie in eigenen Threads
implementiert. Unser alter TCP Transport war recht einfach implementiert - f&uuml;r
jeden Knoten mit dem wir kommunizierten hatten wir einen lesenden und einen schreibenden
Thread. Der lesende Thread ruft einfach in einer Schleife eine Reihe vo read() Aufrufen
auf, baut I2NP Nachrichten auf und f&uuml;gt diese der internen Eingehenden Nachrichten
Queue hinzu. Der schreibende Thread holt die Nachrichten aus der Ausgangs Nachrichten 
Queue (je Verbindung) und schiebt diese durch die write() Aufrufe.</p>

<p>Wir machen das aus CPU Sicht recht effizient - zu jeder Zeit sind fast alle Threads
idle, blockiert mit warten auf etwas zu tun. Jedoch braucht jeder Thread auch reale
Ressourcen (auf &auml;lteren Linux Kernels war oft z.B. jeder Thread als ein abgeleiter
Prozess implementiert). Sobald das Netzwerk w&auml;chst, w&auml;chst auch die Anzahl
Knoten, mit der ein jeder Router kommuizieren m&ouml;chte (denke dran, I2P ist voll
verbunden, was meint, das jeder Knoten wissen sollte, wie er eine Nachricht zu einem
anderen Knoten bekommt und beschr&auml;nkte Knoten sollten nicht wirklich die Anzahl
der ben&ouml;tigten Verbindungen reduzieren). Somit wird in einem Netzwerk mit 
100.000 Routern jeder einzelne bis zu 199.998 Threads NUR zum Abarbeiten der TCP
Verbindungen haben!</p>

<p>Offensichtlich wird das nicht funktionieren. Wir brauchen eine skalierbare
Transportschicht. In Java haben wir da 2 grosse M&ouml;glichkeiten:</p>

<h4>UDP</h4>
<b><i>Implementiert in I2P 0.6 ("SSU") und <a href="udp.html">woanders</a>beschrieben 
und dokumentiert</i></b>

<p>Das Senden und Empfangen von UDP Datagrammen geschieht verbindungslos - wenn wir
mit 100.000 Knoten kommunizieren, stecken wir einfach die UDP Pakete in einen 
Stack und ein einzelner Thread liest diese aus dem Stack aus und schiebt diese 
raus ins Netz (und um zu Empfangen, gibt es einen Thread, der alle eingehenden 
UDP Pakete einsammelt und diese an die Eingehende Queue weiterleitet).</p>

<p>UDP zu nutzen bedeuted aber auch, die Vorteile von TCP zu verlieren, wie z.B.
die Reihenfolge der Pakete, Auslastungskontrolle, MTU Erkennung, usw. Dieses alles
zu implementieren wird viel Arbeit sein, aber I2P braucht nicht alle Featuers wie bei TCP.
Insbesondere habe ich beim Messen im Simulator und im Livenetz festgestellt, dass
der Grossteil der transportierten Nachrichten problemlos in ein einzelnes
unfragmentierten UDP Paket passt, wogegen die gr&ouml;ssten in 20-30 Pakete passen.
Wie mule angemerkt hat, f&uuml;gt TCP einen erheblichen Overhead bei den vielen kleinen
Paketen hinzu, da f&uuml;r jedes Paket ein ACK verschickt werden muss. Mit UDP 
k&ouml;nnen wir den Transport sowohl auf Effizienz als auch auf Belastbarkeit 
optimieren in Hinblick auf die speziellen Bed&uuml;rfnisse von I2P.</p>

<p>Es wird eine Menge an Arbeit sein.</p>

<h4>NIO oder NBIO</h4>
<b><i>NIO implementiert in I2P 0.6.1.22 ("NTCP")</i></b>

<p>In Java 1.4 wurde ein ganzes Paket von sogenannten "New I/O" eingebaut, die den
Entwicklern die vorteile der nicht blockierende IO F&auml;higkeiten des Systems zu
nutzen erlauben - dieses erlaubt dir eine grosse Menge von gleichzeitigen IO
Operationen zu verwalten, ohne die Notwendigkeit eines seperaten Threads f&uuml;r
jede einzelne IO Operation. Dieser Ansatz verspricht vieles, da wir so eine grosse
Menge von gleichzeitigen Verbindungen verarbeiten k&oouml;nnen und ben&oouml;tigen 
nicht einen selbstgeschriebenen Mini-TCP Stack in UDP. 
Dennoch sind die NIO Pakete nicht ganz fehlerfrei, wie die Freenetentwickler
feststellen mussten  Hinzu kommt, das wir mit NIO Support nicht die Open Source
JVMs wie z.B. <a href="http://www.kaffe.org/">Kaffe</a> unterst&uuml;tzen, da 
<a href="http://www.classpath.org/">GNU/Classpath</a> einen geringen Umfang an NIO
unterst&uuml;tzt.
<i>(Hinweis: dieses ist wom&ouml;glich nicht mehr der Fall, da es Verbesserungen bei
den Classpaths NIO gegeben hat, aber es ist unbekannt, wie weit diese verbessert sind.)</i></p>

<p>Eine weitere Alternative in dem selbem Weg ist das 
<a href="http://www.eecs.harvard.edu/~mdw/proj/java-nbio/">Non Blocking I/O</a> Paket -
eine grunds&auml;tzliche saubere NIO Implementierung (geschrieben bevor NIO da war).
Es funktioniert durchs Verwenden von ein paar OS Routinen des nichtblockierenden IO
und weiterreichen von Events an Java. Es scheint mit Kaffee zu funktionieren, obwohl
es letztens nicht viel Entwicklung in dem Projekt gab (wohl durch die Java 1.4 NIO
Entwicklung bedingt).</p>


 </li>
 <li><h3 id="netdb">NetworkDB und Profile Optimierung und Entfernungsregeln f&uuml;r grosse Netz</h3>

<p>In der derzeitigen Netzwerkdatenbank und Profilemanagement Implementation haben wir uns
die Freiheit genommen, ein paar praktische Vereinfachungen zu nutzen. Zum Beispiel
haben wir keinen Code um die Knoten Referenzen aus der K-Gruppe zu entfernen, falls wir
nicht genug Knoten haben um nur eine Gruppe hinreichend zu f<>llen, stattdessen 
behalten wir den Peer in der jeweiligen passenden Gruppe.
Ein weiteres Beispiel dreht sich um die Knoten Profile - der ben&ouml;tigte Speicherbedarf
f&uuml;r jedes Knoten Profile ist klein genug damit wir tausende voll ausgef&uuml;llte
Profile ohne Probleme im Speicher halten k&ouml;nnen. W&auml;hrend wir die M&ouml;glichkeit
zum Nutzen von gek&uuml;rzten Profilen (von denen wir 100 Tausende im Speicher halten
k&ouml;nnen) haben, haben wir keinen Code um ein gek&uuml;rztes Profil in ein
volles Profil zu wandeln, anders herum oder gar ganz zu entfernen. Es ist einfach
nicht praktikabel genug, den Code jetzt zu schreiben, da wir diesen noch eine lange
Zeit nicht brauchen werden.</p>

<p>Somit sollten wir dieses im Hinterkopf behalten, sobald das Netzwerk weiter
w&auml;chst haben wir ein wenig Arbeit damit, aber f&uuml;r jetzt lassen wir das
f&uuml;r sp&auml;ter.</p>

 </li>
</ul></li>

<li><h2 id="security">Sicherheit / Anonymit&auml;t</h2><ul>

 <li><h3 id="tunnelId">
Pro-hop Tunnel ID &amp; neue permutierte TunnelVerificationStructure verschl&uuml;sselung</h3>
<b><i>In I2P 0.5 eingebaut wie <a href="tunnel-alt.html">woanders</a> beschrieben</i></b>

<p>Zur Zeit wissen bei einem 4 Hop Eingangstunnel Tunnel von Alice, von Alice aufgebaut
und bei Elvis startend, &uuml;ber Dave,Charlie und Bob zu Alice gehend 
(A&lt;--B&lt;--C&lt;--D&lt;--E), alle 5 beteiligten Knoten die Tunnel ID "123", da die
Nachrichten damit bezeichnet sind. Wir m&ouml;chten jedem Hop seine eigene Tunnel-Hop ID
geben - Charlie bekommt Nachrichten &uuml;ber Tunnel 234 and reicht diese zum Tunnel 876
an Bob weiter. Beabsichtigt wird damit, dass Bob oder Charlie wissen, das sie im Tunnel
von alice teilnehmen, denn wenn jeder Hop im Tunnel die selbe Tunnel ID hat, sind 
"Collusion Attacken" nicht schwer auszuf&uuml;hren. </p>

<p>Eine einzigartige TunnelID pro Hop hinzuzuf&uuml;gen ist nicht schwer, aber f&uuml;r 
sich alleine unzureichend. Falls Dave und Bob unter der Kontrolle des selben Angreifers 
stehen, k&ouml;nnten sie nicht anhand der Tunnel ID sagen, das sie am selben Tunnel
teilnehmen, jedoch k&ouml;nnen sie dieses anhand der Nachrichtentexte und
verifikationsstrukturen durch einen simplen Vergleich herausfinden. Um das zu verhindern
muss ein Tunnel eine schichtweise Verschl&uuml;sselung auf dem Wege nutzen, sowohl auf
den Inhalt der getunnelten Nachricht als auch auf der Verifikationsstruktur (die zum
verhindern einfacher Attacken genutzt wird). Dieses braucht ein paar einfache &Auml;nderungen
an der TunnelMessage Struktur, als auch die Einbindung von pro-Hop geheimen Schl&uuml;sseln, 
die beim Tunnelaufbau transportiert werden und zum Tunnel Gateway durchgereicht werden.
Wir m&uuml;ssen eine maximale Tunnell&auml;nge setzen (z.B. 16 Hops) und dem Gateway 
sagen, das dieser die Nachricht mit jedem der 16 empfangenen geheimen Schl&uuml;sseln
verschl&uuml;sseln muss, in umgekehrter Reihenfolge, und auch die Signatur der 
Pr&uuml;fsumme der (verschl&uuml;sselten) Daten bei jedem Schritt verschl&uuml;sseln muss.
Das Gateway senden dann diese 16-fach verschl&uuml;sselte Nachricht mitsamt den 16-fachen
16 Felder weiten verschl&uuml;sselten Mapping an den ersten Hop. Dieser entschl&uuml;sselt
die Nachricht und die Nutzdaten mit seinem geheimen Schl&uuml;ssel, schaut in der 16
Felder weiten Mapping nach dem Eintrag, der zu seinem eigenem Hop passt (mit der Pro-
Hop Tunnel ID verschr&auml;nkt) und pr&uuml;ft die Nutzdaten durchs checken gegen 
die assoziierte signierte Pr&uuml;fsumme.</p>

<p>Der Tunnel Gateway hat immer noch mehr Informationen als die anderen Knoten im Tunnel
und ein &uuml;bernehmen des Gateways und eines Tunnel Teilnehmers erlaubt diesen 
Knoten zu vergleichen und die Tatsache bekanntzugeben, das beide im selben Tunnel sind.
Zus&auml;tzlich wissen benachbarte Knoten sowieso, das sie im selben Tunnel sind, da sie
wissen, an wen sie die Nachricht gesendet haben (und mit IP basierten Transporten ohne
beschr&auml;nktes Routing wissen sie auch von wem die Nachricht kam). Dennoch erh&ouml;hen
diese genannten Techniken erheblich die Kosten zum Erreichen von aussagekr&auml;ftigen 
Daten bei l&auml;ngeren Tunneln.</p>


 </li>
 <li><h3 id="ordering">Strenges Sortieren der Teilnehmer in Tunneln</h3>
<b><i>Implementiert im Release 0.6.2</a></i></b>

<p>Wie Connelly <a href="http://dev.i2p/pipermail/i2p/2004-July/000335.html">vorschlug</a>,
der <a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">Predecessor Attacke</a>
<a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">(2008 update)</a> 
zu begegnen, in dem wir die Reihenfolge der Knoten in unseren Tunneln konsistent halten 
(das meint, wann immer Alice einen Tunnel mit Bob und Charlie aufbaut, wird Charlie immer
der n&auml;chste Hop von Bob sein), setzen wir es um, damit Bob nicht Alice Auswahlgruppe
an Knoten herausfinden kann. M&ouml;glicherweise gehen wir einen Schritt weiter und erlauben
Bob nur, nur in einer Richtung in Alices Tunnel teilzunehmen - von Dave eine Nachricht empfangen
und an Charlie weiterreichen - und falls diese Knoten nicht zur Teilnahme im Tunnel zur
Verf&uuml;gung stehen (z.B. wegen &Uuml;berlastung, Disconnect oder so) wird Bob nicht mehr
zur Teilnahme im Tunnel angefragt, bis d<>e Knoten wieder zur Verf&uuml;gung stehen.</p>

<p>Es sind noch mehr Analysen notwendig um den Prozess der Tunnelherstellung zu
&uuml;berpr&uuml;fen - zur Zeit suchen wir einfach aus und sortieren zuf&auml;llig
in der "Top Tier" Knotengruppe des Knotens (die Gruppe mit "fast + high capacity).</p>

<p>Das Anwenden des strengen Sortierens der Knoten im Tunnel erh&ouml;ht auch die
Anonymit&auml;t der Knoten mit 0-Hop Tunnels, da sonst die Tatsache, das das Gateway
eines Knoten immer gleich bliebe, eine verr&auml;terische Aussage ist. Dennoch sollten
Knoten mit 0-Hop Tunnel hin und wieder 1-Hop Tunnel nutzen um den Ausfall eines
normalen, zuverl&auml;sslichen Gateways zu simulieren (z.B. alle MTBF*(Tunnel Lebensdauer)
Minuten einen 1-Hop Tunnel nutzen).</p>

 </li>
 <li><h3 id="tunnelLength">Zuf&auml;llig variierte Tunnell&auml;nge</h3>
<b><i>Eingebaut in I2P 0.5, wie <a href="tunnel-alt.html">woanders</a> beschrieben</i></b>

<p>Ohne Tunnell&auml;ngen Variationen kann jemand, der irgendwie die Tunnell&auml;nge einer
Destination mitbekommt, diese Information nutzen, um die IP Adresse eines Zieles mittels
einer "Predecessor Atacke" herauszubekommen. Wenn z.B. jeder 2-Hop Tunnel nutzt und Bob eine
Tunnelnachricht von charlie bekommt und an Alice weiterreicht, weiss Bob, das Alice der letzte
Knoten im Tunnels ist. Falls Bob identifizieren kann, welche Destination den Tunnel erstellt 
hat (das meint durch Kollisionen mit dem Gateway und die Netzwerk Datenbank nach all den 
Leasesets durchsuchen), dann kennt er den Router, auf dem die Destination liegt (und
ohne beschr&auml;nkte Routen auch die IP).</p>

<p>Um dem Verhalten der Benutzer zu begegnen sollten Tunnell&auml;ngen variiert werden, 
realisiert mit einem Algorhytmus der auf der angefragten Tunnell&auml;nge basiert (z.B.
die 1/MTBF Tunnell&auml;nge f&uuml;r 0-Hop Tunnels, wie oben beschrieben).</p>

 </li>
 <li><h3 id="fullRestrictedRoutes">Ganz ausgenutzte n-hop beschr&auml;nkte Routen mit optionalen vertrauten Verbindungen</h3>

<p>Die Funktionalit&auml;t der oben beschriebenen beschr&auml;nkten Routen ist eine einfache
funktionale Angelegenheit - wie man Knoten, die sonst nicht teilnehmen k&ouml;nnen, am Netz
teilnehmen lassen kann. Doch bietet dieses Konzept noch weitere M&ouml;glichkeiten. Z.B. 
wenn ein Router es nicht riskieren kann, mit nicht vertrauten Knoten direkt zu 
kommunizieren, bauen sie vertrauensw&uuml;rdige Verbindungen durch diese Knoten auf, die es 
ihnen erlaubt, all ihre Nachrichten zu senden und zu empfangen. Diese versteckten Knoten, die
absolut isoliert sein m&ouml;chten, verneinen auch alle Verbindungsversuche anderer Knoten 
(wie sie in den "Garlic Routing" Techniken zuvor dargestellt wurden) - sie nehmen einfach
den Garlicmantel, der den Befehl zum Transport zu einem bestimmten Knoten enth&auml;lt, und
routen diese Nachricht mitsamt den Befehlen zum Weiterreichen an den urspr&uuml;nglich 
geforderten Zielknoten &uuml;ber einen der vertrauensw&uuml;rdigen Verbindungen des 
versteckten Knoten hinaus.</p>

 </li>
 <li><h3 id="hashcash">Hashcash zur routerIdentity, destination  und Tunnel Nachfrage</h3>

<p>Im Netzwerk werden wir wollen, das einige Personen nicht zu viele Ressourcen verbrauchen 
oder so viele Knoten erstellen, das sie einen <a href="http://citeseer.ist.psu.edu/douceur02sybil.html">Sybil</a>
Angriff starten k&ouml;nnen. Traditionelle Techniken wie einen Knoten sehen lassen, wer 
eine Ressource anfordert oder einen Knoten beteibt, funktionieren in I2P nicht, da sie
die Anonymit&auml;t des Systems herabsetzen. Stattdessen m&ouml;chten wir einige
Anforderungen "teuer" machen.</p>

<p><a href="http://www.hashcash.org/">Hashcash</a> ist eine technik, die wir anonym nutzen 
k&ouml;nnen um bestimmte Aktivit&auml;ten "teuer" zu machen, so zum Beispiel das Erstellen
einer neuen Router ID (nur einmal bei der Installation n&ouml;tig), erstellen einer neuen
Destination (nur einmal beim Erstellen des Services n&ouml;tig) oder beim Anfordern von
Knoten zum Teilnehmen in Tunneln (oft, etwa 2-300 mal die Stunde). Wir kennen nicht die
"korrekten" Kosten f&uuml;r diese Aktivit&auml;ten bis jetzt, aber mit etwas forschen
und experimentieren sollten wir einen Basislevel finden, der ausreichend teuer ist
und dennoch keine unn&ouml;tige Belastung f&uuml;r die Leute mit wenig Ressourcen
darstellt.</p>

<p>Es gibt ein paar weitere Methoden die wir erkunden k&ouml;nnen um die Anfragen an
Ressourcen "nicht kostenlos" zu machen und mehr forschen an dieser Front ist gerne gesehen.</p>

 </li>
 <li><h3 id="batching">Fortgeschrittene Tunnel Operationen (Zusammenfassen/Mixen/Limitieren/Auff&uuml;llen)</h3>

<p>F&uuml;r grosse passive externe Beobachter und grosse interne, Kollusionen hervorrufende Beobachter
ist das standard Tunnel Routing angreifbar &uuml;ber Traffic Analysen - einfache die gr&ouml;sse und
Frequenz der Nachrichten zwischen Routern beobachten. Um sich dagegen zu sch&uuml;tzen, m&ouml;chten
wir einige der Tunnel in ihre eigene Mixing Kaskade verwandeln - Nachrichten am Gateway sammeln,
verz&ouml;gern und in Paketen aussenden, falls n&ouml;tig in anderer Reihenfolge und auch
das einf&uuml;gen von sinnlosen Nachrichten (f&uuml;r die Knoten im Pfad nicht von den "echten"
Nachrichten unterscheidbar). Es gab schon eine Menge an 
<a href="http://freehaven.net/doc/sync-batching/sync-batching.pdf">Nachforschungen</a> an diesen
algorhytmen, an denen wir zuerst lernen k&ouml;nnen bevor wir die verschiedenen Tunnel Mix
Strategien einbauen.</p>

<p>Zu den Aspekten der Anonymit&auml;t der mehr variierenden Tunnel Operationen gibt es auch
funktionale Aspekte. Jeder Knoten kann nur eine bestimmte Menge an Daten f&uuml;r das Netzwerk
transportieren. Und um einen bestimmten Tunnel daran zu hindern, eine viel zu grosse Menge 
der Bandbreite zu nutzen, sollten die Knoten einige Bremsen f&uuml;r die Tunnel eingebaut haben.
Zum Beispiel kann ein Tunnel so eingestellt werden, das er nach 600 transportierten Nachrichten
(1 jede Sekunde), 2,4MB (4KBps) oder &uuml;berschreiten eines Durchschnitts (8KBps f&uuml;r die
letzte Minute) gebremst wird. Zuviele Nachrichten werden verz&ouml;gert oder einfach fallen
gelassen. Mit dieser Art des Beschr&auml;nkens k&ouml;nnen Knoten eine Art ATM-QoS f&uuml;r
bereitstellen, welches verhindert, das verhindert, das mehr Bandbreite alloziert wird, als
der Knoten zur Verf&uuml;gung hat.</p>

<p>Dazu wollen wir m&ouml;glicherweise Code zum dynamischen Umrouten von Tunneln einbauen,
um ausfallende Knoten zu umgehen oder zus&auml;tzliche Knoten in den Weg einzuf&uuml;gen.
Dies kann durchs garlic routen einer Nachricht an einen bestimmtel Knoten im Tunnel geschehen,
die Informationen zum umdefinieren des n&auml;chsten Hops im Tunnel..</p>

 </li>
 <li><h3 id="stop">Stop &amp; Go Mix mit Garlic &amp; Tunnel</h3>

<p>&Uuml;ber das pro-Tunnel Sammeln und Mixen hinweg gibt es weitere M&ouml;glichkeiten
um sich gegen grosse Angreifer zu sch&uuml;tzen, so wie zum Beispiel f&uuml;r jeden Schritt
im garlic gerouteten Pfad eine Verz&ouml;gerung oder Zeitfenster zum Weiterrouten der
Nachrichten zu defenieren. Dieses gibt Schutz gegen einen langzeit "Intersection" Angriff,
da ein Knoten Nachrichten verschicken kann, die f&uuml;r die meisen Knoten auf dem Weg
wie perfekte Standard Nachrichten aussehen, nur f&uuml;r den Knoten nicht, f&uuml;r
den die Ummantelung die Verz&ouml;gerungsanweisung preisgibt.</p>

 </li>
</ul></li>

<li><h2 id="performance">Performance</h2><ul>


 <li><h3 id="reply">Stabile Tunnel / Lease Auswahl</h3>
<b><i>Ausgehende Tunnel Auswahl in 0.6.1.30 eingebaut, eingehende Lease Auswahl in 0.6.2</i></b>

<p>Die zuf&auml;llige Auswahl von Tunneln und Leases f&uuml;r jede Nachricht erzeugt
eine grosse Anzahl von Nachrichten, die nicht in korrekter Reihenfolge transportiert werden.
Dieses hindert die Streaming Bibliothek daran, die Gr&ouml;sse der Nutzdaten auf die 
maximal m&ouml;gliche zu erweitern. Durchs stabile Halten der Auswahl f&uuml;r eine
Verbindung wird die &Uuml;bertragungsrate viel h&ouml;her.</p></li>

 <li><h3 id="reply">Reduktion des B&uuml;ndels von Anwort-LeaseSets</h3>
<b><i>Implementiert in Release 0.6.2</i></b>

<p>I2P f&uuml;gte ein Antwort-Leaseset (typischweise 1056 bytes) an jede ausgehende
Klient Nachricht an, was ein massiver Overhead war. Korrigiert in 0.6.2.
</p></li>

 <li><h3 id="sessionTag">Umstellung von Sessiontag auf synchronisiertes PRNG</h3>

<p>Zur Zeit funktioniert unser <a href="how_elgamalaes">ElGamal/AES+SessinTag</a> Algorythmus so,
das er jede verschl&uuml;sselte Nachricht mit einer zuf&auml;lligen 32byte Einmalmarkierung markiert
(ein "Session Tag"), die die Nachricht als mit dem assozierenden AES Session Schl&uuml;ssel verschl&uuml;sselt
identifiziert. Dies verhindert, das Knoten Nachrichten als zur selben Session identifizieren k&ouml;nnen,
da jede Nachricht eine komplett neue zuf&auml;llige Markierung haben. Um dieses zu erf&uuml;llen
b&uuml;ndeln wir alle paar Nachrichten ein komplett neues Set an Session Tags in die
verschl&uuml;sselte Nachricht und haben so einen transparenten Weg um zuk&uuml;nftige Nachrichten
zu indentifizieren. Wir m&uuml;ssen dann nur noch die erfolgrich transportierten Nachrichten
verfolgen um zu wissen, welche Tags wir nutzen sollten.</p>

<p>Dieses arbeitet gut und robust, ist aber aus Sicht des Bandbreitenverbrauchs ineffizient,
da es das Vorschicken der Session Tags erfordert (und nicht alle Tags werden gebraucht, manche
k&ouml;nnen verfallen, da ihre Lebenszeit ausgelaufen ist). Im Schnitt kostet das Vorraussenden
der Session Tags 32 Bytes f&uuml;r jede Nachricht (die Gr&ouml;sse eines Tags). Wie taral
jedoch vorgeschlagen hat, kann das vermieden werden durch Nutzung einer synchronisierten PRNG -
sobald eine neue Session aufgebaut ist (durch den ElGamal verschl&uuml;sselen Block) seeden beide
Seiten eine PRNG und generieren die Session Tags nach Bedarf (wobei der Empf&auml;nger 
die n&auml;chsten paar m&ouml;glichen Tags vorrausberechnet, um Nachrichten in falscher 
Reihenfolge h&auml;ndeln zu k&ouml;nnen).</p>

 </li>
 <li><h3 id="streaming">Komplettes Streaming Protokoll Erweiterung</h3>
<b><i>Verschiedene Erweiterungen in I2P 0.6.1.28 eingebaut,
und signifikante zus&auml;tzliche Korrekturen in 0.6.1.33 eingebracht,
aber noch viel Platz f&uuml;r Verbesserungen</i></b>

<p>Seit I2P Version <a href="http://dev.i2p.net/pipermail/i2p/2004-November/000491.html">0.4.2</a>
haben wir eine "full sliding window" Streaming Bibliothek, die die alte
feste "Window"-Gr&ouml;sse Streaming Bibliothek stark erweitert und die
Verz&ouml;gerung beim nochmal senden stark herabsetzt. Wie auch immer, gibt es 
auch hier noch Platz f&uuml;r weitere Optimierungen:</p>

<ul>
<li>ein paar Algorhythmen um RTT und &Uuml;berlastungsinformationen
   &uuml;ber Streams auszutauschen (je Ziel-Destination?
   je Quellen-Destination? F&uuml;r alle lokalen destination?)
</li>
<li>weitere Verbesserungen f&uuml;r interaktive Datenstr&ouml;me
   (der Hauptfokus der aktuellen Implementation liegt auf 
   Bulk Datentransfers)</li>
<li>Mehe explizite Nutzung der neuen Features in der Streaming
   Bibliothek und der SAM(v2) Bridge um den Overhead je tunnel
   geringer zu bekommen</li>
<li>Bandbreitenbeschr&auml;nkungen auf Klientenebene (in je einer
   oder beide Richtungen des Datenstroms oder gar &uuml;ber 
   mehrere Datenstr&ouml;me hinweg). Dies ist nat&uuml;rlich
   eine Erweiterung der gesamten Routen Bandbreiten
   Beschr&auml;nkung.</li>
<li>Verschiedene Kontrollen f&uuml;r Destinations um zu regeln,
   wieviele Datenstr&ouml;me sie akzeptieren oder erstellen
   wollen (wir haben etwas an Grundlagen, aber deaktiviert)</li>
<li>Access Kontroll Listen (erlauben nur Datenstr&ouml;me von oder 
   zu anderen bekannten Destinations)</li>
<li>Web Kontrollen und &uuml;berwachen der Funktionen der
   unterschiedlichen Datenstr&ouml;me, sowie die M&ouml;glichkeit,
   diese direkt zu schliessen oder zu beschr&auml;nkenm</li>
</ul>

 </li>
</ul></li>

</ul>
{% endblock %}