Item — HN Reader

The confusion is understandable. Fundamentally, all that's going on is that UDP Gateway is performing the NOISE_IK handshake and ChaCha20-Poly1305 encryption to establish a tunnel. It does nothing with the encapsulated traffic other than deliver it (raw or decapsulated) to the configured destination (Lambda, S3, etc.).

It's a primitive for building secure, but open to any client (any peer public/private key will be accepted).

To use it as a VPN would require write a complex Lambda on the AWS end. But that isn't the point.

The point is providing very efficient encryption for UDP from the edge to the cloud, or between machines. It's lighter weight and more reliable than DTLS because of the lack of sequence number and retry.

That's it.

1 comments

Okay, so you're saying that it's not a complete WireGuard implementation and not functional. Every WireGuard endpoint must have an IP address (or subnet) on the encrypted subnet. If an endpoint doesn't have one, WireGuard cannot route traffic to that endpoint.

You said the handshake is establishing a tunnel, and that it is delivering raw traffic, but how is that possible in a L3 environment that uses IP addresses to determine route(s) to an endpoint? When you refer to "encapsulated traffic", you probably mean traffic from the unregistered endpoint to a known WireGuard server, This would give the known WireGuard server the public IP of the unregistered endpoint, but unless the WireGuard server has an IP address for the unregistered endpoint's encrypted L3 subnet, no traffic will ever flow in the other direction.

A few years ago, I had an idea for a secure way for two WireGuard endpoints to find each others' public IP address, which I have not yet implemented, but even in that environment both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.

Some background on my WireGuard experience:

I've set up a lot of WireGuard systems and have even done some WireGuard demonstrations for government research purposes (over five years ago, before I retired).

Right now I'm maintaining (for myself, my family, some former consulting clients, and two of our security systems) a dual-stack multi-point WireGuard network with three cloud servers, and about 30 endpoints scattered across four physical locations and five mobile devices. I even set up some kludgy scripts so that two of the locations using dynamic IP can communicate directly point-to-point with each other, and fall back to one of the cloud-based WireGuard routers to re-sync if/when one of their public IP addresses changes. Direct point-to-point communication cuts latency in half and reduces my cloud data fees.

Well, here are a couple things to do with this:

I have a fleet of small battery powered temperature sensors that send readings to a backend built with it. On the sensors, I’m using the vanilla WireGuard-ESP library to connect over Wi-Fi to the backend (full tunnel). So the IP for the device is assigned like normal, the the tunnel is established. The sensor also needs to pull time (NTP) over the tunnel. So it talks to two different “IPs” that are completely virtual. At the other end of the tunnel the packets are inspected in the Lambda and if they match one of the two magic IPs, things happen (temperature stored or NTP response). The Lambda function does all that work (there is no real NTP server).

Another example is what I call CoAP/wg where raw CoAP requests are sent by a client application. By raw I mean what goes over the tunnel isn’t encapsulated IP, it’s just plain CoAP. In that case the backend just handles it like any other CoAP implementation would since the UDP Gateway terminates the encryption/tunnel. This isn’t a tunnel in the networking sense but it uses the same backend as the temp sensor example.

It’s a weird tool, but a really nice one IMHO.

> both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.

That’s how every other implementation works. It’s not a requirement of the protocol though, and that inspired this tweak in my implementation.

FWIW, it still allows configuring known peers separately from unknown ones.

Sorry for the double reply, I had meant to address that in the first.

Thanks for your explanations. I recognize that you're offering this as a product within the AWS ecosystem, but because it's an evolution of WireGuard, which has a GPLv2 license, you should probably provide some way for users to obtain your source code, unless you've acquired a separate license directly from Jason Donenfeld.

I don't use any code from others here, it's a ground-up implementation of the protocol in C# targeting .Net 10 AoT.