<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2013-10-08 21:32, schrieb Martin Asmus:<br>
</div>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hallo,<br>
<br>
da wir uns vom praktischen in den theoretischen Bereich bewegen,
mal auf discuss verschoben.<br>
</div>
</blockquote>
Vorweg: ich gebe Dir in den maßgeblichen Punkten Recht, und ich bin
nicht konkret auf das vorliegende Problem eingegangen, sondern auf
das Problem einer Maßnahmensetzung im Allgemeinen. Daher würde ich
die Diskussion auch gerne auf die Testtage verlagern, ... über Mails
lösen wir das nicht.<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite">
<div class="moz-cite-prefix"> <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">
</blockquote>
</blockquote>
...<br>
Lass mich trotzdem hier ein paar Punkte klarstellen:<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite">
<blockquote cite="mid:5253DE39.7060903@pekarek.at" type="cite">...<br>
</blockquote>
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>
</blockquote>
Schon richtig. Hierzu sollten wir einen Ablauf - best practices -
definieren. Manche Vorgehensweisen passieren einfach aus der Not
heraus und ich gehe davon aus, dass einige Knoten keine ideale
Konfiguration haben (siehe unten). Da liegt noch Arbeit vor uns -
und auch das ist wohl "experimentell" am Netz.<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite">
<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>
</blockquote>
Bleiben wir beim Problem: Es gibt guten Traffic und weniger guten
Traffic, ob das nun ins Idealbild passt oder nicht: Eine
Wasserleitung soll schließlich auch dicht und stabil sein, damit sie
ihren Zweck erfüllt; Ist sie das nicht gibt es Schäden.<br>
Netzneutralität sehe ich in diesem Vergleich durch Stabilität und
Dichtheit und der Wassermenge begrenzt. Nur dort wo der Druck zu
stark erhöht wird, dass Wasser eingefärbt, umgeleitet, etc wird,
wird sie tatsächlich verletzt. Sie dient der ungestörten Versorgung,
nicht einem, diesem Zweck zuwiderlaufenden bloßen Selbstzweck.<br>
<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite">
Inwiefern ergibt sich ein Schutz der Privatsphäre? (Außer, dass
ich geschützt bin, wenn ich keine Daten ins Internet schicken
kann...;-))<br>
</blockquote>
Scherzkeks ;-) Aber Du siehst das oben beschriebene Problem ;)<br>
Gemeint war Datenschutz versus Deep Packet Inspection, die im PPA
definitiv nicht zulässig wäre.<br>
<br>
Ich leite das aus<br>
<ul>
<li>Der Eigentümer bestätigt, freien Transit über seine freie
Netzwerkinfrastruktur anzubieten</li>
<li>Der Eigentümer bestätigt, die Daten, die seine freie
Netzwerkinfrastruktur passieren, weder störend zu
beeinträchtigen noch zu verändern.</li>
</ul>
her, auch, wenn so nicht dort steht.<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite"> <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>
</blockquote>
Was auch aufgrund von Fehlkonfigurationen nicht immer passiert.
Z.B.: Interface in der falschen Zone, Weiterleitung in der Zone auf
Drop, NAT auf externen Interfaces... diese Fehler treten häufiger
auf, als wir wahrhaben wollen und haben denselben störenden Effekt.<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite"> <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>
</blockquote>
Das ist illusorisch, solange man mit einfacheren Problem zu kämpfen
hat und das Know-How nicht beim User (nicht unbedingt Betreiber)
ankommt.<br>
Anytun als Ausweg?<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite"> 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>
</blockquote>
Das ist zu befürchten.<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite"> Gibt
es schon Überlegungen/Versuche, wie sich das auf die
Netzlast/-kapazität auswirken würde?<br>
</blockquote>
Im AP-Mode sehe ich keine prinzipiellen Probleme: Sonst würden die
auf eduroam basierenden Netze der Unis allesamt stehen - und soviele
Nutzer wie dort haben wir üblicherweise nicht pro AP.<br>
Zum Adhoc-Mode habe ich keine Erfahrungen - dass ich kein Fan des
"Nicht-Standards" Adhoc bin.<br>
Mich würde 802.11s weit mehr interessieren.<br>
<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite">
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>
</blockquote>
Das würde mich freuen. Ich werde es auch versuchen, zumindest am
Samstag da zu sein.<br>
<blockquote cite="mid:52545DDF.8070806@yahoo.de" type="cite"> <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>
</blockquote>
Firmware-Bugs und Vorschläge bitte auf trac.trac.wien.funkfeuer.at
posten.<br>
<br>
<br>
LG<br>
Erich<br>
</body>
</html>