Version 0.5 roadmap

[neilalexander]

The following are things we have identified as desirable for v0.5:

• Revised routing

Replace the routing algorithm with a new and revised one. This is done in Ironwood.

• Revised session crypto

This is likely to happen in a future version. Replace the current end-to-end session encryption with something more standard, like Noise or DTLS — audited libraries would be even better. The current key rotation is also a bit too aggressive and that hurts performance so it would be nice to have something more resource-friendly.

• TLS mutual peer authentication

Replaced with per-listener, per-peer and per-multicast interface password authentication which is far simpler. Allowing a node to be configured with TLS certificates and a trusted CA, so that peerings can only be established with other trusted nodes from the same CA.

• Network segregation

A shared network key, included in the tree announcements, will ensure that two nodes that peer with what should be segregated networks will ignore each other. This should make it much easier to operate private Yggdrasil meshes and not worry that they will end up accidentally peered to the public network.

• Peer queues

Something like fq_codel or even something naive (like matrix-org/pinecone#34), so that we can more fairly balance traffic around the network and reduce latency somewhat in congestion scenarios. Obviously we can't avoid the problems from TCP buffers but it might improve things slightly.

• QUIC peerings

Assuming the padding in QUIC doesn't end up being too terrible, we could use quic-go or something as an alternative peering transport.

• Fuzzing

Support for fuzzing landed in Go 1.18 recently.

[zhoreeq]

Mutual peer authentication

Something like SAE?

[majestrate]

Revised session crypto
QUIC peerings

have you considered an http3 lookalike? it is basically quic + tls 1.3, such would allow one to do actual domain fronting and blend in with google youtube and cloudflare traffic :^)

[ri-gilfanov]

What do you mean by a some kind of shared-key authentication?

If the shared key is stored on each node, then this can introduce additional administrative complexity for next use cases:

1. Removing access for multiple nodes. For example, manually maintaining BlockPublicKeys doesn't sound like a good idea.

2. Replacing the shared key on multiple nodes. The first thing that comes to mind is a centralization point, which announces the expiration date of the old shared key and propagates the new shared key.

Sorry for my google translate.

[majestrate]

shared key authentication would be gatekeeping connecting to peers by requiring an additional out of band key to connect, like a username/password. right now it can be done with a pubkey whitelist but that is hard to manage.

[ri-gilfanov]

Ah, I remember/understood. The AllowedPublicKeys option restricts incoming peer connections only. I still need to use a firewall to control access to TCP/UDP ports.

However. A single authorization key (as an alternative to the AllowedPublicKeys option) can lead to difficulties in the following cases:

1. Leakage of an authorization key to third parties,
2. The need to block some peers that have an authorization key.

In both cases, I will need to recreate the authorization key and redistribute it to my peers (or to friendly peers). This is also not easy to manage. This may require more complex functionality. Something like a "centralized password reset" for a known set of peers.

[jhaar]

Ummmm, you're sorta describing why PKI was invented. ie mutual auth is solved by having a CA and it signing both the server and client certs, and revocation of specific certs solves the need to reject previously trusted clients too.

Currently I'm running a "private" ygg network and solve the AllowedPublicKeys problem by creating a Yggdrasil initialization process that involves the client creating it's private key and pushing it's public key up to the server via an OOB channel (php script) that's "sudo-edit"ing the server Yggdrasil file. Works well enough for my playing around - but not how TLS VPNs do it. Doesn't deal with the "reject previously trusted client" issue I admit - but there's always vim :-/

BTW, at work we're running a PKI to handle traditional VPN clients for 12K users (ie client certs): revocation of certs happens up to a dozen times per week. I throw that factoid in here just to reinforce the fact that "breaking" previously trusted clients is a real issue and not some theoretical one

[NikitaPuzyryov]

Seeing that quic peerings got through, but session crypto got postponed: would it make sense to use quic for session crypto as well?

[neilalexander]

In the future maybe, when QUIC datagram support in quic-go is more mature. Right now I'm not sure it would perform as well and we would still need better control over the packet size in the quic-go library first (although there is an issue upstream tracking that).

[Cuteistfox]

 QUIC peerings

Assuming the padding in QUIC doesn't end up being too terrible, we could use quic-go or something as an alternative peering >transport.

Why is #344 open then

[neilalexander]

https://github.com/yggdrasil-network/yggdrasil-go/releases/tag/v0.5.0

https://github.com/yggdrasil-network/yggdrasil-go/releases/tag/v0.5.1

[almereyda]

And now even:

https://github.com/yggdrasil-network/yggdrasil-go/releases/tag/v0.5.2

Which just happened to land not even three hours later in the apt repository with no noticeable delay. Good work!