Author Topic: Wissenswertes über I2P - Teil2 - Streaming Lib, Destinations und Leases  (Read 12370 times)

0 Members and 1 Guest are viewing this topic.

Offline postman

  • Advanced
  • ***
  • Posts: 281
  • Karma: +5/-0
  • Planet Peer Community
    • View Profile
Wissenswertes über I2P  - TEIL II -
geschrieben von postman
postman@i2pmail.org


Hallo nochmal,

Wer auf diesen Artikel stösst und noch nicht den ersten Teil gelesen hat,
sollte dies noch nachholen. Damit wird das Verständnis spürbar erleichtert :)

Ich hatte im letzten Teil das grundsätzliche Verfahren erläutert, mit dem
I2P Knoten untereinander kommunizieren. Das virtuelle Konstrukt, "Tunnel" genannt
sichert das Netzwerk gegen eine Reihe von Attacken und Bedrohungszenarien ab,
die eingesetzt werden könnten, um das Arbeiten des Netzwerks zu stören oder
Daten zu erheben, die eventuell genutzt werden könnten, um Verkehr im Netzwerk
mit bestimmten Diensten oder gar Nutzern zu korrelieren. Bitte nehmt zur Kenntnis,
dass ich nicht auf ALLE Mechanismen, sondern nur auf die Basisideen eingegangen bin.
Bestimmte Konzepte wie das Garlic-Routing und welche Kryptographie an welcher Stelle
eingesetzt wird, ist ausserhalb des Fokus' dieses Dokuments.

Wenn wir uns die Routerbasiskommunikation betrachten, stellen wir jedoch fest, dass
sich dort keinerlei Bezug finden lässt, wie denn nun Nutzer/Programme in diesem Netzwerk
zueinander finden. Die im ersten Teil zitierten Tunnel und die I2P interne Kommunikation
geschieht fern von Serverdiensten, Ports und Clients, die sie nutzen wollen.
Um dies zu ermöglichen, müssen wir uns einige weitere Komponenten der I2P
Welt näher anschauen.

In der normalen Internetwelt haben wir TCP/IP, wobei TCP das sogenannte Transportprotokoll
ist. Es adressiert den gewünschten Dienst über den Port, verfügt über eine
statusorientierte Kommunikation und Datenflusskontrolle, sowie Integritätschecks.

I2P könnte man als ein "IP" ÜBER TCP/IP betrachten. Die Router reden über
TCP/IP miteinander, bauen Tunnel auf und tauschen verschlüsselt über diese Tunnel
Nachrichten aus. Diese darin enthaltenen Nachrichten könnte man als
NEUE IP-Pakete betrachten, auch wenn ihnen, im Vergleich mit Ihren echten
Internetkameraden Merkmale, wie IP Absende und Zieladresse fehlen.
Aber genau das ist ja das Ziel bei I2P!

Partizipiert dein Router nur an Tunneln, bekommt er die eigentliche Nachricht
oder Payload nicht zu sehen. Er leitet sie einfach an den nächsten Partner weiter,
bis die Nachricht den Router erreicht, der am Ende des Tunnels ( oder Anfang des Tunnels )
steht. Nur dieser kann die Nachricht entschlüsseln.

Damit nun aus dieser Quasi-IP Nachricht etwas programmtechnisch nutzbares wird, gibt es
in I2P die sogenannte Streaming-Lib. Sie kann als TCP/UDP Implementierung von I2P betrachtet
werden, da sie Nachrichten aus den Tunneln zu einem Datenstrom zusammensetzt und
diese an lokale Ports auf deinem Node weiterleitet, an denen z.B. ein Webserver horcht
oder anderere Services laufen.




               dein Node
eingehender  +---------------+
Tunnel1      |  +---------+  |
-----------> |->|         |  |
[DATEN1]     |  |[DATEN1] |  |
             |  | +   +   |=====>Datenstrom  ---> <lokaler Port> <-> <Applikation>
eingehender  |  |[DATEN2] |  |                       z.b.9999        z.B Webserver
Tunnel2      |  | +   +   |  |
-----------> |->| CHECKS  |  |
[DATEN2]     |  +---------+  |
             | Streaming Lib |
             +---------------+




Im obigen Bild können wir schematisch erkennen, wie die Daten aus zwei
unterschiedlichen eingehenden Tunneln, von der StreamingLib zu einem
Datenstrom zusammengesetzt werden und danach an einen lokalen
Port geleitet werden. Wenn man bedenkt, wie die Tunnelbildung zustandekommt,
so fällt es einem Angreifer äussert schwer, nachzuvollziehen, welche Daten
die durch deinen Router laufen, schlussendlich für dich bestimmt waren,
da Daten, auch wenn sie die selbe Quelle und das selbe Ziel haben,
unterschiedlichste Wege durch das Netz nehmen werden.

Das gleiche gilt umgekehrt natürlich auch für ausgehende Daten.

Das klingt soweit ganz schön, ist aber alles nur akademischer Natur, wenn
es einem Anwender nicht gelingt den Dienst, den er kontaktieren möchte, in irgendeiner
Art zu benennen oder anzusteuern. Im normalen Internet haben wir dazu DNS Namen(Hostnamen)
und Ports. In I2P gibt es dies nicht. Trotzdem muss ein beliebiger Teilnehmer im Netzwerk
einen beliebigen I2P-öffentichen Dienst erreichen können.

Um dies zu ermöglichen, greift man zu einem nicht ganz leichten Verfahren, welches ich hier
versuche, zu erläutern. Wir bleiben  bei dem Beispiel Webserver.
Markus hat in seinem Howto http://board.planetpeer.de/index.php/topic,731.0.html
erklärt, wie man mit Zuhilfenahme des I2PTunnel Tools ( Webbasiert ) die Einrichtung eines neuen
Dienstes vornimmt. (Bitte unbedingt lesen, wer es noch nicht getan hat)

Das interessante dabei ist, dass für diesen "Dienst" neben dem Port und einigen weiteren
Angaben ein kryptographisches Schlüsselpaar mit
öffentlichem und privatem Schlüssel gebildet wird. Der private Schlüssel wird auf der Festplatte
in deinem I2P Arbeitsverzeichnis gespeichert. Der öffentliche Schlüssel wird "veröffentlicht", d.h. anderen
I2P Nutzern zugänglich gemacht. Er wird im I2P Jargon meist "Destination Key" oder einfach nur
"Destination" genannt. Der öffentliche Schlüssel ist also eine Art "Namen" unter dem dein Dienst
in Zukunft für andere zugänglich gemacht wird.

Da niemand 516 Zeichen gerne in seinem Browser eintippt, verfügt
dein I2P über eine hosts.txt Datei, in der alle bekannten und veröffentlichten Destinations unter einem
einfachen Namen abgespeichtert werden

Beispieleintrag aus der hosts.txt

sciencebooks.i2p=Rrqf6EmeuqckygNrim-ZcZ97uEIL9Ykkr8cj1RSGbeih33~UUpjAp0x2fxrpbibXwuGufWMNoaMkZH8FxOxZr1hvBeV4Mvjrn05kKWyPpB
B1x7rAcVCCoD~bl6CUU2k4NtFrO9~BCCZdoIvMxXYWRy4nj18RVaIlOS3qE6~F04pU7Fy0sj7xtd02wgeyKkJ6pXYGfETMr6phVusHSSQfCumDBpnqEt7EcXTIs
Pz58y9Zim4u1wp6xj~OvGWFIP8fKIxpH~zf6o0qYytXrf6SJbIEvwITKGIXZTM5KxQ0LbEydSgPn4q5PttQlKg~7hxuGG5RYqP2IMg-f9z4-1SfYTbz~EixEq8g
v0R30c60tqsyAaw9o37R3k9inkT5WylYwBKM0pzfcAVjejcoPYnFF1iithGl0AYkP~~isxCErCNwLs39NyE688C5amDIpXl7AgB~IvbwZfONbd2cwMOB2RFzTSh
YZlwcILB7EzgMvEt2l8GBkstP3CzNrjQ2gAL0AAAA



Aber woher weiss mein I2P Router WO er sich hinwenden soll wenn er sciencebooks.i2p connecten will?
Nun, die Veröffentlichung des Schlüssels in den I2P Foren oder im IRC oder mit Hilfe der mitgelieferten Adressbuch
Software, dient nur zur Bekanntmachung unter den Anwendern des Netzwerkes. Damit I2P Router den Service finden,
wurde ein automatisches Verfahren etabliert:

Nehmen wir mal an, du aktvierst einen Servertunnel für deinen Webserver auf Port 9999
dazu wird das Schlüsselpaar erzeugt, du announct den Destinationkey im I2P Forum. Gleichzeitig
muss dein I2P Router sicherstellen, dass Anwender deinen Server finden, ohne dabei deine tatsächliche
IP/Identität herauszufinden. Also kommen auch hier die Tunnel ins Spiel

Dein Router baut einen oder mehrere  eingehende Tunnel auf, über die dich Nutzer
in Zukunft erreichen können sollen


        +--------+        +---------+       +---------+     +--------+
        |Dein    |        |HOP 2    |       |HOP  1   |     |Gateway |
Port    |Router  |<-------|Router   |<------|Router   |<----|Router  |<---------
9999<---|        |        |der mit  |       |der macht|     |der mit |Daten FÜR mich treten hier
        |        |        |macht    |       |mit      |     |macht   |aus dem Netzwerk
        +--------+        +---------+       +---------+     +--------+in das Gateway meines
                                                                |     eingehenden Tunnels
                                                                |
                                                                |
                                                              NETDB




Das alleine hilft dir noch nicht. Als nächstes veröffentlicht
der Gateway Router eine Information der Form


"Hallo Leute, wenn ihr sciencebooks.i2p sucht ( Schlüssel: SchRrqf6EmeuqckygNrim-ZcZ97uEIL9Ykkr....)
 dann bin ich dafür der entgegennehmende Router für die nächsten paar Minuten"


in der sogenannten netdb. Die NetDB ist eine verteilte Informationsdatenbank, in der I2P speichert,
welche Router zum Netzwerk gehören und welche Destinations wie erreicht werden können.
Sie ist in Form einer Distributierten HashTable organisiert und arbeitet komplett dezentral, ist also auf
alle I2P Knoten verteilt.

Fällt euch etwas auf?

Der Router der in die Netdb speichert, dass eine bestimmte Destination über Ihn erreichbar ist,
seid nicht ihr, sondern der Gateway Router für euren eingehenden Tunnel. Damit ist euer
Router als eigentlicher Dienstanbieter versteckt und die HOP Router dazwischen kriegen
von all dem auch nichts mit.

Etwas zweites ist interessant:
Der Netdb Eintrag ist nur zeitlich begrenzt gültig. Meist gilt er nicht länger als 10 Minuten.
Aus diesem Grund wird dieses Announcement auch als "LeaseSet" bezeichnet. Der Gateway Router
ist nur für einige Minuten das System, welches für Euren Webserver eingehenden Tunnel spielt.
Nach ein paar Minuten werden die Karten neu gemischt ein neuer eingehender Tunnel wird gebaut,
der andere partizipierende Knoten hat und mit hoher Wahrscheinlichkeit auch einen anderen
Gateway Router. Ist dies geschehen wird das alte Leaseset durch ein neues ersetzt und alle,
die deinen Service nutzen wollen, müssen die neue Tunnelstrecke verwenden. Das ganze geschieht
für den Anwender unterbrechungsfrei. Dafür sorgt die Streaminglib.

Damit kann Euer Dienst gefunden werden, ohne das der Nutzer/Anwender weiss, welcher I2P Router
ihm den Service anbietet.

Der Client, der sich mit euch verbinden will, fragt also in der netdb an, auf welchem I2P Router
er einen eingehenden Tunnel für diesen Dienst findet, und benutzt einen oder mehrere seiner
ausgehenden Tunnel, um sich mit deinem Dienst zu verbinden. Dabei hat auch ein Client
eine Destination, da der Server ihm ja antworten können muss. Allerdings ist es so, dass Client Destinations
nicht in der Netdb gelistet werden. Stattdessen teilt der Client beim Verbindungsaufbau mit, über welchen
incoming Tunnel Gateway er für eine Antwort zur Verfügung steht.

Trotz dieses gewaltigen Aufwands kann die Geschwindigkeit, mit der im I2P Daten übertragen
werden, recht beeindruckend sein. Allerdings hängt dies immer auch von der Übertragungskapazität und der
Auslastung der beteiligten Router ab.

Ich hoffe mal, dass einige von Euch jetzt verstanden haben, nach welchem Verfahren
I2P grundsätzlich funktioniert. Im Teil III werde ich auf Bedrohungsszenarion und Sicherheitsrisiken eingehen

Bis dann
postman

--
postman@i2pmail.org
Postmaster and Administrator
http://hq.postman.i2p - I2P's free and anonymous Mailsystem