On Sun, Oct 28, 2018 at 1:52 AM Antonin Décimo <[email protected]> wrote: > > Hello Dave, > > There's also my dtls branch. > https://github.com/MisterDA/babeld/tree/unicast-dtls > > It requires some cleanups, updates to the latest draft, and > harmonisation with the hmac branch, but I'm confident we'll eventually > get there.
cool. What's your intended deployment model? One of my issues with crypto, rather than auth, is I'd wanted a way to have a partially untrusted network to bootstrap off of and/or to allow at least some unauthed or uncrypted nodes to participate with filters or inflated metrics. You bring a new node up. It needs to get on the network long enough to at least get a route to somewhere that has the configuration info you need to stick into it. Being "stubby" is almost enough (unless you are trying to come up as a p2p interface) - which will work with hmac auth nodes - a default route to the internet is all you need to (for example) install essential updates and tools, but being able to express that you'd like a couple unprotected routes to exist is a difficult problem As another example, I'd like to share part of my ipv6 source specific space with the meshy universe, but not allow anyone further access inside my network, or allow anyone in attempting to use or spoof part of the rest of the space in it at all. (simple example, I filter out nearly all announcements of normal ipv4 address space, so 8.8.8.8 can't be spoofed, and I used to filter out anything outside of comcast's ASN as that's the only public IPv6 space I have (used to just limit it to my dedicated hurricane tunnel), and certainly filter out their dns server ipv6 addrs also) It would be good to be able to log certain forms of possible malfeasance... (this is partially equivalent to the BGP path validation problem, and basically, in running any network larger than a few people, all the social and technical problems that happen in the "big" Net, start happening here.) After that, things get hairier. I really don't "get" the tunneldigger/wlan-slovenia and other efforts that make things even more complicated. It seems like the first thing anybody does upon designing a mesh network is overlay a link state set of tools and tunnels over it to capture statistics and control information. Is that an artifact of the OLSR deployments or control freakery? My own paranoia about partially trustable networks (like wanting to have big bogon filters at my gateways at least - and maybe even APs) come from many scars of running a rather public network with a ton of visitors that never heard of anti-virus software. the openwrt bcp38 package is really helpful when someone starts ping -f the universe... Me, I run ssl/ssh and ssh port forward enabled tools, and have *one* dedicated collection point for statistics that I can export to the world as I see fit, and normally, any given view of my network comes down to a few dozen routes, tops. I don't want to know about any of the churn elsewhere. I have a whole /56 from linode I should go use up somehow.... A pending use for a tunnel is on my default gws where I might attempt a wireguard fallback route for the whole net (172.20.0.0/14), after I retire that cerowrt box. and at some point (currently about 4k routes), you run out of bandwidth, or cpu, or memory. On this go-round of my deployment I've disabled every last extra daemon that I used to run (dnsmasq, netperf, uhttpd, odhcpd, and I'm probably giving up on snmp in favor of just using smokeping. I used to use xnetd for some things. Superservers still make sense when you only have ~6MB of memory that is better off used for packets and routes). And it really pays to have the bare minimum number of exported routes to any other zone in your network. > > > Happy hacking, > > -- Antonin > > _______________________________________________ > Babel-users mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
