Rheinland Backbone Documents and Policies


#1

Das Projekt Rheinland Backbone haben wir mit der Zielsetzung begonnen alle Freifunk Communities die möchten darüber ins Internet zu bringen. Damit gemäß rechtlicher Vorgaben und gerecht für alle Communities einheitlich umgesetzt werden kann möchten wir eine Reihe von Dokumenten herausgeben. Dort wird festgehalten für wen wir das tun mit welcher technischer Umsetzung das geschieht und wie die daraus entstehenden Pflichten wahrgenommen werden.

Im wesentlichen handelt es sich hier um eine Erweiterung des Pico Peering Agreement, eine Datenschutzerklärung und eine Erklärung der Sicherheitsrichtlinien der Bundesnetzagentur. Im Folgenden findet Ihr Stichpunkte die wir uns dazu überlegt haben aus denen die genannten Dokumente entstehen werden.

Die Stichpunkte sind in Englisch fomuliert um uns mit anderen Organisationen insbesondere beim Chaos Communication Congress in zwei Wochen drabüber austauschen zu können.

Heute haben wir bei der Vorstandssitzung die Punkte soweit für ok befunden und stellen sie hier der Community für Feedback vor. Nach dem Congress werden die Dokumente veröffentlicht, die auf Basis der bis dahin entwickelten Version entstanden sind.

Policy Documentation - Rheinland Backbone
This document collects our five different policy sets, concerning administrators and operation of the Rheinland Backbone, courtesy of Freifunk Rheinland e.V.

Purpose

Rheinland Backbone is a transit network. Its purpose is the connection of any access network in the Freifunk Community to the public Internet. Connectivity of the clients is established over IPv4 and IPv6.

Technical Overview

Communities are allocated with a single IPv6 subnet and an IPv4 address (at least 2) for each of their routers (e.g. supernodes). IPv6 connectivity will be native, end-to-end. Due to global IP address exhaustion, it is necessary for the community to assign clients with private IPv4 addresses and use NAT technique for routing into other networks. The Backbone Network does not apply any encryption on traffic routed to or from the internet.

Definitions

Community: Community in relation to this document is defined as group of people who operate a seperate network infrastructure. In some cases this might by a group of people who share a common network infrastructure (meta communities).

Operator: A operator is each person who operates (does have root account) communities systems which are connected the the backbone infrastrucutre.

User: A user is considered a person who connects to infrastructure which is provided by a local Freifunk community.

Global Terms

  • A Freifunk community is considered a group of people who accept and implement the pico peering agreement
  • Each Freifunk community is given Backbone transit based on Rheinland Backbone Policy acceptance
    Communities must delegate operation of the backbone connection to designated operators. This should be at least two people.
  • Each connected community should mention this service and advertise for donations in a way that they deem appropriate
  • No charge must ever be applied for the usage of this service
  • The service is not intended to place or distribute any kind of advertisement
  • The provided service connects to public networks. Every user must take care of his own encryption and security matters
  • Data-protection is considered as important and the infrastructure more than fully complies with local data protection laws
  • No one must use the network to harm the freedom of others
  • No policy rule must be violated to satisfy the need of another rule

Routing Policy

  • IPv4 is considered a legacy protocol, but will be supported as transition mechanism for an undefined period of time
  • Internal and external peerings are either IPv6 only or support both IPv4 and IPv6
  • Net neutrality: every type of packet is treated equally in regard to priority, bandwidth and latency
  • quality of service cannot be as network feature
  • The Rheinland Backbone don’t support censorship or filtering of any kind and will act against requests to implement such things. - It will announce censorship and surveillance measures applied (e.g. out of legal reasons) when possible.

Service Level Agreement

  • No formally formally defined support response times are provided
  • Services are provided on best effort basis
  • Community’s operators should cooperate for solving issues

Operations Level Agreement

  • Abuse-notifications are accepted and distributed via a ticket system
  • Operators should target to handle assigned abuse requests in a timeframe of 24h
  • A contracted lawyer should be reachable at any time
  • Abuse must be treated according to the abuse treatment policy
  • All operators must act according to the administration policy

Administration Policy

  • Don’t spy on or collect user’s traffic without a technical reason
  • Collected logs must be deleted after a finished troubleshooting session
  • No user information gathered during a debug session should be disclosed at any time
  • User traffic must only be manipulated to make connectivity possible
  • Logging volume and scope should be as minimal as possible
  • Captive portals must not be used to gateway network access
  • Every delegated operator must take action against threats inside the community’s network if possible

Abuse Treatment Policy

  • Requests by state authority should be handled by a lawyer
  • Criminal prosecution with lawful enforcement will not be hindered by Rheinland Backbone
  • Each abuse-case is handled seriously
  • Each abuse-case is tried to be answered faithfully within 48 hours
  • If possible we are going to take action against each occurrence
  • The Rheinland Backbone is not able to provied any information about the end user

List of open Issues

  • Should there be a obligation for communities to announce changes? If, which changes?

  • Should there be a requirement for reachablility of community operators?

  • Should there by any cirteria for a decision if a community will get connected?

  • What should be the process of resolving conflicts? What are possible actions for violations/conflicts?


Einbindung neuer Communities / transparenz von Richtlinien & Protokollen
Freifunker mit geschäftlichem Hintergrund
Welche Daten werden geloggt?
Intercity-Verbindung und Backbone
Fragen zur Anonymität des Knotenbetreibers
Abwägung von Datenschutzansprüchen mit Knoten-Selbstauskunft
Technische Umsetzung Freifunk im NRW-Wirtschaftministerium
Technische Umsetzung Freifunk im NRW-Wirtschaftministerium
Splash Screen / Captive Portal in Firmware
Technische Umsetzung Freifunk im NRW-Wirtschaftministerium
Welche Daten werden geloggt?
Projekt Provider werden
Einbindung neuer Communities / transparenz von Richtlinien & Protokollen
Einbindung neuer Communities / transparenz von Richtlinien & Protokollen
Einbindung neuer Communities / transparenz von Richtlinien & Protokollen
Einbindung neuer Communities / transparenz von Richtlinien & Protokollen
Einbindung neuer Communities / transparenz von Richtlinien & Protokollen
Welche Daten werden geloggt?
Splash Screen / Captive Portal in Firmware
#3

Hi Thomas,

zwei Fragen zu den sehr schönen Grundlagen:

“Community” im Sinne der Policy… ist was ?
Wir Kempener verstehen uns als Community - hängen aber an der Domäne Ruhrgebiet. (Sinigerweise). Ich vermute es wäre sinnvoll einen Annex mit Definitionen zu formulieren.

“•Requests by state authority should be handled by a lawyer” - würde Ich so verstehen: Der Backbone macht es, aber von den Communities (…die am Backbone hängen, siehe Definitionsfrage) sollten dem folgen. Der empfehlende Charakter ist gewollt ?

LG
Ralf


#4

Hi Ralf,
ich habe die Definition Community hinzugefügt.

Die Empfehlung ist so gewollt weil es ja Fälle geben kann in denen keine Rücksprache erforderlich ist. Das beschreibt halt eher eine interne Vorgehensweise des Backbone Teams.

Grüße
Thomas


#5

Moin!

Wenns um Deutsches Recht geht sollten Texte auch in Deutsch, zumindestens übersetzt werden. Denn Englisch ist bei uns, Gott sei Dank, keine Amtssprache.


#6

No shit, Sherlock! :slight_smile:


#7

Da diese Policy ja anscheinend noch nicht fertig ist habe ich noch einen Zusatz der wichtig ist.
Bin mir nicht sicher ob es zu Routing Policy oder Operation Level Agreement gehört, ich denke ein wenig von beidem:

  • Every additional network the community provides connectivity for has to be announced to the backbone administrative team. Networks which get connected without doing so will result in a shut down of the connectivity to the backbone. This also involves splitting of meta-communities into its own collision domains.

Einbindung neuer Communities / transparenz von Richtlinien & Protokollen
#8

Zusätzlich noch:

  • The administrative team may deny connectivity requests if one or more of the following criteria are met
  • The community intersects with one or more communities which are already connected to the FFRL backbone and still have enough capacity.
  • The community has no dedicated administrative team. Every community which requests access to the backbone is needed to have at least 2 administrators in case one of them is not reachable

#9

Ab wann gibt es die Sachen auf Deutsch? Bin mir nicht sicher ob ich die Texte richtig verstehe.


#10

Quick’n’Dirty powered by Google Translate

Politik Dokumentation - Rheinland-Backbone
Dieses Dokument erhebt unsere fünf verschiedenen Maßnahmengruppen, über die Administratoren und Betrieb des Rheinland-Backbone, mit freundlicher Genehmigung von Freifunk Rheinland eV

Zweck

Rheinland-Backbone ist ein Transitnetzwerk. Sein Zweck ist die Verbindung eines Zugangsnetzwerk in der Freifunk-Gemeinschaft mit dem öffentlichen Internet. Connectivity der Clients ist über IPv4 und IPv6 etabliert.

technische Übersicht

Gemeinschaften mit einer einzelnen IPv6 Subnetz und eine IPv4-Adresse (mindestens 2) für jede ihrer Router (zB Superknoten) zugewiesen. IPv6-Konnektivität wird nativen, Ende-zu-Ende. Durch die globale IP-Adresse Erschöpfung, ist es erforderlich, dass die Gemeinschaft, um Kunden mit privaten IPv4-Adressen zuweisen und NAT-Technik für die Weiterleitung in andere Netze. Die Backbone-Netzwerk keine Verschlüsselung auf den Verkehr von oder aus dem Internet weitergeleitet anzuwenden.

Begriffsbestimmungen

Gemeinschaft: Gemeinschaft in Bezug auf dieses Dokument wird als Gruppe von Menschen, die einen separaten Netzwerkinfrastruktur zu betreiben festgelegt. In einigen Fällen ist diese Macht von einer Gruppe von Menschen, die einen gemeinsamen Netzwerkinfrastruktur (meta Gemeinden) zu teilen.

globale Geschäfts

  • Ein Freifunk-Community wird als eine Gruppe von Menschen, die zu akzeptieren und umzusetzen Pico Peering-Vereinbarung
  • Jeder Freifunk-Community gegeben Backbone Fuhr Rheinland Backbone-Politik Akzeptanz basiert
  • Gemeinschaften müssen den Betrieb der Backbone-Verbindung, um die benannten Betreiber übertragen. Dies sollte mindestens zwei Menschen.
  • Jede angeschlossene Community sollte diesen Service erwähnen und um Spenden werben in einer Weise, die sie für geeignet halten
  • Es darf unter keinen Umständen eine Gebühr für die Nutzung dieses Dienstes erhoben werden
  • Der Service ist nicht beabsichtigt, um irgendeine Art von Werbung zu platzieren oder zu verteilen
  • Die zur Verfügung gestellten Service eine Verbindung zu öffentlichen Netzen. Jeder Benutzer muss darauf seine eigene Verschlüsselung und Sicherheit verfügen, anzu
  • Wir betrachten den Datenschutz so wichtig und erfüllen mehr als komplett die örtlichen Datenschutzgesetze
  • Niemand darf das Netzwerk in einer Weise nutzen, welche der Freiheit der anderen schadet
  • Keine Richtlinienregel darf verletzt werden, um die Notwendigkeit einer anderen Regel zu erfüllen

Routing Policy

  • IPv4 wird als ein altes Protokoll angesehen, wird aber als Übergangsmechanismus für einen unbestimmten Zeitraum unterstützt werden
  • Interne und externe Peerings sind entweder nur IPv6 oder unterstützt IPv4 und IPv6
  • Netzneutralität: jede Art von Paket wird gleich in Bezug auf Priorität, Bandbreite und Latenz behandelt
  • Wir sind nicht in der Lage, QOS als Netzwerkfunktion bereitstellen
  • Wir unterstützen keine Zensur und Filterung jeder Art und werden gegen Übertragungsanträge um solche Dinge zu implementieren vorgehen. - Wir werden Zensur und angewendeten Überwachungsmaßnahmen (aus rechtlichen Gründen zum Beispiel) geben bekannt, wenn möglich.

Service Level Agreement

  • Wir bieten keine formal definiert Reaktionszeiten
  • Dienstleistungen werden basieren auf Best-Effort-Basis zur Verfügung gestellt
  • Admins der Communities sollten zur Lösung von Fragen zusammenarbeiten

Operationen Level Agreement

  • Abuse-Meldungen werden akzeptiert und über einen Ticket-System verteilt
  • Die Betreiber sollten gezielt zugeordnet Abuse Anfragen in einem Zeitraum von 24 Stunden behandeln
  • Ein Anwalt sollte jederzeit erreichbar sein
  • Missbrauch muss entsprechend der Abuse Behandlungs Richtlinie behandelt werden
  • Jeder Community Admin muss sich entsprechende der Verwaltungsbestimmungen verhalten

Verwaltungsbestimmungen

  • Sie spionieren nicht auf oder sammeln Verkehrs Benutzer ohne technischen Grund
  • Gesammelte Protokolle müssen nach einer fertigen Fehlerbehebungssitzung gelöscht werden
  • Benutzerverkehr darf nur manipuliert werden um einwandfreie Konnektivität zu ermöglichen
  • Protokoll-Volumen und Umfang sollte so gering wie möglich sein,
  • Captive Portals dürfen nicht als Eingangstür für den Netzwerk-Zugriff verwendet werden
  • Jeder delegiert Community Admin muss gegen Bedrohungen innerhalb des Community Netzwerks wenn möglich vorgehen

Abuse Treatment Politik

  • Rückfragen von Staatsgewalt sollte durch einen Anwalt abgewickelt werden
  • Wir haben keine Strafverfolgung mit rechtmäßigen Durchsetzung behindern
  • Wir nehmen jeden Missbrauch-Fall ernst
  • Wir werden versuchen, jeden Missbrauch-Fall treu innerhalb von 48 Stunden zu beantworten
  • Wenn möglich, werden wir Maßnahmen gegen jedes Auftreten nehmen
  • Wir sind nicht in der Lage, alle Informationen über den Endnutzer bereitzustellen

Welche Daten werden geloggt?
Gibt es die möglichkeit, ein individuelles Captive Portal zu bauen?
Splash Screen / Captive Portal in Firmware
#11

Danke, diesen Dienst den Google da anbietet kenne ich auch. Nur ist es keine Grundlage worauf eine Diskussion aufgebaut werden kann und alle Vereinsmitglieder können sich deswegen nicht dran beteiligen.


#12

Darum habe ich die Übersetzung ja schon auf grobe Fehler untersucht :wink:


#13

Ich habe das Gefühl das die Namen der Entitäten noch durchgängig benannt werden könnten. Community ist definiert.
Undefiniert und damit missverständlich sind wie ich finde “We”, “Operator”, “User”, Auch wenn es dadurch etwas sperriger wird möchte ich vorschlagen die jeweils handelnde Entität immer explizit zu nennen.


#14

Wie hier schon mehrfach angesprochen wurde, wünsche ich mir die Diskussion über die Richtlinie auf Deutsch.

Meiner Meinung nach sollte ein Zeitfenster festgelegt werden, in dem die Meinung der Vereinsmitglieder zu einzelnen Punkten vorgetragen werden kann.

Kann man schon so machen, allerdings spielt hier die Vereinsarbeit und ich hoffe, dass es noch ausreichend Zeit geben wird, auf einzelne Punkte einzugehen, die vorher auf Deutsch richtig formuliert wurden. Es kann nicht sein, dass hier eine Sprachbarire eingebaut wird, die die Vereinsarbeit erschwert und es danach nicht ein mal Zeit geben wird darüber auf Deutsch zu reden.


#15

Es muss dringend noch ein klarer Hinweis aufgenommen werden, dass die Konnektivität bei Verstößen gegen die Policy bis auf Weiteres eingestellt wird.

Öfter habe ich sogar schon die Formulierung gelesen “jederzeit und ohne Angabe von Gründen”, aber im Falle von Verstößen sollte aus meiner Sicht ausreichend vorwarnen.

Darüber hinaus noch die besprochene Passage, dass das Backbone nicht kommerziell genutzt werden darf.


#16

Wobei wir dann wohl “kommerziell” auch definieren sollten.

Siehe die leidige Diskussion um Kneipe und Freifunk. Wenn die Kneipe Freifunk wegen Freifunkförderung hinstellt, alles gut. Wenn sie es zur Umsatzförderung als Werbemittel sieht, ist das nach gängiger Rechtssicht kommerziell.

Ich denke, das wird bei Zusammenarbeit mit z.B. Stadtwerbegeselschaften etc schnell ein Thema.

Glücklicherweise haben wir das Thema spalsh Screen (kann Ich da mal meine Getränkeliste verlinken…) erledigt.


#17

Andere Anmerkung - auf Basis einer Diskussion hier im Forum.

Wie halten wir es eigentlich so als Provider mit der Verschwiegenheitspflicht ?

“Den bei der Datenverarbeitung beschäftigten Personen ist untersagt, personenbezogene Daten unbefugt zu erheben, zu verarbeiten oder zu nutzen (Datengeheimnis). Diese Personen sind, soweit sie bei nicht-öffentlichen Stellen beschäftigt werden, bei der Aufnahme ihrer Tätigkeit auf das Datengeheimnis zu verpflichten. Das Datengeheimnis besteht auch nach Beendigung ihrer Tätigkeit fort.” § 5 BDSG

“beschäftigt” beschränkt sich ja nicht auf gegen Vergütung. Ein jeder der Daten einsehen KANN ist hier im Scope. Das muss m.E. der Provider top-down sicherstellen, wenn ihn kein Organisationsverschulden treffen soll.

Im Umkehrschluss ist es die Versicherung für diejenigen, die natürlich als betrieblichen Gründen mal in Datenströme reinschauen müssen.


#18

Ich schlage vor, dass nur auf Anweisung und Rücksprache in Datenströme geschaut werden kann und dies mit Datum, Unterschrift und Grund protokolliert wird. Ich handhabe das im Augenblick so: Ich tue es erst gar nicht.


#19

Hi @vax,

danke für dein Feedback. Ich habe nun Definitionen für die Begriffe eingefügt und die generellen “We” Statemens die sich auf den Rheinland Backbone beziehen ins passiv gesetzt.

Grüße
Thomas


#20

@rahuelsm das sollten wir als Thema in das nächste Vorstandstreffen mitnehmen. Ich sehe das so, dass es niemandem Schaden kann sowas zu unterscheiden weil ohnehin jeder danach handeln sollte.

Ich habe diesen Grundsatz jetzt mal mit aufgenommen.

  • No user information gathered during a debug session should be disclosed at any time

#21

Wie ich in der Einleitung geschrieben haben ist die Wahl der Sprache nicht dazu genutzt worden eine Barriere aufzubauen die Menschen daran hindert mitzudiskutieren. Sie soll im Gegenteil uns es ermöglichen Feedback aus anderen Communities wie z.B. Spanien, Frankreich ect. einzuholen. Das ist aus meiner Sicht ein großer Zugewinn in einem frühen Stadium der Entwicklung unserer Policy.

Bitte versuche doch an der Diskussion teilzunehmen. Es verübelt Dir niemand, wenn du Verständnisfragen zu einzlenen Punkten der Policy stellst.
Die Übersetzung wenn auch mit der Hilfe von Google ist mit Sicherheit in der Lage an >80% Verständnis aller Punkte heran zu kommen.

Ich fände es gut, wenn sich jeder darauf einlassen würde die Diskussion auf dieser Basis zu führen. Die Intention besteht nicht darin irgendjemanden auszuschließen.