Dieser Text fasst einige wesentliche Punkte der 21 eingereichten Vorschläge zusammen. Er dient als Vorbereitung auf das Treffen am 11. Juni. Vorschläge für verbessertes Routing =================================== Dies sind nur die grundlegenden Ideen, die wir als Vorschläge erhalten haben. Die meisten Überlegungen dazu gingen natürlich noch deutlich weiter, können hier aber nicht wiedergegeben werden. Wenn Ihr Euren Beitrag unterrepräsentiert seht :-), meldet Euch bitte vor dem Kolloq noch einmal. Die allermeisten Vorschläge sehen vor, dass nun für alle Kanäle (ggf. außer anonyme Kanäle) Teilnehmerlisten ausgetauscht werden müssen. (Logisch. :-)) Grundsätzlich lassen sich die Routing-Ansätze wie folgt klassifizieren: - Reduzierung der TCP-Verbindungen im P2P-Netz auf einen Baum (oder ggf. eine andere Struktur, z.B. Mesh). Das erfordert intelligentes Erweitern des Baumes beim Anmelden und das Schließen von Lücken bei Abgängen/Ausfällen: - durch Austausch von Informationen über "Nachbarn der Nachbarn", die das Überbrücken ausgefallener Verbindungen erlauben. Das muss jedoch so geschehen, dass wieder ein Baum (ohne Schleifen durch die Überbrückung) entsteht. Oder: - durch die Übernahme von Aufgaben abgehender Baumknoten durch Vertreter und gezieltes Einfügen von neuen Knoten nur als Blätter oder an z.Zt. vertretenen Positionen. Dies ist recht kompliziert, hätte aber den Vorteil, dass sich das Routing aus den Positionen im Baum ergeben könnte, ohne eine explizite Routingtabelle. - Beibehalten redundanter Verbindungen, aber optimiertes Routing anhand von Routing Informationen. Diese Routing Informationen ergeben dann wiederum Multicast-Routing-Bäume, in diesem Fall aber logisch je Kanal statt in der Struktur der TCP-Verbindungen. Der Austausch der Routing Informationen kann erfolgen... - durch periodisches Aussenden von DVs an die jeweiligen Nachbarn, oder: - implizit durch den Absender und die TTL der Nachrichten, die einen Knoten sowieso passieren, oder: - durch das Fluten einzelner gezielter Nachrichten bei Änderungen der Peers. Bei Neuzutritt zeigt ein Hop-Counter jedem Empfänger die Distanz zum neuen Peer an. Bei Abgang/Ausfall propagieren dies ebenfalls die Nachbarn. Die so gewonnenen Routing-Tabellen in jedem Peer zeigen somit für jede UserID, über welchen direkten Nachbarn über wieviele Hops der User erreichbar ist. Wenn ein User erreicht werden soll (weil er Teilnehmer des Kanals einer "MessageMessage" ist), der noch nicht in der Routing-Tabelle enthalten ist, wird die Nachricht weiterhin geflutet, also an alle Nachbarn weitergeleitet (außer dem von den die Nachricht unmittelbar empfangen wurde). Auch wenn wir dem Kolloquium nicht vorweggreifen wollen, denken wir, dass die folgenden Ansätze nicht in der engeren Auswahl bleiben: - Chat-Multicast durch IP-Multicast. Die Überlegungen dazu gingen zwar durchaus recht weit, aber sprechen die erkannten Probleme tatsächlich gegen diesen Weg. Hauptgründe: Wir wollen auch "im Internet" wo wir nicht von einer IP-Multicast Infrastruktur ausgehen können, das System nutzen können. Die Abbildung von Kanal-Namen auf Multicast-Adressen wäre nicht ganz einfach. - Einige Vorschläge basieren weitgehend auf direkter Kommunikation zwischen je zwei Knoten in einer "normalen" Sender/Empfänger Beziehung. Wir wollen aber eigentlich bei einer P2P-Struktur bleiben. Diesen Weg wollen wir somit ebenfalls nicht weiter verfolgen. - Einige Vorschläge sehen einen oder mehrere Koordinatoren vor. Die dazu erforderlichen Auswahlalgorithmen erzeugen einen relativ großen Aufwand, der in Szenarien mit selten wechselnden (ausfallenden) Servern toleriert werden kann, aber in Systemen wie unserem Chat-Netzwerk mit laufend beitretenden und austretenden Peers problematisch ist. Offene Fragen: - Wie beeinflusst der Ausfall von Peers das Routing und wie wird für entsprechende Rekonfiguration des Routings gesorgt? - Wie kann überhaupt der Ausfall (nicht nur das ordentliche Abmelden) von Peers bzw. Links erkannt werden? Vorschläge für anonymisierte Kanäle =================================== Grundsätzliches: - Beiträge zu anonymen Channels dürfen natürlich keine Daten zum Absender enthalten. Vorgeschlagene Verfahren: - Anonymität "nur" durch zufällig gewählte TTL beim Sender. Ein Problem besteht bei der "besonders unsicheren" maximalen TTL. Bsp.: wählt ein Peer aus dem TTL-Intervall 10-20 zufällig den Wert 20 so läßt sich leicht auf den Absender zurückschließen. - Kein Routing für anonyme Nachrichten -> Flooding! - Routing der Nachrichten für einen anonymen Channel im Ring (gebildet aus allen Teilnehmern des anonymen Channel). - Anonymität durch "Verschlüsselungsketten" die vom Urheber gebildet werden: - Die Nachricht wird mit dem öffentlichen Schlüssel eines zufälligen User verschlüsselt und an diesen geschickt. Dieser wiederholt diesen Vorgang oder postet die Nachricht auf dem anonymen Channel aufgrund bestimmter Wahrscheinlichkeiten. Ebenfalls denkbar ist die Vorgabe einer Kette von mind. X Peers durch den Sender (z.B. durch Anon-TTL) ehe die Nachricht gepostet werden darf. - Die Nachricht wird "zwiebelartig" mehrfach nacheinander mit den öffentlichen Schlüsseln zufälliger User verschlüsselt. Bekommt ein Peer eine solche Nachricht, entfernt er die "Verschlüsselungsschale" des Users und schickt das Paket weiter an den nächsten User. Der letzte Peer in dieser Reihe kann die Nachricht vollständig entschlüsseln und postet den Inhalt auf dem anonymen Channel. Hierbei überwacht der eigentliche Sender den anonymen Channel und verschickt die Nachricht erneut, wenn sie nach Ablauf eines Timeout nicht auf dem Channel gepostet wurde. Mögliche Erweiterungen hierzu: - Einführen von zufälligen Dummy-Nachrichten, die bei der letzten Entschlüsselung als solche erkannt und somit nicht gepostet werden. - Einführen einer einheitlichen Größe für alle anonymen Nachrichten. - Zeitverzögertes Weiterversenden von anonymen Nachrichten. Weitere Anmerkungen zur Anonymität: - Sollte ein Peer für Anonymität mit mind. X anderen Peers verbunden sein? - Wie wird die MessageID für anonyme Nachrichten gebildet? - Machen geschlossene anonyme Kanäle Sinn? Wie wird das Problem der Schlüsselverteilung gelöst? - Angriffsmöglichkeiten, die bei der Auswahl des Verfahrens zu bedenken sind: - Beliebiger Traffic kann belauscht werden. - Möglicherweise können mehrere Peers zusammenarbeiten um die Identität eines Peers herauszufinden - Im schlimmsten Fall hat ein Angreifer eine totale Sichtweise auf das Netz. D.h. er sieht zu jedem Zeitpunkt welcher Peer welche Nachricht sendet und empfängt. Sonstige Beobachtungen ====================== - Das Problem, dass in der bisherigen Spezifikation ein Angreifer eine "ChannelMessage" erzeugen kann, in der er selbst einen neuen User auf einem geschlossenen Kanal ergänzt und einen gültigen Teilnehmer als Sender fälscht, wurde erkannt. Frage an alle: Wie lässt sich dieses Problem lösen? - DES ist nicht mehr als wirklich sicherer Verschlüsselungslagorithmus anzusehen. Trotzdem wollen wir ihn der Einfachheit halber weiter verwenden. - (Fast) alle wollen in Java programmieren. Eine mutige Gruppe hat sich für C#/Mono entschieden. (Super!) - Oft sind die Klassendiagramme noch nicht aussagekräftig, aber das ist ok. - Die Begriffe UserID und Peer wurden sehr oft nicht sauber auseinander gehalten. Ein User ist ein Teilnehmer. Seine Werkzeug im Netz ist das Programm, das im Netz einen Peer darstellt. Es wäre durchaus denkbar, dass ein Peer(-Prozess) von mehreren Usern benutzt wird. Wichtig ist auch die Unterscheidung der Adressierung: Ein User wird durch seine UserID identifiziert und adressiert. Ein Peer hingegen durch eine TCP-Portnummer und einen Domainnamen oder eine IP(v4 genügt)-Adresse. Annahmen für die weitere Diskussion =================================== Hier sind ein paar sehr vage Annahmen über das P2P Chat-Netz, die vielleicht hilfreich sind, um sich zu einigen Entscheidungsfragen eine Meinung zu bilden. Wir wollen kein hoch-skalierendes System anstreben. Dazu würden die erforderlichen Maßnahmen im Routing zu kniffelig werden. Aber wir wollen die Skalierung natürlich auch nicht ganz außer acht lassen und den Netzverkehr natürlich schon gegenüber der alten Spezifikation veringern, ohne eine Gefahr der Partitionierung zu erhöhen. - Anzahl der Kanäle: moderat, sagen wir mal ca. 10 im Rahmen des PVS-Testbetriebs. - Anzahl der Nodes bzw. Teilnehmer: Skalierbarkeit wäre schön, muss aber nicht beliebig sein. Im Rahmen des Praktikums nehmen wir mal eine Zahl zwischen #Gruppen und #Personen von ca. 40 an. - Channel-Rekonfigurationen: Das Anlegen und Löschen von Kanälen dürfte insbesondere bei der erstgenannten Annahme nicht sehr oft stattfinden. - Teilnehmer-Rekonfiguration: Das Anmelden, Abmelden und Ausfallen von Peers findet hingegen häufiger statt. - Reiner Chat-Traffic in den Kanälen sollte im Normalbetrieb den größten Anteil des Verkehrs an jedem einzelnen Knoten ausmachen, auch wenn das im Testbetrieb dieses Praktikums durchaus anders aussehen mag. Diese Annahmen dürften für viele Einsatzzwecke zutreffend sein. Im Idealfall könnt Ihr nach einiger Zeit der Entwicklung vielleicht das Chat-Netz gleichzeitig für Eure Tests und für die Diskussion von Fragen und Problemen bei der Kommunikation mit den Peers anderer PVS-Gruppen nutzen. Stefan und Frank, 2004-06-08