Die Intention hinter dem Projekt finde ich sehr gut allerdings bin ich skeptisch wie sicher das ganze wirklich ist, folgender Gedankengang dazu:
Die IP Adresse des Knotens mit dem ich direkt über das Internet verbunden bin sehe ich logischer Weise. Ebenso besitze ich den Schlüssel für Inhalte die ich anfordere.
Der Knoten mit dem ich verbunden bin und dessen IP Adresse ich kenne, stellt mir also defacto Daten zu Verfügung die ich ggf. auch als illegal erkennen kann.
Oder werden Verfahren verwendet, die es erschwären dass ich den entschlüsselten Inhalt mit den als verschlüsselt empfangenen Daten identifizieren kann. Weis hier jemand wie das realisiert wird? Ich denke verhindern kann man das nicht.
Wer sagt mir also dass die Ermittlungsbehörden das nicht nutzen um Betreiber von Knoten mit bestimmten Inhalten in Verbindung zu bringen?
Als Betreiber eines Knotens besteht die einzige Sicherheit doch in der Rolle die mir in der Kommunikation zukommt und die eben darin besteht dass ich als Betreiber eines Knotens nicht Urheber der Daten bin, noch deren Inhalt kenne und somit angeblich nicht belangt werden kann.
Wie sieht denn derzeit die Rechtslage in Deutschland dazu aus, weis das hier jemand? Man könnte wohl argumentieren dass man auch nichts anderes macht als die ISP, die ihre Server und Router zu Verfügung stellen. Aber die ISP sind ja auch verpflichtet die Kommunikation zu protokollieren, zu Speichern und den Ermittlungsbehörden zur Verfügung zu stellen. Wie ist das also wenn ich als Betreiber eines Knotens nicht erklären kann wo die illegalen Inhalte herkommen die ich weitergeleitet habe?
@UffTaTa 
UffTaTa schrieb:Ich ging immer davon aus das, solange eine Verbindung (logisch) steht, diese Ports für andere Verbindungen nicht erreichbar sind (auf Transportebene, nicht auf Anwendungsebene).
Die logische Verbindung besteht zwischen Sockets nicht zwischen Ports. Ein TCP- Socket ist eindeutig charakterisiert durch:
Quell IP Adresse; Quell Port und Ziel IP Adresse; Ziel-Port
D.h wenn eine Verbindung steht, so kann trotzdem ein weiterer Host eine Verbindung über den gleichen Port zu einen der Teilnehmer aufbauen. (Und umgekehrt.)
Das geht problemlos, weil TCP die von verschiedenen Hosts empfangenen Pakete an verschiedenen Sokets abliefert (Transportschichtdemultiplexing).
Ein Port ist eigentlich nur eine Portnummer. Das Socket kannst du dir da schon eher als logisches Objekt vorstellen, das du in der oo Anwendungsprogrammierung tatsächlich auch als solches behandeln kannst. z.B.:
DatagramSocket einUDPSocket = new DatagramSocket (1024) ;
Erzeugt in Java ein UDP Socket mit Portnummer 1024
In UDP sieht das Transportschichtdemultiplexing übrigens anders aus, dort ist ein UDP-Socket charakterisiert durch :
Quell Port, Ziel-Port
Hier muss also tatsächlich die Anwendungen ggf noch die empfangenen Pakete hinsichtlich der Quell IP unterscheiden.
@interpreter 
interpreter schrieb:Ich hab mal auf der FTP Wiki-Seite nachgeschaut und weiß jetzt was du meinst, die Adressierung der Verbindungen über die Ports scheint nur stattzufinden, wenn sich die Clients beispielsweise in einem Firmennetz befinden wo viele Clients über die selbe IP senden und sich somit nicht voneinander unterscheiden lassen.
Ist zwar OT aber das würde mich jetzt schon interessieren: Warum muss in diesem Fall der Client bei FTP unterschiedliche Ports verwenden? Ich war mir bislang rech sicher das dem nicht so ist.
Die fest definierten Portes 20 und 21 kommen doch ohnehin nur auf Serverseite zum Einsatz der Client kann seinen Port frei wählen. Er kann doch ein und denselben Port nutzen um eine Verbindung zu Port 20 und 21 eines Servers aufzubauen (sind doch unterschiedliche Sockets da TCP)
interpreter schrieb:die Adressierung der Verbindungen über die Ports scheint nur stattzufinden, wenn sich die Clients beispielsweise in einem Firmennetz befinden wo viele Clients über die selbe IP senden und sich somit nicht voneinander unterscheiden lassen.
Eben. Dann translatiert ein NAT-Router oder Server im Firmennetz mittels NAT die Anfragen der einzelnen Hosts auf verschiedene Ports.
Dann ist auch klar dass ebendieser Router bzw. Server (der dann nach Außen als Client in Erscheinung tritt) seinen Port für die Kommunikation mit einem Server frei wählen können muss.(Sonst funktioniert NAT nicht.) Somit kann dieser aber auch über ein und denselben Port mehrere (durch unterschiedliche (Ziel IP,Ziel Port)-Tupel charakterisierte) Verbindungen aufbauen.
Chesus schrieb:Der Vorsitzende der Enquete-Kommission
