[Babel-users] 57 forks of babel on github

[Dave Taht]

On Sun, Oct 28, 2018 at 1:52 AM Antonin Décimo <antonin.decimo at gmail.com> 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
> Babel-users at alioth-lists.debian.net
> 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