<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo,<br>
<br>
da wir uns vom praktischen in den theoretischen Bereich bewegen,
mal auf discuss verschoben.<br>
<br>
Am 08.10.2013 12:28, schrieb Erich N. Pekarek:<br>
</div>
<blockquote cite="mid:5253DE39.7060903@pekarek.at" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Netzneutralität ist gut, aber sie bringt herzlich wenig, wenn die
Folge daraus ist, dass die Übertragung leidet oder gänzlich
verunmöglicht wird.<br>
</blockquote>
Das hab ich auch als Prämisse gesetzt.<br>
Bei genauerer Überlegung ist dieser Kritikpunkt auch nicht wirklich
haltbar, da der Filter sich ja nicht um Inhalt, Protokoll, etc.
kümmert.<br>
Indirekt hat es halt dieselbe Symptomatik, da es nur gewisse
Programme/Funktionen sind, die dieses Verbindungspattern aufweisen.<br>
Und wenn er *genau* das tun würde was der Name sagt (P2P filtern),
wäre es eine Verletzung der Netzneutralität.<br>
Aber genug von "was wäre, wenn"...<br>
<br>
<blockquote cite="mid:5253DE39.7060903@pekarek.at" type="cite"> Zur
Kritik am Verstoß gegen das PPA:<br>
Insofern sehe ich für die <b><i>zeitweise und bedarfsorientierte</i></b>
Verwendung von Beschränkungen durchaus keinen Widerspruch zum PPA,
sondern eine Maßnahme, die die Existenz und Daseinsberechtigung
von Community-Netzwerken zu sichern imstande ist, wenn andere
Mittel nicht mehr funktionieren - zB weil Kontaktdaten nicht
aktuell sind; es sich um verwaiste Devices handelt etc.<br>
</blockquote>
Auch hier geb ich dir recht, allerdings ist dieser Filter weder
temporär noch bedarfsorientiert, sondern führt auf dem betreffenden
Knoten zu einer *grundsätzlichen* Blockade aller peers, die ein
gewisses Verbindungsverhalten aufweisen.<br>
In meinem Fall werde ich gesperrt, sobald ich mein lokales Netz an
0xff anbinde, da ich 2 Geräte betreibe, auf denen Symform läuft.
(Ist zumindest meine einzige Erklärung)<br>
Er orientiert sich (soweit ich das beurteilen kann) weder an der
Auslastung des Knotens, noch an der "Bösartigkeit" der Verbindungen.<br>
Außerdem handelt es sich auch nicht um ein "last resort", das nur
benutzt wird, wenn der Knotenbetreiber nicht erreichbar ist.<br>
<br>
<blockquote cite="mid:5253DE39.7060903@pekarek.at" type="cite"> Das
Zuschalten von Filtern oder QOS mag im Prinzip des PPA als
unzulässig gelten, aber man muss das, so denke ich, in Relation
zum Zweck der Bestimmung sehen: und der ist nicht, die Verbreitung
von Schadsoftware oder die Begünstigung von DDoS mit oder ohne
Wissen der Nutzer, sondern im Schutz der Privatsphäre und im
prinzipiell freien Datenverkehr zum Wohl der beteiligten Nutzer
begründet. </blockquote>
Und genau diesen freien Datenverkehr sehe ich hier beeinträchtigt.<br>
Inwiefern ergibt sich ein Schutz der Privatsphäre? (Außer, dass ich
geschützt bin, wenn ich keine Daten ins Internet schicken
kann...;-))<br>
<br>
<blockquote cite="mid:5253DE39.7060903@pekarek.at" type="cite">(Es
gibt aber kein Prinzip, das ohne sachliche begründete Ausnahme
gerecht wäre und daher auf Biegen und Brechen umgesetzt werden
muss - wäre dem so, könnten wir gleich wie die Provider eine
Policy ausgeben, in Hard- und Software "enforcen", wie dies bei
gewissen Provider(zwangs)modems der Fall ist. <a
moz-do-not-send="true"
href="http://www.heise.de/netze/meldung/Bundesnetzagentur-Anhoerung-zu-Zwangsroutern-1968755.html">Die
Deutschen diskutieren</a> gerade heftig über diese Unsitte.)<br>
Ich will das in unserem Netz nicht, ... <br>
</blockquote>
ack, das will hier, glaub ich, niemand.<br>
Wir haben allerdings ein agreement, das besagt, dass der eigene
Knoten als relay für den 0xff-traffic dienen muss. Die
Funktionalität dafür sollte auf jedem Knoten gegeben sein.<br>
<br>
<blockquote cite="mid:5253DE39.7060903@pekarek.at" type="cite"> In
diesem Zusammenhang muss ich allerdings auch (Selbst-)Kritik üben,
denn ein unverschlüsseltes Datennetzwerk über Funk ist auch nicht
gerade im Sinn einer Auslegung des PPA unter den Aspekten des
Datenschutzes und der Selbstbestimmtheit der Nutzer. Ich würde
daher zumindest soweit gehen, eine einfache Grundverschlüsselung
(WPA2-PSK) des Netzes oder Teilen davon zu fordern, auch, wenn das
nicht alle Lauscher abhalten kann.<br>
</blockquote>
Soweit ich weiß, gab es da den Konsens Verschlüsselung auf höheren
Layern zu propagieren.<br>
Da AES gerade unter Beschuss gerät und andere tiefgreifende
Diskussionen und Probleme im Crypto-Bereich existieren, würde ich
hier vielleicht noch abwarten, da man sonst evtl. ein falsches
Sicherheitsgefühl erzeugt.<br>
Gibt es schon Überlegungen/Versuche, wie sich das auf die
Netzlast/-kapazität auswirken würde?<br>
Allgemein ergeben sich damit viele neue Fragen und mögliche
Probleme.<br>
<br>
<blockquote cite="mid:5253DE39.7060903@pekarek.at" type="cite"> Wir
werden hoffentlich im Rahmen der Testtage diese Probleme
thematisieren und ich hoffe auf zahlreiches Erscheinen zu
"Funkfeuer - Quo vadis" laut Programm. Spannung ist garantiert.<br>
</blockquote>
Ich werd auf jeden Fall schauen, dass es sich ausgeht.<br>
<br>
Wenn dieser Filter wirklich nur DNS-requests sperrt, kann man damit
auch nicht viel Schaden vermeiden (ad Malware verbreiten). Dann ist
das Ganze eigentlich ein "DDoS-Schutz" mit unangenehmen
Nebenwirkungen, der nur länger andauernde Attacken blockiert, die
DNS benutzen.<br>
Insgesamt scheint es mir sinnvoller ein IDS/IPS(SNORT, nessus, etc.)
im Netz zu betreiben, dessen Meldungen (loglevel warn) auf der
Wien-Liste gepostet werden. Auch ein paar honeypots wären denkbar.
Beide Techniken sind auch besser geeignet, die Ereignisse
zurückverfolgen und die Ursachen nachhaltig beseitigen zu können.<br>
<br>
LG<br>
Martin<br>
<br>
P.S. Vielleicht doch besser auf die Security-Liste? Nachdem security
vermutlich eine Teilmenge von discuss ist, belass ich´s mal auf
discuss.<br>
</body>
</html>