Meshbird – distributed private networking
meshbird.com
meshbird.com
Glaring problems: - The same unchanging aes key is shared between all nodes on a network. Compromise one, compromise all. Additionally a bad node can impersonate any other node.
- The 96 bit nonce is derived randomly and there is no rekeying which means sending more than 2^32 messages will leak your (static, unchanging) key to the world. That's 2^32 total between all clients on a network. Hope everyone is manually updating their keys!
- Default unchanging password of `hello-world` is set. Everyone remembers to change that environment variable right?
- The KDF is md5, which means attackers can brute force guess the key incredibly fast.
- There's no perfect forward secrecy (aging out of old keys).
Summary: Stick to Wireguard!
Would be interested in hearing from Adam[2] the trade-offs between fully and partially decentralized architectures
> All traffic transmit directly to recepient peer without passing any gateways. Meshbird do not require any centralized servers.
means you can't have a NAT on both sides of connection. Zerotier falls back to proxying the traffic if you can't connect directly.
If not, please pardon my ignorance; not a networking expert.
1) They switched away from UDP, now use TCP. So NAT traversal / punching isn’t possible.
2) Even if UDP was used there’s still some network setups that aren’t traversal friendly, such as most cellular/LTE networks where port mappings are unpredictable.
> Similarly, adding port prediction to the P2PNAT approach allows it to handle symmetric NATs increasing its success rate to 84.3%
Interesting that it works, but doesn't seem very reliable.
Clients A and B connect to a rendezvous host. R looks at A and B's ports, guesses which ports they will use for the next connection and instructs them to connect to each other respectively. First SYN packets are lost, but they poke holes, so on the retry the symmetrical open kicks in and peers hook up into a shared TCP connection. The end.
From what I remember ingress TCP filtering was universally very dumb - if there was a SYN out, anything on the same quartet of IP/ports was allowed in. That was on a sample of several thousand devices, though most of these were of consumer grade. It was also few years before the paper you linked to above.
Re6st indeed is more focused on connectivity than performance because it re-establish connection even when the Chinese great firewall kicks in.
# Changelog
## v2.0
- removed DHT
[...]
- bootstraping and peer exchange from one or more nodesAlso, any idea the overhead in terms of CPU pushing around 100Mbps?
That seems alarming for a commit message.
There are scant details on the website as to _how_ it works. They don't appear to backup the claim that its "distributed"
Are they just using a DHT to distribute IP addresses, then use wireguard to connect? how is routing configured? is it dynamic.
All of the basics seem to require looking into the code, which seems a little obtuse
also, wget'ing a script direct into sh, not a healthy start. easy installers == great, but not when its piped directly into sh. Tar.gz and make it obvious that your not hiding stuff, and make sure you post a hash of the tar.
And it is a bit strange their English is mostly correct and then they make this mistake consistently. Maybe not a mistake?