I started using yggdrasil yesterday. The ability to get a static IPv6 address on a meshnet, with encrypted traffic by default, and the option to only accept inbound connections from public keys I trust is incredibly cool. Just like that I can access any of my devices that run ygg from anywhere using standard tools like git or ssh (or git-annex). It makes it really easy to network my devices together without having to screw around with split tunneling a wireguard server and create a DIY set of services to, for example, remotely manage my devices or sync things from one to the other, and that's just for starters. Feels like the Unix philosophy actually being useful for once.
That's not hugely secure, though: IPv6 is only 128 bits, which means that the hash is would only provide 64 bits of security if it provided all the bits for the address. And I assume that the IPv6 address is not _only_ the hash, but instead some bits are used to put it into ULA space or similar. ULA uses 7 bits, which means that only 121 bits of the hash are usable, which means it provides 60.5 bits of security, which isn't nothing, but isn't really good enough for anything you care about.
In 2022, 128 bits is the bare minimum, and frankly 192 or 256 are often preferable.
Encryption is done using normal Wireguard keys so it's not a security problem. Im curious if the DHT routing is done based on the key or on the IPv6 address that represents the key.
The software is essentially a 'node', doing the routing. Whenever it starts it reads the config file to see if there is a private key in there. If no, it will generate a new one for you and that is your identity on the network.
> Just perhaps with something other than IPsec underneath?
That is correct, it uses standard, but not ipsec, encryption based on public key cryptography. A host that saves its private key will thus forever have the same IP address and if it runs services you connect to them using the encryption to its public key.
A node that is configured to connect to the wider yggdrasil public network will thus be reachable on a single IP with an identity that is based on public key cryptography, even if the machine is moving from network to network or even another continent.
"Still - can't figure out what the project does and what would be the practical application for it."
It is a computer network, like the internet. As a computer network, the practical application for it is similar to practical application for the internet.^1 One of its advantages over the internet is that users control their own IP addresses, not ISPs, and peer-to-peer connectivity is made easier. There is also no need for the use of TLS and all the third parties that profit as email/web gatekeepers. A peer-to-peer network offers an escape from an internet and web full of self-appointed third party middlemen, e.g., RIRs, ICANN, "tech" companies, certificate authorities, etc., who exploit their position for profit.
Yggdrasil hands you a an IPv6 /64 subnet. Most nodes on Yggdrasil assign themselves a single, stable IPv6 address. They then communicate to other IPv6 nodes in the network. Traffic on the network is E2E encrypted using a cryptographic keypair. Because of this, you don't need to use anything like TLS on the network. Just share your IPv6 address with others and you're good to go.
I first learned of cjdns from a video I saw on YouTube in 2012.^2 I was impressed by this person being interviewed. He described the most fundamental problems with the internet in plain English anyone could understand and he actually had a working solution!
The interviewer however did not seem to understand what the author was talking about. :)
26:32 in the interview. The interviewer was dismissive of this very talented developer and the developer just falls silent because they made the moment awkward.
I was not aware CJDNS was unmaintained (or considered archaic). Do you have a resource comparing CJDNS, Yggdrasil, Zeronet and maybe other similar protocol? Bonus points if there's mentions of possibilities for interoperability (or incompatibilities) between these networks, and/or discussion about the shortcomings pointed out by the matrix people when developing their Pinecone routing scheme.
> I was not aware CJDNS was unmaintained (or considered archaic).
It seems (for some definition of seem lol) that more mindshare these days is around Ygg. CJDNS's author is working on something else at the moment primarily, and while they're still committed to working on CJDNS, their attention is split. Ygg is getting regular changes. Ygg's codebase being in Go also makes it a bit easier to get contributions in. But keep in mind that this may just be biased based on the circles I'm spending time in.
> Do you have a resource comparing CJDNS, Yggdrasil, Zeronet and maybe other similar protocol?
I wish I did. This would be a great thing to put together. Maybe I should spend some time properly comparing the two.
Kind of, in that you can use it to replace Tailscale if you want. Using Yggdrasil as a DIY Tailscale replacement is probably less work than manually configuring WireGuard, because it handles the mesh features of Tailscale for you.
All nodes are publicly routable rather than private, though. If you want to lock everything down to emulate Tailscale, you can just configure your firewall to only allow traffic from a whitelist of your devices' Yggdrasil addresses[1].
I don't really understand what you mean. Yggdrasil will automatically discover and peer with other hosts running Yggdrasil on your network. Connecting your network, across the internet to another network is no different than connecting to a public peer.
My biggest concern with Yggdrasil is that, without careful configuration of every node, anyone can connect to your Yggdrasil network and potentially expose it to the public Yggdrasil network.
I've moved on to experimenting with Nebula (made by Slack). This is made specifically for closed networks and has built in tools to restrict access. I still REALLY like Yggdrasil and will continue to experiment with it; just not for private meshing.
Current Internet "works" in a very complicated way, ISPs and apps handle all the hassles, wire and wireless infrastructures, effective routing, certificate authority, encryption, permission control.
Clients who won't notice until they want to form a network at wild themself. In addition, average app developers are error prone at cryptography which are potential security holes.
Yggdrasil deals all of them as an all in one solution. Ad-hoc WiFi is enough to form a network. IP address is username, routing address and public key. App built on Yggdrasil is also freed from dealing with encryption and permission control.
The claims around "scalable" and "self-healing" are very vague indeed.
Yggdrasil is just an overlay over the existing Internet, not a replacement, which removes a lot of its usefulness.
Perhaps this means, in theory, that if you switch between multiple ISPs (e.g. phone + ADSL) or have dynamic IPv4 address, the IPv6 connectivity over Yggdrasil will stay the same.
First of all, its is a research project. The owners are very clear about that and love to repeat its lack of any guarantees ;-)
Personally I've been using it for a while and its indeed living up to its promises, but ymmd.
It is indeed an overlay network by the simple rule of that being something that people can use. Technically the guys require the underlying protocol to keep order (one after another) in the packages for the stuff to work. Which is why building it on top of tcp/ip makes sense. Note that the ordering requirement is likely to be removed in a future iteration, again this is a research project.
Ideas like doing a mesh using antenna's in your city are thus, for now, out of reach. But the core concepts and approaches will likely map very nicely to such a usecase and the lessons learned as an overlay will help such a future design.
The public network is currently around 4000 nodes, which is why "scalable" is indeed meant to be vague. Tests of a million nodes are going to be required, probably in a future protocol iteration, to make clear statements about how scalable it really is. Signs are good, DHT usage is still very low while we saw a doubling of network size in the last 6 months.
Reading https://yggdrasil-network.github.io/about.html it's even more unclear. They claim to have invented something much better than traditional routing but there is no mention of how Yggdrasing perform bandwidth/latency/cost-aware routing.
If you are interested, I suggest you stop by on the matrix room and chat about the different topics. Its rather large and I'm not a developer on the project, just someone learning from those better than me. Mostly in that room.
Yggdrasil doesn't need Internet but existing IPv6/IPv4. Ad-hoc Wifi or local router with multicast support is enough for Yggdrasil to run automatically.
It's awesome. Have been using it for a while. Ipv6 overlay network with e2e encryption. And it works well. Dns is blockchain based at the moment. It's neat. You can use it standalone or join the public one. There is also a mail system yggmail and a matrix chat implementation. All work as advertised.
Yggdrasil only does routing. DNS is not part of it. There are people running DNS severs on the network. And some of them are blockchain based, but that's not part of the Yggdrasil project.
I really appreciate that clarification. The "blockchain based" DNS server concept the parent mentioned almost caused me to bounce off of this project, which is otherwise very interesting to me.
There's an old and incomplete looking protocol spec if you look through the organizations GitHub repos (would link but not at a computer) for what it's worth.
Found it yesterday when someone posted this on lobste.rs, not sure how much it reflects the current version of the software.
When I looked into yggdrasil they were talking about repartitioning the address space to give more bits to the network id which is derived from a public key pair because network ids were small enough that collisions were being actively found.
I feel like 128 bits is a lot for address space but not enough for encryption.
> I feel like 128 bits is a lot for address space but not enough for encryption.
Yes, collisions take sqrt(2^128) = 2^64 operations to find on average. Usually 256 bits is chosen to make that 2^128 operations if finding a collision poses problems.
I think the next version of IP needs to be anonymous. That is if I connect to multiple endpoints they should not be able to know that I am the same person. It may even be a good idea to allow multiple connections to the same host to be impossible to relate together, but that has some negative connotations for DoS attacks. Right now there are a myriad of problems based around the fact that sharing IP addresses is becoming frowned upon. It is a serious threat to any P2P and even just the ability to follow links without fear (for example asks you to confirm every link you click to prevent IP leak + DoS attack).
I feel a bit dumb because I can't figure out how to use this on my m1 mac. I installed the package, edited the configuration file to include some of the public peers, and tried to click on some yggdrasil links on the website. It keeps timing out. Am I doing something wrong?
Ygg does not include a DNS, so use IP addresses directly. Notice that in most webbrowsers you need to add square brackets to indicate an IPv6 address.
Also notice that since yggdrasil automatically does end-to-end encryption, a lot of websites don't bother with ssl. So explicitly type http and turn off any plugins that turn your http into https.
Would it be possible to make a gateway between Yggdrasil and the public IPv6 internet so that nodes in one can communicate with nodes in the other? Are the address spaces disjointed, or might a particular 128 bit address contact someone different in each network?
The design behind yggdrasil is to keep as much the same as possible. I have some projects running on ygg using simple, existing, TCP-socket tech. Works great. So, to get the big issue out of the way. There is a lot of compatibility already there.
The gateway possibility is there, someone needs to do it, is all. There are instructions on the website on how to setup such a gateway on your local router, so you do not need to install the binary on each device to access ygg services.
The main reason why there isn't really anyone really doing this is that this is a research project and most people that use it, use it for their own usecases. Not to offer some websites which aren't already on mainnet.
You can send a router advertisement packet on your local network to tell machines to send you packets to the yggdrasil network/prefix, so it's easy to hook up a whole LAN to yggdrasil.
On the other hand, you would have to run an Internet gateway on one of the nodes, and give that address as a default route. It would work, but with a bit more manual work. IIRC someone ran a public Internet gateway at some point.
The yggdrasil address-space is different from the one used to give public IPv6 addresses.
The protocol does not add peers, you will have to look for nearby ones yourself and add then in the config.
If you add more than one, you might start routing between those nodes. Probably Ok on desktop, not so much on mobile.
For next steps, it picks one 'main' peer for your outgoing traffic, based on speed. (once an hour).
On a higher level, the system builds a tree out of the peers that are connected and you send data from one node to the other by directions. Think "left at church, right at heardresser". Or in yggdrasil it is "Go to node 10, then from there to node 1, then to node 5, then to node 6".
In short; a tree is built based on the elected root sending out a package and which peer sends it to you first. Indicating that that is the fastest.
You send data the shortest route though the mesh using local directions only.
Actual traffic is encrypted for the destination peer, so other than some headers needed to route, everyone in the middle will just forward an unreadable blob.
Moreover, RFC1888 never moved beyond "experimental" status. Look at its heading, where it says "Obsoleted by: 4048 Category: Experimental", and its preface which explicitly states that "This memo does not specify an Internet standard of any kind."
> their approach still spends 7 bits on the prefix.
The Yggdrasil people are very clear that this is a research project. Not to be used in production, to be used at your own risk etc etc etc.
In that light I find it unfair to claim it spends addressspace. Which, I might add, is pretty darn huge and we are not going to run out of addresses any time soon. If ever.
Maybe pedantic, but needed to point out that the 7 in `0200/7` of the usage is the opposite of being spent. The 7 first bits are the mask you need to apply to indicate that it is INSIDE the yggdrasil address-space. Which means that they only 'spend' 1 bit from from the first byte. Not 7.
> the cryptographic (in)security of Yggdrasil addresses.
Fair enough, I didn't catch that one.
The addresses generated has changed already from 0.3 to 0.4 (which is the series we see today), I expect that something will change again in future to make brute forcing harder.
Notice that in all cases the same IPv6 range was used, reusing the same space as upgrades change the individuals' IP address.
Ideally the project would use link-local addresses, but to quote Arceliar [1] (one of the devs):
> there's no standard way to specify these interfaces across platforms / number these interfaces intelligently. if there was, we could have set aside a specific interface number for ygg, and then just used link-local addresses, which is technically more correct than using a global address that isn't actually global
