220 likes | 409 Views
Architektur und Implementation von Peer To Peer - Netzwerken. Peer To Peer – „Datenaustausch zwischen Gleichberechtigten“. Aufgabe des Vortrags: Präsentation/ Bewertung des Peer To Peer Systems (GNet) Darstellung der Entwicklung/Umsetzung von Effizienz und Sicherheit. Dazu benötigt:
E N D
Architektur und Implementationvon Peer To Peer - Netzwerken Peer To Peer – „Datenaustausch zwischen Gleichberechtigten“
Aufgabe des Vortrags: • Präsentation/ Bewertung des Peer To Peer Systems (GNet) • Darstellung der Entwicklung/Umsetzung von Effizienz und Sicherheit • Dazu benötigt: • Bildung einer Verständnisbasis über den Weg „vergangener“ Systeme • Der Weg: • Der Ursprung: Client-Server-Prinzip im WWW und die Probleme • Der neue Ansatz: Napster, neue Ziele und die entstandenen Probleme • Der zweite Ansatz: Gnutella, wieder neue Ziele und die Probleme • ...(Kombiformen aus Napster und Gnutella) • Der erste Schritt in die Zukunft: GNet, dessen neue Ziele und Probleme
„Die Probleme kommen aus der Vergangenheit“ Wozu überhaupt Peer To Peer – Netzwerke? Client – Server – Prinzip ist Ursache der Entstehung von Peer To Peer - Denken Client – Server – System im WWW WWW-Server • Suche ist: • einstufig • Erweiterung: zweistufig • durch Suchmaschinen http://www.inf.fu-berlin.de http://www.netzwerke.de html divx mp3 http://www.berlin.de • Probleme: • Starke Server zur Sättigung • starker Nachfrage • Server benötigen • große Bandbreite • -> Flaschenhals Bandbreite www-Client www-Client www-Client
Napster • Ziele: • Schnelle Suche und Download von MP3-Dateien • Lastverteilung • Bedeutet: • Getrennte „Kanäle“ für Anfragen und Daten Architektur: Index Server Index: [(Suchbegriff, IP- Adresse)] „ZZ Top“ 212.189.23.21 212.189.23.21, ZZ Top www-Client www-Client 212.189.23.21 ZZ Top.mp3
Implementation: • „http“ auf TCP/IP als Protokoll zwischen allen Hosts • Kommunikation in Klartext (unverschlüsselt) • zentraler Index mit (Beschreibungstext, IP (Host)) - Tupeln • Probleme: • Indexserver Attacken von bösartigen Dritten. • Qualitätsangriff (Senden von falschen Informationen für den Server) • Quantitätsangriff (Bandbreitenzerstörung durch übermäßige Anfragen) • Ausschalten durch Staat • Abhören der Kommunikation (Wer bietet an, wer empfängt) • Senden falscher Dateien / Viren vom bösartigen Dritten. • Fazit: • Lastverteilung funktioniert sehr gut • massivste Schwächen bei Sicherheit und damit Bestand des Systems
Neuer Ansatz: Gnutella • Ziele: • Wahrung der Performance durch Lastverteilung • Schaffung von Sicherheit (teilweise Anonymität) • Dezentralisierung • Folgende Erweiterungen zu Napster: • Dezentraler „Index“ • = jeder Servant besitzt eigenen Index. • „Index“ besteht aus Dateiindex, Hostindex • Verschlüsselung von Anfragen (RSA) • -> Wahrung von Anonymität beim Empfang von Anfragenachrichten • durch Nichttauschpartner
Architektur: Die Anfrage – Sammlung von Ergebnissen • keine „Server“, keine „Clients“, nur „Servents“ • zweistufiges System wie Napster • jede Anfrage wird verschlüsselt versendet (RSH) • Stufe: Sammeln von „positiven“ Adressen • Stufe: Download von gewählter „positiver“ Adresse Servent Dateiindex [(Suchtext, Datei)] Anfragenverwaltung [ Anfrage ] Anfrage Hostverwaltung [ IP ] • Suchtext • Adresse • TTL (Time To Live)
Probleme des Gnutella Ansatzes: • Überschwemmung der Bandbreite durch Anfragen • Überschwemmen der Servents mit Rechenarbeit durch • kontinuierliche Verschlüsselung und Abarbeitung von • Anfragen • Fazit: • lange Suchen • Downloadgeschwindigkeit wird ausgebremst • gezielte Angriffe auf Servents leicht möglich • Qualitätsangriffe (Verbreiten von „falschen“ Inhalten) • falsch = nicht den Inhalt spezifizierende Suchtexte • Quantitätsangriffe (zigfaches Downloaden des selben Inhalts • vom selben Servent) • -> Nicht Effizient und nicht sicher
Allgemein: • Was soll das System leisten? • Effizienz – schnelle Suche – schnelles Herunterladen • Quantität – viele Inhalte als Angebot • Qualität – korrekte Inhalte als Angebot • – durch Verifikation (automatisch) • Effizienz – Ressourcenverwaltung (CPU, Speicher, Netzbandbreite) • Sicherheit – Abhörsicherheit - Anonymität – Ausfallsicherheit • – Ausschließen von bösartigen Dritten • Skalierbarkeit – Mit wachsender Benutzerzahl keine schlechtere Performance • -> GNet und Freenet leisten dies • Warum eine Beschreibung hier von GNet? • Freenet – Ansatz ist auf Grund von Verwendung von Namensräumen • sehr komplex • GNet – Ansatz ist noch verständlicher, bei besserer Leistung
Sessionverwaltung • Anfrageverwaltung 1 • Prioritätswarteschlange [(SessionID, IP, public Key, AnfragenID)] [(Priorität, Hashwert)] • Privater Schlüssel zur Identifikation • öffentliche Schlüssel werden generiert • RSA - Kodierung Anfrage (Hinweg) Inhalt (Rückweg) Hashwert, Priorität, TTL Hashwert, Priorität, TTL Inhalt, SessionID Der Ansatz GNet: • nutzt UDP anstatt TCP/IP um Bandbreite zu sparen -> Sessionverwaltung benötigt • Eindeutigkeit von Inhalten -> Hashen der Inhalte mit RIPE160 • Eindeutigkeit von Anfragen -> Hashen der Anfragen mit RIPE160 • Einstufiges Such/Ladesystem Servent Dateiindex [(Hashwert, Inhalt, Rang)] Hostindex [Hashwert,Host-IP, public Key, Rang)]
Rang 16 Rang 20 Rang 7 Rang 11 • Anfrageverwaltung 1 • Prioritätswarteschlange • [Hashwert, Priorität, TTL)] Rang 12 Rang 8 Rang 8 Rang 5 Dateiindex [Hashwert, Inhalt)] Hostindex [Hashwert,Host-IP, public Key, Rang)] Sessionverwaltung [(SessionID, IP, public Key, AnfragenID)] Routing der Anfragen: (Backtracking) • RSA – Verschlüsselung • der Anfragen Rang 10 Rang 5 Rang 2 Rang 1
Dateiindex [Hashwert, Inhalt)] Sessionverwaltung [(SessionID, IP, public Key, AnfragenID)] Routing der Inhalte als Ergebnisse der Anfragen: Inhalt • Blowfish – Verschlüsselung • der Inhalte • Cachen der Ergebnisse Inhalt Inhalt Inhalt
Nicht geklärte Problematiken: • lokale Rangvergabe der „Servents“ für intelligentes Routing • Verhindern von Angriffen durch bösartige (Rangvergabe) • effiziente Speicherplatznutzung (Vergabe von Rängen für Inhalte) • Steigerung der Effizienz durch „Splitten“ von Inhalten • Steigerung der Qualität durch automatische Verifikation
Rangvergabe der Servents: • Ziel: • Qualitativ hochwertiges Routing der Anfragen • Ausschließen von bösartigen Hosts durch schlechte Ränge Jeder Servent führt über seine „Tauschpartner“ eine eigene Rangliste, die über das Transaktionsverhalten des Tauschpartners gesteuert wird. • Der Rang erhöht sich: • mit hoher angebotener Bandbreite • mit hoher Verfügbarkeit • mit positiven Verifizierungen der gelieferten Inhalte • mit Beachtung des Kommunikationsprotokolls • mit Wichtigkeit der angebotenen Inhalte • bei mehr Beantwortungen durch versenden von Inhalten als Anfragen -> Nur Weiterleitung von Anfragen über gute Servents (höchster Rang) -> Ab einer bestimmten unteren Ranggrenze -> bösartiger Tauschpartner
Speicherplatznutzung von Inhalten: • Ziel: • Speicherplatz sparen • System: • Zwei Speicherplätze (Cache, On the Fly - Speicher) • Verweis zu Freenet (ist an dieser Stelle ineffizient! Freenet 2GB „Lesbarer“ Speicher GNet • Grosser Vorteil von GNet 1GB „Lesbarer“ Speicher Cache Cache • Löschen von unwichtigen Inhalten mit geringem Rang aus dem Cache
Steigerung der Effizienz: Splitten von Dateien • Ziel: • schnelleres Verteilen von Inhalten durch verteilen durch • Teilen von Inhalten Ursprungsinhalt Aufgeteilter Inhalt (Block = 1KB) Hashen jedes Blockes einzeln Zusammenfassen aller Hashwerte zu einer Indirekten Datei Indirekte Datei ist wieder Ursprungsdatei
Steigerung der Effizienz: Splitten von Dateien • Dateiindex erhält dann immer als Eintrag: • (Hashwert der indirekten Datei, Pfad der indirekten Datei) • (Hashwert eines Blocks, Pfad des Blocks) • … • Suche erfolgt nach: • indirekter Datei (ungenaue Suche) • nach Blöcken (genaue Suche)
Servent1 Servent2 … Steigerung der Qualität: automatische Verifikation von Inhalten Folgendes Verfahren: • Sei B 1KB Block -> H(B) ist der Hashwert von B • Sei S Suchanfrage -> H(S) ist der Hashwert von S • Für positives Suchanfrage gilt: S „passt zu“ B B, H(B) S, H(S) H(H(H(S))) H(H(H(S))) „passt zu“ H(H(H(B))) V(B) = B mit H(B) verschlüsselt H(H(S)) „passt zu“ H(H(B)) V(B) unter H(S) im Dateiindex speichern
Probleme des GNet – Ansatzes: • Endlicher Horizont verhindert finden aller Inhalte • -> Einsatz eines TTL • Informationen gehen verloren • -> Inhalte mit geringem Ranggehen verloren • Zu feines Splitten (1KB) vergrößert indirekte Dateien • -> Speicherplatzverbrauch, Bandbreitenreduzierung • Träger Start eines neuen Servents (Rang eines bösartigen Hosts) • Einstufiges System verhindert die manuelle Verifikation • (manuelle Verifikation == beste Verifikation) • merke Problematik (H(H(H(S))) „passt zu“ H(H(H(B))) • ungenaues „passt zu“ -> falsche Inhalte werden auch geladen • genaues „passt zu“ -> wenig Inhalte sind Treffer • Kein Update defekter Inhalte möglich • -> Ausschluss durch negativ verlaufende Verifikation
Quellen: • Skript zu GNet • Skript zu Freenet • Gnutella • [http://www.heise.de/tp/deutsch/inhalt/te/8504/1.html] • [http://www.zuviel.org/magister/node56.html] • RSA – Verschlüsselung mit sehr genauen Beispiel (Ver-, Entschlüsseln) • [http://www.pro-privacy.de/pgp/tb/de/rsa.htm] • [http://www.oszhdl.be.schule.de/gymnasium/faecher/informatik/krypto/rsa.htm] • RIPE160 – Hashfunktion (Funktionsweise, Geschwindigkeit, Alternativen) • [http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html] • Blowfish – Verschlüsselung • [http://home.t-online.de/home/jerry.luitwieler/krypto4.htm#_Toc435352926]