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

[L. Aaron Kaplan]

Prinzipiell vorab: DNS Sperren (so wie ich sie kenne) sind *keine* gute Idee. 

Siehe auch: https://www.isc.org/blogs/blocking-dns/
(Wer Paul Vixie nicht kennt: das ist der Autor vom BIND nameserver, unter anderem)


On Oct 8, 2013, at 10:40 PM, "Erich N. Pekarek" <(spam-protected)> wrote:

> 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.
Umgekehrt kommen vielleicht 5% aller hier subscrib-ten zu den Testtagen.
Also ich finde das schon OK auf der Liste.

>> 
>> 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 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.

Wieso ist das illusorisch. end-to-end crypto ist der einzige Weg. Und damit musst du halt auch den layer 7 einbeziehen.
Martin hat da IMHO schon vollkommen recht.

> 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.

Welcome to the Cryptocalypse...
Das ganze ist wirklich mittlerweile eine ziemliche Tragoedie.

>> 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.

Letzteres skaliert nicht. Das wissen wir seit vielen Jahren schon.
Es ist vielleicht fuer ein lokales in der Wohnung-mesh gut. 


lg,
a.

(mit CC an die richtige security@ liste :) 
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 163 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20131009/180533e7/attachment.sig>