openwrt
babled: using hmac in decentralized environments?
I'm very interested in MAC authentication for the Babel routing protocol. However, I'm unsure if I can apply some of the parts to a decentralized network like freifunk, where everyone can participate. The basic idea is that I want to exclude unknown members through mac authentication? How do your share a secret key between neighbors (can I automatize the process?)? Any idea how we can use it?
@aparcar @kerneis @jech @SvenRoederer @pmelange @spolack @Akira25
I've replied here:
https://www.mail-archive.com/[email protected]/msg00797.html
(Feel free to reply to the list without being subscribed, I'll whitelist your address.)
Thanks a lot! I subscribed to the mailing-list today. I need some time to respond.
a decentralized network like freifunk, where everyone can participate. The basic idea is that I want to exclude unknown members through mac authentication?
I just started a side-discussion at https://lists.freifunk.net/pipermail/wlantalk-freifunk.net/2021-June/001344.html on your general idea of excluding "unknown members" on the open decentralized Freifunk network. This intention seems to be conflicting with the spirit of Freifunk. But let's focus in this issue on the technical side.
@SvenRoederer wrote:
abgesehen vom technischen Aspekt einer solchen Implementierung stellt sich mir die Frage nach der Vereinbarkeit mit den Freifunk-prinzipien.
Right. Babel-MAC is an authentication mechanism. Out of the box, it can be used to implement static keying, but with suitable authentication and key distribution services, it could be used to implement a fairly wide range of policies.
It is possible that you guys are happy with your current unauthentified routing domain. If so, great. If not, then we can think together about (1) what security properties would enhance your network, (2) what security policies could be used to guarantee these properties, and (3) how best to implement the policies.
It is possible that you guys are happy with your current unauthentified routing domain. If so, great. If not, then we can think together about (1) what security properties would enhance your network, (2) what security policies could be used to guarantee these properties, and (3) how best to implement the policies.
That is exactly what I hoped for that we could work together to make mesh networking better. In particular, we are rolling out babeld over some parts of freifunk berlin. So far babeld is working very well! I'm not that happy that a potential attacker could attack our network.
However, I invested much of my free time currently becoming OLSR maintainer and fixing some important compiling and OpenWrt-specific things. OLSR codebase is huge and I would say it is not that easy because of all platforms that they support. Currently, I struggle with making a new release because of all the java bindings and android support. I do not receive feedback from the community if I can drop these platforms.
I would like to invest more of my time working on some more future proven project. That is why I would be happy to team up with you.
I have many open questions:
- What metrics are good for monitoring purposes? (I will soon write some collectd plugin)
- Can we distribute(flood) hostnames, or use a DHT, or DNS based approach
- Layer-3 Roaming [0], [1]
- Wireless-Mesh-Extensions
- Plugins
- Whatever...
I currently invest my free time in this project, so please forgive me that I need some time to answer on your mailing list. ;) I want to have a look at how b.m.x. is doing their crypto stuff and that my e-mail might consider more useful information.
Thanks for your very good maintenance, documentation and help. I really enjoy developing for babeld and using it.
However, I invested much of my free time currently becoming OLSR maintainer
Congratulations!
- What metrics are good for monitoring purposes?
Off the top of my head:
- The amount of time a prefix is marked as unreachable
Self-explanatory.
- The amount of time a route is available but the destination cannot be pinged
If it's large, then the link-quality estimator is too slow.
- The cost of neighbours through which a selected route goes.
If you have a bad neighbour, that's okay if Babel can find a path around it. On the other hand, if a selected route goes through a bad neighbour, then it means that Babel couldn't find a better neighbour, and your network is probably not dense enough.
- The number of route flaps
If Babel is flapping (switching between two routes to the same prefix), then it needs more hysteresis
- Can we distribute(flood) hostnames, or use a DHT, or DNS based approach
The IETF solution for flooding is HNCP,
https://datatracker.ietf.org/doc/html/rfc7788 https://openwrt.org/docs/guide-user/network/zeroconfig/hncp_configuration https://github.com/sbyx/hnetd https://github.com/jech/shncpd
It works reasonably well on small mesh networks:
https://datatracker.ietf.org/meeting/96/materials/slides-96-homenet-1
We could probably design something similar for large, unstable meshes.
- Layer-3 Roaming 0, 1
I'm working on it:
git clone https://www.irif.fr/~jch/software/sroamd.git
- Wireless-Mesh-Extensions
Not my area of expertise, sorry.
- Plugins
There are no plugins in babeld. If you implement extra features, you should aim for getting them committed into mainline rather than losing time maintaining a separate plugin.
I really enjoy developing for babeld and using it.
Thanks for the kind words :-)
HMAC is not yet implemented in UCI either, is it? https://github.com/openwrt/routing/blob/master/babeld/files/babeld.init https://alioth-lists.debian.net/pipermail/babel-users/2021-June/003827.html
Would a configuration like the following work?
config general
option default_key "mydefaultkey"
config interface
option ifname "eth1"
option key "myotherkey"
config key
option name "mydefaultkey"
option type "hmac-sha256"
option value "fe3c..."
config key
option name "myotherkey"
option type "hmac-sha256"
option value "fe3c..."
