[Feature Request]: UDP unicast instead of multicast

[formtapez]

Platform

Cross-Platform

Description

It would be great if the user could configure a custom UDP unicast address (a "normal" IP-address, or even better: a complete hostname which then gets resolved) for the UDP-Link feature. That would allow to bridge two nodes which are not located in the same WiFi network.
Then other infrastructure (like the HAMNET for example) can be used to bridge two networks without having to put everything in a L2-VPN.

[Jorropo]

👍 notes from discord we should encrypt theses, DTLS probably makes sense here.

Also ever since v2.6.2 I've made two changes (96ba948 & f41afb1) which means a running a single L2 domain is no longer required.
You can setup an L3 IGMP based routing solution and it should* work, see https://an0n-r0.medium.com/making-dlna-through-site-to-site-vpn-work-f393629f4ce0 for example to set that up with wireguard (an L3 VPN).

*I havn't tested it yet.

[formtapez]

Okay, but therefore you need two additionaly computers which cost money and energy just to manage that VPN and make the multicast-routing. The cheapest solution would be just to be able to change that IP address. Then a normal port-forward could be used, or just use existing routing (HAMNET).
I dont think that additionaly encryption is needed, because the UDP-Link is just a replacement for the air-interface, which is already encrypted.

[Jorropo]

Okay, but therefore you need two additionaly computers which cost money and energy just to manage that VPN and make the multicast-routing. The cheapest solution would be just to be able to change that IP address. Then a normal port-forward could be used, or just use existing routing (HAMNET).

👍

I dont think that additionaly encryption is needed, because the UDP-Link is just a replacement for the air-interface, which is already encrypted.

I strongly disagree, there is a huge effort difference between anyone within a handful of kms can send kbps of data per second to my node VS anyone on the planet can send 54Mbps of data to my node.
WiFi / Internet is ridiculously faster than LoRa and I don't want a situation where you setup a port forward and that turns into you being a nuisance spectrum hog against your knowledge because some rando started spamming your UDP port.

Among other benefits with a modern encryption like DTLS you will be able to add and remove public keys, and only allowed nodes will send / receive UDP packets.

[thebentern]

We also already have MQTT largely filling this role. It is more than likely if we enable UDP to escape the LAN natively, we will be subject to a bunch of sweeping data privacy / compliance changes similar to MQTT around this feature that I have no appetite for.

[EternityForest]

Seems like the use cases for this are pretty strongly overlapping with my distributed hash table routing discussion.

One advantage of that proposal (in it's latest form) is that the gateways that talk outside the lan can be completely separate third party projects, all Meshtastic itself needs to do is mark packets as globally routable, and periodically publish a "I want to link channel hash X with global link key Y".

The global link key is derived from a rolling code, so nobody can spam your UDP port continually unless they have the channel key, or they're nearby to listen to the new rolling codes, or maybe if they do traffic analysis on the entire OpenDHT network.

If you make the rolling code a little longer, so it could serve as an extra layer of encryption key, then nobody could even get any metadata.

They can't even DDoS you without the key, and you don't even need to reveal your IP address to communicate.

You could swap in any anonymity network, DHT, central server, hamnet link, etc.

[formtapez]

All these issues should be solved if we let the node only accept traffic from the configured IP-address of the bridge-partner.

[Jorropo]

The protocol is non interactive, it is trivial to forge UDP packets with the wrong source IP address and you are rolling the dies on whether or not your ISP properly filter them out (many don't).

Even assuming this didn't had more issues, I don't see how this answers in the first place:

we will be subject to a bunch of sweeping data privacy / compliance changes

[madeofstown]

The protocol is non interactive, it is trivial to forge UDP packets with the wrong source IP address and you are rolling the dies on whether or not your ISP properly filter them out (many don't).

Even assuming this didn't had more issues, I don't see how this answers in the first place:

we will be subject to a bunch of sweeping data privacy / compliance changes

People aren't planning to use this on the open Internet right? (The S in IOT stands for security) NAT should protect you from malformed UDP packets coming from WAN.

[Jorropo]

People aren't planning to use this on the open Internet right? (The S in IOT stands for security) NAT should protect you from malformed UDP packets coming from WAN.

• If you are gonna run this over LAN you don't need this feature, multicast works already.
• not all networks use NAT
• Many IoT products being insecure is not a good argument to contribute to the problem. Doing encryption is not much more efforts.

Edit: overall I think it's bad UX to give sharp and dangerous tools to people when a safe solution exists and doesn't provide less value.