I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

einige changes eingebunden

Browse Source
This commit is contained in:
amiga4000
2008-09-14 14:01:32 +00:00
parent 89025daa09
commit 7a2b0e0411
3 changed files with 78 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
www.i2p2/pages/faq_de.html
View File

@ -10,7 +10,7 @@ Hier sind ein paar Stellen, wähle einen oder mehrere
<li><a href="http://trac.i2p2.i2p/newticket">trac.i2p2.i2p</a> Ticket
<li><a href="http://forum.i2p/viewforum.php?f=10">forum.i2p</a>
<li><a href="http://paste.i2p2.i2p/">paste.i2p2.i2p</a> und melde den Link im IRC Kanal #i2p
<li>Diskusssion mit den Entwicklern im IRC Kanal #i2p
<li>Diskussion mit den Entwicklern im IRC Kanal #i2p
</ul>
</p>
<p>
@ -69,7 +69,7 @@ Falls deine native jbigi Bibliothek problemlos funktioniert kommt der Grossteil
der CPU Last wahrscheinlich vom Routen der "Participating Tunnel". Dieses erzeugt
Last auf der CPU, da bei jedem Hop eine Schicht von Verschl&uuml;sselung
dekodiert werden muss. Du kannst die Ausnutzung durch "Participating
Tunnel" auf 2 Wegen beschr&auml;ken - durch reduzieren der "shared Bandbreite"
Tunnel" auf 2 Wegen beschr&auml;nken - durch reduzieren der "shared bandwith"
auf der Seite
<a href="http://localhost:7657/config.jsp">config.jsp</a> oder durch setzen von
<tt>router.maxParticipatingTunnels=nnn</tt> auf der Seite
@ -89,14 +89,14 @@ akzeptieren m&uuml;ssen.
Aber lass uns die Frage in 3 Teilen beantworten:
<ul>
<li><b>Verteilen</b> - Alle Daten in I2P sind in mehreren Schichten verschl&uuml;sselt. Du
kennst nicht den Inhalr der Nachricht, ihren Ausgangspunkt oder ihr Ziel. Deine einzige
kennst weder den Inhalt der Nachricht noch ihren Ausgangspunkt oder ihr Ziel. Deine einzige
Auswahl ist nur, generell keine Daten zu routen, indem Du die "Share" Bandbreite oder die
maximale Anzahl der "Participating Tunnel" auf 0 setzt (siehe oben). Es w&auml;re sch&ouml;n, wenn
du dieses nicht machst, du solltest dem Netzwerk helfen, in dem du fremde Daten weiter
leitest.
<li><b>Speichern</b> - I2P hat keinen verteilten Datenspeicher, du musst an Freenet denken.
Du speicherst keine Daten f&uuml;r jemand anderen.
<li><b>Zugriff</b> - Falls es Eepsite gibt, die Du nicht magst, besuche sie nicht!
<li><b>Zugriff</b> - Falls es Eepsites gibt, die Du nicht magst, besuche sie nicht!
Oder benutze einen Proxy wie Privoxy, der den Zugriff dazu f&uuml;r dich sperrt.
</ul>
@ -148,16 +148,16 @@ von h&ouml;heren Bandbreitenlimits (Mehr Bandbreite freigeben).
<p>
Nein, im Gegensatz zum <a href="http://www.torproject.org/">Tor Netzwerk</a>,
sind "Ausgangspunkt" oder "Outproxies" nicht in der Installation von I2P enthalten
und somit nicht Standard Teil des Netzwerkes.
Nur Freiwillige, die eine zus&auml;iche Anwendung installieren und betreiben
und somit nicht Standard-Teil des Netzwerkes.
Nur Freiwillige, die eine zus&auml;iche Anwendung installieren und betreiben,
k&ouml;nnen Daten ins normale Netz umsetzen. Es gibt nur sehr wenige davon.
</p>
<h3 id="outproxy">Ich kann keine normalen Internetseiten &uuml;ber I2P erreichen.
<span class="permalink">(<a href="#outproxy">link</a>)</span></h3>
<p>
Siehe oben. Es gibt nur wenige HTTP "outproxies", diese nicht ein automatischer Teil des
Netzwerkes und sie k&ouml;nnen nicht aktiv sein.
Siehe oben. Es gibt nur wenige HTTP "outproxies", diese nicht ein offizieller Teil des
Netzwerkes und sie k&ouml;nnen inaktiv sein.
hinzu kommt, das die Outproxies squid.i2p, true.i2p und krabs.i2p nicht mehr aktiv sind.
Der einzige aktive zur Zeit ist false.i2p.
Um diesen zu benutzen,
@ -181,7 +181,7 @@ von h&ouml;heren Bandbreitenlimits (Mehr Bandbreite freigeben).
m&ouml;glich, versuche einfach diese zu installieren, mit einem Standard Tunnel
zu konfigurieren und probiere es einfach aus!
Wie schon mehrmals im oberen Bereich erkl&auml;rt sind Outproxies nicht Bestandteil des
eigentlichen I2P Netzwerkes, es sind Dienste die von einzelnen Personen betrieben werden
eigentlichen I2P Netzwerkes. Es sind Dienste die von einzelnen Personen betrieben werden
und jederzeit funktionieren oder nicht funktionieren k&ouml;nnen.
Falls Du einen Outproxy aufsetzen m&ouml;chtest, betrachte sorgf&auml;ltig die
m&ouml;glichen Risiken davon.
@ -335,13 +335,13 @@ verbinden oder mit einem Passwort sichern?
<li><b>Ausgehender TCP Transport von verschiedenen hohen Ports an verschiedene TCP Ports</b></li>
<li><b>(optional, aber empfohlen) Eingehender UDP Transport an Port 8887 von verschiedenen Adressen</b></li>
<li><b>(optional, aber empfohlen) Eingehender TCP transport an Port 8887 von verschiedenen Adressen</b><br />
Per default lauscht I2P nicht auf eingehende TCP Verbindungen.<br />
Per Voreinstellung lauscht I2P nicht auf eingehende TCP Verbindungen.<br />
Um dieses zu aktivieren, kannst du entweder I2P die Adresse und Port automatisch erkennen lassen,<br />
werden aus dem UDP Transport ausgelesen, oder du kannst die IP Adresse (oder einen DNS Namen)<br />
und einen TCP Port per Hand eintragen. Du kannst diese Funktion auf der Konfigurations Seite<br />
aktivieren.</li>
<li><b>Ausgehender UDP Transport auf Port 123, Antworten erlaubend</b><br />
Dieses ist f&uuml;r da I2P interne Zeit synchronisieren notwendig. Es fragt via SNTP zuf&auml;llige
Dieses ist f&uuml;r das I2P-interne Zeit synchronisieren notwendig. Es fragt via SNTP zuf&auml;llige
SNTP Server im pool.ntp.org Pool oder einen von dir eingestellten Server ab.</li>
</ul>
</li>

8
www.i2p2/pages/roadmap_de.html
View File

@ -14,7 +14,7 @@
entwicklen</li>
<li>Zuverl&auml;ssliche Verbindungen, vern&uuml;nftige Performance</li>
<li>Verteilte / erweiterte i2pupdate Verteilung, Standardeinstellung auf Download setzen</li>
<li>Bessere n00b-Sicherheit (abfangen von OOM and falschen Einstellungen, bessere Anleitungen,
<li>Verbesserte Einsteiger- und Benutzerfreundlichkeit sowie besserer Schutz vor Fehlbedienung (bessere Anleitungen,
bessere Standardeinstellungen auf langsamen PCs)</li>
<li>Test mit gr&ouml;sserer Benutzerbasis, fixen von Problemen</li>
<li>Aktuelle, korrekte Website</li>
@ -25,7 +25,7 @@ mehr ben&ouml;tigt wird?
<h2 id="1.0">1.0</h2>
<ul>
<li>Volle &Uuml;berpr&uuml;fung auf Schachstellen in der Anonymit&auml;t und weitere Schwachstellen</li>
<li>Volle &Uuml;berpr&uuml;fung auf Schwachstellen in der Anonymit&auml;t und weitere Schwachstellen</li>
<li>Reduzierung des Speicherverbrauchs, entfernen der Debuginformationen, I2P auf langsamen und
embedded PC besser lauff&auml;hig machen</li>
<li>Anleitungen und Dokumente</li>
@ -42,6 +42,6 @@ embedded PC besser lauff&auml;hig machen</li>
<li>Anwenderdefinierte Verz&ouml;gerung in den Tunneln</li>
</ul>
<p>Bitte schaue auf der <a href="todo_de">Todo</a>liste nach f&uuml;r mehr detailiertere Informationen
zu mehreren dieser aufgaben.</p>
<p>Bitte schaue auf der <a href="todo_de">Todo</a>liste nach nach detaillierteren
Informationen zu diesen Aufgaben.</p>
{% endblock %}

125
www.i2p2/pages/todo_de.html
View File

@ -1,10 +1,10 @@
{% extends "_layout_de.html" %}
{% block title %}To Do Liste{% endblock %}
{% block content %}<p>Hier ist eine detailietere (und dennoch unvollst&auml;ndige)
{% block content %}<p>Hier ist eine detaillietere (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
oder Werkzeuge zum absichern der eigenen Computer gegen Angriffe. 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.
@ -16,10 +16,11 @@ M&ouml;chtest du helfen? <a href="getinvolved_de.html">Beteilige Dich</a>!
<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>
<li><a href="#netdb">NetworkDB und Profiloptimierung und Entfernungsregeln f&uuml;r grosse
Netze</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="#tunnelId">Pro-hop Tunnel ID und 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>
@ -49,13 +50,13 @@ 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
von einem anderen Gateway aus einen Tunnel zu sich aufbauen. 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
<p>Hierf&uuml;r verbinden sich die nicht erreichbaren Knoten einfach mit ein paar anderen
Knoten, bauen einen Tunnel durch sie auf und ver&ouml;ffentlichen eine
Referenz auf diese Tunnel in Ihrer RouterInfo Struktur in der Netzwerk Datenbank.
</p>
@ -81,15 +82,15 @@ 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
<p>Hierbei geht es nicht darum, die IP eines Knotens zu verstecken, es ist
eher eine M&ouml;glichkeit um Nutzern 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>
Eingangsgateway. Innerhalb eines Tunnels sollten zwei benachbarte Knoten nicht
versteckt sein, dennoch wird diese Regel technisch nicht ben&ouml;tigt.</p>
</li>
<li><h3 id="transport">Hochentwicklete Transportschicht mittels UDP, NBIO, oder NIO</h3>
@ -99,18 +100,18 @@ sollten nicht versteckt sein, aber das ist technisch nicht n&ouml;tig.</p>
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>
Thread. Der lesende Thread ruft einfach in einer Schleife eine Reihe vo read()-Aufrufen
auf, baut I2NP Nachrichten auf und f&uuml;gt sie einer internen Warteschlange f&uuml;r
eingehende Nachrichten 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
<p>Wir machen das aus CPU-Sicht recht effizient - die meiste Zeit warten fast alle Threads
unt&auml;tig. 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
Knoten, mit der ein jeder Router kommuizieren m&ouml;chte (man bedenke, dass I2P voll
verbunden ist, was bedeuted, das jeder Knoten wissen sollte, wie er eine Nachricht zu einem
anderen Knoten bekommt. Eine Einschr&auml;nung der Routen 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>
@ -119,18 +120,18 @@ Verbindungen haben!</p>
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
<b><i>Implementiert in I2P 0.6 ("SSU") und <a href="udp.html">hier</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
<p>Das Senden und Empfangen von UDP Datagrammen geschieht ohne stehende Verbindung.
Auch bei 100.000 anderen Routern ben&ouml;tigt UDP nur einen einzelnen Thread, der
die ausgehenden Pakete aus einem Stack ausliest und versendet
(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.
zu implementieren wird viel Arbeit sein, aber I2P braucht nicht alle Featuers von 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.
@ -145,31 +146,32 @@ optimieren in Hinblick auf die speziellen Bed&uuml;rfnisse von I2P.</p>
<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.
Entwicklern erlaubt, die Vorteile der nicht-blockierenden IO-F&auml;higkeiten des Systems zu
Nutzen - dadurch kann eine grosse Menge von gleichzeitigen IO-Operationen verwaltet werden,
ohne die Notwendigkeit eines seperaten Threads f&uuml;r
jede einzelne IO-Operation. Dieser Ansatz ist vielversprechend, da wir auf diese Weise viele
Verbindungen gleichzeitig verarbeiten k&oouml;nnen und keinen
selbstgeschriebenen Mini-TCP Stack in UDP ben&oouml;tigen.
Dennoch sind die NIO Pakete nicht ganz fehlerfrei, wie die Freenetentwickler
feststellen mussten Hinzu kommt, das wir mit NIO Support nicht die Open Source
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
<a href="http://www.classpath.org/">GNU/Classpath</a> NIO nur im geringen Umfang
unterst&uuml;tzt.
<i>(Hinweis: dieses ist wom&ouml;glich nicht mehr der Fall, da es Verbesserungen bei
<i>(Hinweis: das ist wom&ouml;glich schon/bald 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
<p>Eine weitere Alternative in diese Richtung 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
eine grunds&auml;tzliche saubere NIO-Implementierung (geschrieben bevor NIO da war).
Es verwendet einige BEtriebssystem-Routinen des nichtblockierenden IO
und reicht Events an Java weiter. 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>
<li><h3 id="netdb">NetworkDB und Profiloptimierung und Entfernungsregeln f&uuml;r grosse
Netze</h3>
<p>In der derzeitigen Netzwerkdatenbank und Profilemanagement Implementation haben wir uns
die Freiheit genommen, ein paar praktische Vereinfachungen zu nutzen. Zum Beispiel
@ -195,47 +197,46 @@ f&uuml;r sp&auml;ter.</p>
<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>
Pro-hop Tunnel ID und 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
<p>Zur Zeit wissen, wenn Alice einen 4-Hop Eingangstunnel aufbaut, der bei Elvis beginnt
und &uuml;ber Dave,Charlie und Bob zu Alice geht (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>
an Bob weiter. Beabsichtigt wird damit, dass Bob oder Charlie nicht wissen, dass sie im Tunnel
von Alice teilnehmen. Unterschiedliche Tunnel IDs erschweren "Collusion-Attacken". </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
teilnehmen, jedoch k&ouml;nnen sie es 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.
verhindern einfacher Attacken genutzt wird). Die TunnelMessage Struktur muss hierf&uuml;r
geriongf&uuml;gig ge&auml;ndert werden, als auch die Einbindung von pro-Hop geheimen Schl&uuml;sseln,
die beim Tunnelaufbau transportiert 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
Das Gateway senden dann diese 16-fach verschl&uuml;sselte Nachricht mitsamt den 16-fachem,
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
Hop Tunnel ID gekennzeichnet) und pr&uuml;ft die Nutzdaten 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.
<p>Das Tunnel Gateway hat immer noch mehr Informationen als die anderen Knoten im Tunnel
und die &Uuml;bernahme des Gateways und eines Tunnel Teilnehmers erlaubt Angreifern, diesen
Knoten zu vergleichen und festzustellen, dass 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>
wissen, an wen sie die Nachricht gesendet haben. Mit IP basierten Transporten ohne
beschr&auml;nktes Routing wissen sie auch von wem die Nachricht kam. Dennoch erh&ouml;hen
die oben genannten Techniken erheblich die Kosten um bei l&auml;ngeren Tuuneln
aussagekr&auml;ftige Daten zu erlangen.</p>
</li>