search

yggdrasil-network / yggdrasil-go

An experiment in scalable routing as an encrypted IPv6 overlay network
https://yggdrasil-network.github.io
Other
3.54k stars 242 forks source link

Protocol choice for peers discovered over multicast #1187

Open meshmayhem opened 1 month ago

meshmayhem commented 1 month ago

Yggdrasil currently only supports TLS for multicast peerings, there should be an option for the user to choose what protocol is used.

neilalexander commented 1 month ago

What use case do you have in mind? It would be extremely unusual to find one protocol available and another one blocked at the link-local level.

meshmayhem commented 1 month ago

QUIC is my personal use case, which requires manual peering to use with local peers in the current implementation. Generalizing to allow using any of the supported peering protocols rather than just QUIC and TLS would likely be the easiest to implement and maintain.

neilalexander commented 1 month ago

What I'm not sure about is why you'd prefer QUIC in this case. There is no benefit from connection migration etc on link-local peerings and, all else equal, it performs worse than a TLS peering does.

Using tls://:

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  3.12 GBytes  2.68 Gbits/sec                  sender
[  5]   0.00-10.00  sec  3.12 GBytes  2.68 Gbits/sec                  receiver

Using quic://:

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.20 GBytes  1.03 Gbits/sec                  sender
[  5]   0.00-10.02  sec  1.19 GBytes  1.02 Gbits/sec                  receiver

The multicast discovery is just as much about providing sane defaults for local connectivity.

ufm commented 1 month ago

What I'm not sure about is why you'd prefer QUIC in this case. There is no benefit from connection migration etc on link-local peerings and, all else equal, it performs worse than a TLS peering does.

But, for example, plain TCP should be even faster.

neilalexander commented 1 month ago

But, for example, plain TCP should be even faster.

You are right, it should be, and multicast peerings did used to be plain TCP. However, it leaves protocol control messages unencrypted, so we decided defaulting to TLS was the happy middle-ground.

ufm commented 1 month ago

You are right, it should be, and multicast peerings did used to be plain TCP. However, it leaves protocol control messages unencrypted, so we decided defaulting to TLS was the happy middle-ground.

I’d prefer to have a bit more speed or slightly less CPU load. I have nothing to fear in my local network. My wife and my cat will stand up to protect me from evil hackers if needed. And there’s no one else in my local network.

ufm commented 1 month ago

What I mean is that it would be better if this could be configurable. Neither you nor I — no one knows exactly what a particular user needs. And if they’ve found some information deep in the documentation about how to change the default behavior, it’s better to assume that they know what they’re doing.

neilalexander commented 1 month ago

There are further questions though, namely:

  1. What if you configure TCP and I configure TLS and then we end up on the same network — should the connection just fail to establish or do we expect something more intelligent to happen?
  2. Right now we already have some code that tries to avoid duplicate connections, but it already struggles with zoned link-local addresses, so you typically end up with one inbound and one outbound peering anyway if both sides are listening and beaconing — what if they come up as different protocols?
  3. Will anyone remember to switch between TCP and TLS if they roam between networks that have different levels of trustworthiness?

Maybe these are things we’d have to think about much more if we were approaching a v1.0 but for now I am just not convinced it’s worth the complexity.

ufm commented 1 month ago

Connection should just fail to establish.

We have fundamentally different approaches. You believe the user is clueless and shouldn't be given unnecessary options. I believe the user is an adult, understands what they are doing and takes responsibility for their actions. Yes, reasonable default settings are needed, and in this case, TLS is perfectly fine for that. But let me repeat: there are no "unexpected" guests in my network who need to connect to Yggdrasil (and if there are, we'll work it out). However, extra electricity and CPU time for unnecessary encryption are still being consumed and just heating the air. Greta Thunberg is looking at you with disapproval. :)

ufm commented 1 month ago

P.S. By the way, if I have it set to not send beacons, and the person who came to me has the same setting, how will we connect? Oh my god, everything is doomed, how can this be! :)

meshmayhem commented 1 month ago

What I'm not sure about is why you'd prefer QUIC in this case. There is no benefit from connection migration etc on link-local peerings and, all else equal, it performs worse than a TLS peering does.

While I understand QUIC may perform worse than TLS in your network, it significantly outperforms TLS and TCP in mine. The requested feature would allow all three of us to use the protocol best fit for our needs.

The multicast discovery is just as much about providing sane defaults for local connectivity.

I believe defaulting to TLS is very sane, though I don't think that should come at the cost of users having the option to choose a protocol better suited to their network or preference.

3. Will anyone remember to switch between TCP and TLS if they roam between networks that have different levels of trustworthiness?

I think dynamic protocol switching for multicast peering is out of scope for this issue, but it may be worth exploring in the future.