Reclaim Your Mesh – Self-paced Networking in Multilateral Environments
Axel Neumann
International Summit for Community Wireless Networks (IS4CWN) 2013, Berlin
October 3, 2013
www.bmx6.net www.qmp.cat
Outline
1
Introduction (What?)
Community Mesh Networks
2
BMX6 Approach (How?)
Background and Objectives Protocol Principles
3
Advantages and Outcome (Why BMX6?)
Advantages
4
Secure Routing in Open Networks (Whats Next?)
Problem: Open versus Secure
User-Defined Trust Policies (Routing via Trusted Nodes)
Community Mesh Networks
Structure
open, decentralized, neutral heterogeneous
cooperative
Growing and restructuring
Coordinated (consensus) Organically (individually)
Scalability challenges
Overhead:
More nodes, larger IPs (v4 -> v6) HW heterogeneity ([Kb..Gb])
Human diversity:
Character (trust)
Preference (services, routing: fast vers. reliable)
Community Mesh Networks
Structure
open, decentralized, neutral heterogeneous
cooperative
Growing and restructuring
Coordinated (consensus) Organically (individually)
Scalability challenges
Overhead:
More nodes, larger IPs (v4 -> v6) HW heterogeneity ([Kb..Gb])
Human diversity:
Character (trust)
Preference (services, routing: fast vers. reliable)
Community Mesh Networks
Structure
open, decentralized, neutral heterogeneous
cooperative
Growing and restructuring
Coordinated (consensus) Organically (individually)
Scalability challenges
Overhead:
More nodes, larger IPs (v4 -> v6) HW heterogeneity ([Kb..Gb])
Human diversity:
Character (trust)
Preference (services, routing: fast vers. reliable)
Background and Objectives
B.A.T.M.A.N.
, started July 2006
BatMan-eXperimental (BMX)
, gradually diverged to
independent project, protocol, code, users,...
BMX6
, first release during WBMv3, June 2010
Today: Productively used (eg.
qMp
[1])
BMX6 Design Objectives:
IPv6: Exploit capabilities, cope with address size Cope with HW diversity and nodes
Scale with increasing diversity of users
Failure robustness (misconfiguration, IP collisions, attacks?) Be user centric (power to the people) without disrupting cooperation
How: Learn from social networks
Scale to millions, despite huge diversity
Protocol Principles [2,3,4]
Seperate node attributes and IDs
Traditionally ID given by IPs (Babel)
Attributes (static)
DESCRIPTION (node profile) Networks, names, services, metrics, ...
Flooded once & globally Public knowledge
Node discovery before path discovery
IDs reference node attributes
Context-specific ID types
Description hashes (160bit RSA): -> globally unambiguous
Internal IDs (16bit):
-> locally unambiguous, short! Used for routing updates (4 bytes)
Protocol Principles [2,3,4]
Seperate node attributes and IDs
Traditionally ID given by IPs (Babel)
Attributes (static)
DESCRIPTION (node profile) Networks, names, services, metrics, ...
Flooded once & globally Public knowledge
Node discovery before path discovery
IDs reference node attributes
Context-specific ID types
Description hashes (160bit RSA): -> globally unambiguous
Internal IDs (16bit):
-> locally unambiguous, short! Used for routing updates (4 bytes)
Advantage I: Overhead
Node and neighbor discovery expensive but transient Path discovery/maintenance continuous but cheap [4,5]
4-bytes routing updates (IID + metric value + sequence#) Overhead: approx. 1 byte / node / neighbor / second
Master Thesis from Glenn Daneels, “Analysis of the BMX6 routing protocol” [4]:
0 100000 200000 300000 400000 500000 600000 700000 0 20 40 60 80 100 Over head (Bps) Time (s)
Overhead (Bps) per second (100 seconds, topology size 100) BMX6 Grid BMX6 Topology OLSR Grid OLSR Topology
Advantage I: Overhead
Node and neighbor discovery expensive but transient Path discovery/maintenance continuous but cheap [4,5]
4-bytes routing updates (IID + metric value + sequence#) Overhead: approx. 1 byte / node / neighbor / second
Master Thesis from Glenn Daneels, “Analysis of the BMX6 routing protocol” [4]:
0 50000 100000 150000 200000 250000 300000 350000 400000 450000 0 20 40 60 80 100 Over head (Bps) Topology size Steady state (100 seconds)
Steady state BMX6 Grid Steady state OLSR Grid Steady state BMX6 Topology Steady state OLSR Topology
Advantage I: Overhead
Node and neighbor discovery expensive but transient Path discovery/maintenance continuous but cheap [4,5]
4-bytes routing updates (IID + metric value + sequence#) Overhead: approx. 1 byte / node / neighbor / second
Real-life overhead trace from Wireless Community Weekend 2013, Berlin [6] One node moving around, approx 20-nodes temporary mesh deployment
Advantages II: User-controlled routing (choose how)
Description contains routing-metric algo:
Defaults: 0.5s-link probes, 5s-routing update, ETX-like metric
Performance analysis from Wireless Battle Mesh WBMv6, 2013 [7], (work in progress) 25 ping tests between stationary nodes:
1 5 10 50 500 5000 0.0 0.2 0.4 0.6 0.8 1.0
round tip time (RTT) [ms]
ECDF 0.0 0.2 0.4 0.6 0.8 1.0 ● ● ● ● ECDF babel batadv bmx6 olsr
succused expect rcvd babel 18879 19366 25000 26116 batadv 18889 18971 25000 25123 bmx6 21216 21383 25000 24900 olsr 21381 21596 25000 25326 groups=5,6,7,8,9,10,13,15,17,18,19,23,24,25,26,27,28,30,32,34,35,36,37,38,39 10 100 1000 babel 50 67 74 batadv 46 71 74 bmx6 69 82 84 olsr 74 84 85 proportion [%] <= RTT
3 netperf TCP throughput tests between stationary nodes in [Kbits/second]:
Protocol test1 test2 test3 avg
babel 831 836 827 831
batadv 833 990 403 742
bmx6 2695 2708 1980 2461
olsr 2918 3647 1867 2810
Note correlation between ECDF for 10ms RTT and avg TP
Advantage III: Overlay Networking (choose what)
Description publishes tunnel endpoints to networks
Traffic routed via user-controlled overlay network Using Linux-Kernel tunnel: Fast!!!
Flexible tunnel offering and routes redistribution
tunIn=myself /n=10.6.1.17/28 /b=10M
redistTable=homeNets /table=123 /b=100M /kernel=1 redistribute=nbCloud /n=10.1.0.0/16 /b=10M /olsr=1
Flexible tunnel selection policies
Destination specific GWs (private, cloud)
tunOut=peter /n=192.168.9.0/24 /hostname=peter tunOut=myCloud /n=10.6.0.0/16 /minPrefixLen=26
Zebra/Quagga support (export other community clouds)
tunOut=community /n=10.0.0.0/8 /maxPrefixLen=16 /bgp=1
No undesired internet-GW switching
tunOut=inet /n=0.0.0.0/0 /maxPrefixLen=0 /hysteresis=50
Preference driven GW selection (encounter IP hijacking)
tunOut=inet /n=0.0.0.0/0 /maxPrefixLen=0 /name=ffGW /bonus=100
Advantages IV: Self-configuration & Failure Recovery
Configuration:
Minimal configuration requires only interface
Auto-configured primary address (ULA-IPv6 based, similar to EUI64) – immediate reachability
Unambiguous end-to-end routing (NOT anycast/anywhere) Also description hash re-usable as primary IP (routing)
Failure Recovery:
Allocation conflicts solved context specific
Eg: DAD solved by dropping conflicting routing updates NOT affecting overall network, just conflicting nodes!!!
Misbehaving nodes are isolated locally
Illegal node descriptions are dropped
Problem: Open versus Secure
Existing end2end sec (ssl, vpn) rely on functioning routing
Routing security by exclusion (shared key) is NO solution!
Contradicts openness
Public secret soon, hard to control or update Controversy between key-holders remains
Clear rules are nice. But global compliance questionable!
Think of hitchhikers dilemma:
Society consensus: Do not threaten others ? Young lady worries sweating older man (despite well dressed)
Others afraid of punks offering a lift
Security driven by trust, not by law (rules of consensus)
Society approach:
Don’t exclude (criminalize) anybody But allow individuals to discard offers Lets try the same for routing...
User-Controlled Routing via Trusted Nodes: Goal
Anarchist and Hippie distrust Spy
Data to-be routed around
Bourgeois appealed by
NSA-sponsored high-speed links
Data to-be routed straight Helps Anarchist despite distrust
User-Controlled Routing via Trusted Nodes: Approach
Extend BMX6 description to publish
each node’s
PubKey
Trust set (other node’s pubKeys) Signature: ensure authenticity) Remember: Descriptions propagated globally
New rules:
pubKeys+signature to setup symmetric link encryption:
Authenticate routing updates from NB’s
Only process routing updates from X via NB if NB trusted by X!
-> Forwarding path (next hops) to X only via trusted nodes
References:
1 L. Cerdà-Alabern, A. Neumann, and P. Escrich,Experimental Evaluation of a Wireless Community Mesh Network, acceppted for 16th ACM/IEEE InternationalConferenceon Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM 2013), Barcelona/Spain
2 A. Neumann, E. López, and L. Navarro,An evaluation of BMX6 for community wireless networks, 1st International Workshop on Community Networks and Bottom-up-Broadband (IEEE CNBuB 2012), Barcelona/Spain
3 A. Neumann, L. Navarro, P. Escrich, and R. Baig,Receiver-driven routing for community mesh networks, 5th International Workshop on Hot Topics in Mesh Networking (IEEE HotMesh 2013), Madrid/Spain
4 Glenn Daneels,Analysis of the BMX6 routing protocol, Master thesis at University of Antwerp, Department Mathematics-Computer Science, 2012-2013
5 Roger Baig Viñas,Evaluation of Dynamic Routing Protocols on Realistic Wireless Topologies, Master Thesis at Universitat Autònoma de Barcelona, Department de Telecomunicació i D’Enginyeria De Sistemes, June 2013
6 Wireless Community Weekend, 2013, Berlin, http://wiki.freifunk.net/Wireless_Community_Weekend_2013 7 Wireless Battle Mesh version 6 (http://battlemesh.org/BattleMeshV6), Mailing list Subject:[Battlemesh]
Battlemesh v6 conclusions, Online: http://ml.ninux.org/pipermail/battlemesh/2013-July/002488.html
Thanks!
Questions...?
Checkout www.bmx6.net