[Discuss] p2p-Filter (war: [wien] DNS sperre wegen skype - heute abend im Metalab)

Di Okt 8 22:40:07 CEST 2013

Hallo!

Am 2013-10-08 21:32, schrieb Martin Asmus:
> Hallo,
>
> da wir uns vom praktischen in den theoretischen Bereich bewegen, mal 
> auf discuss verschoben.
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.
>
> Am 08.10.2013 12:28, schrieb Erich N. Pekarek:
...
Lass mich trotzdem hier ein paar Punkte klarstellen:
>> ...
> 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)
> Er orientiert sich (soweit ich das beurteilen kann) weder an der 
> Auslastung des Knotens, noch an der "Bösartigkeit" der Verbindungen.
> Außerdem handelt es sich auch nicht um ein "last resort", das nur 
> benutzt wird, wenn der Knotenbetreiber nicht erreichbar ist.
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.
>> 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. 
> Und genau diesen freien Datenverkehr sehe ich hier beeinträchtigt.
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.
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.

> Inwiefern ergibt sich ein Schutz der Privatsphäre? (Außer, dass ich 
> geschützt bin, wenn ich keine Daten ins Internet schicken kann...;-))
Scherzkeks ;-) Aber Du siehst das oben beschriebene Problem ;)
Gemeint war Datenschutz versus Deep Packet Inspection, die im PPA 
definitiv nicht zulässig wäre.

Ich leite das aus

  * Der Eigentümer bestätigt, freien Transit über seine freie
    Netzwerkinfrastruktur anzubieten
  * Der Eigentümer bestätigt, die Daten, die seine freie
    Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen
    noch zu verändern.

her, auch, wenn so nicht dort steht.
>
>> (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. Die Deutschen diskutieren 
>> <http://www.heise.de/netze/meldung/Bundesnetzagentur-Anhoerung-zu-Zwangsroutern-1968755.html> 
>> gerade heftig über diese Unsitte.)
>> Ich will das in unserem Netz nicht, ...
> ack, das will hier, glaub ich, niemand.
> 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.
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.
>
>> 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.
> Soweit ich weiß, gab es da den Konsens Verschlüsselung auf höheren 
> Layern zu propagieren.
Das ist illusorisch, solange man mit einfacheren Problem zu kämpfen hat 
und das Know-How nicht beim User (nicht unbedingt Betreiber) ankommt.
Anytun als Ausweg?
> 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.
Das ist zu befürchten.
> Gibt es schon Überlegungen/Versuche, wie sich das auf die 
> Netzlast/-kapazität auswirken würde?
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.
Zum Adhoc-Mode habe ich keine Erfahrungen - dass ich kein Fan des 
"Nicht-Standards" Adhoc bin.
Mich würde 802.11s weit mehr interessieren.

> Allgemein ergeben sich damit viele neue Fragen und mögliche Probleme.
>
>> 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.
> Ich werd auf jeden Fall schauen, dass es sich ausgeht.
Das würde mich freuen. Ich werde es auch versuchen, zumindest am Samstag 
da zu sein.
>
> ...
> P.S. Vielleicht doch besser auf die Security-Liste? Nachdem security 
> vermutlich eine Teilmenge von discuss ist, belass ich´s mal auf discuss.
Firmware-Bugs und Vorschläge bitte auf trac.trac.wien.funkfeuer.at posten.

LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20131008/493bb072/attachment.htm>