Hacker News Reader

Comment by markisus | Hacker News Reader

This has got me reading about TURN and it just seems like a huge ugly hack. Two computers want to send UDP to each other. They are electrically connected by sets of physical cables. They could even be down the street from each other. But they don’t know how to get their routers to set the right bits in their translation tables. Instead it’s just easier to send all their traffic through a third computer in another city thousands of miles away or maybe into outer space and back. Have I got it right?

View on HN

From what I understand the real ugly hack is NAT tables thanks to the shortsightedness of IPv4.Everything else flows from there.

Mostly, though, what you are describing is the internet

For me something only qualifies as a 'huge ugly hack' if a better way exists. I think TURN does the best it can in the constraints that exist!

* TURN handles protocol bridging (TCP <-> UDP)

* TURN is useful for privacy preservation.

* TURN handles NAT Traversal (unfortunate when it comes to this)

* TURN is used for security in some cases. It sits at the edge and clients create allocations

Oh I thought TURN was mainly about the NAT traversal. Can you elaborate on the other points? Especially security and privacy?

Even if it is mainly about NAT, how else would you do NAT traversal?

by not having nat?

...only if ipv6 wasn't written by the very people profiting from NAT.

Hole punching: https://en.wikipedia.org/wiki/Hole_punching_(networking)

Oh I guess that’s STUN that does the hole punching.

I’m so used to seeing both STUN and TURN together.

You aren’t completely wrong apparently.

> TURN is considered an extension to the STUN. So, a typical TURN server would include a STUN server implementation by default.

https://www.100ms.live/blog/webrtc-turn-server

STUN is merely a well-thought out signaling protocol. The simplest, and most common, route is for each party to reach out to the rendezvous (STUN server), which then responds with the port and IP in the other peer. Each party then uses the same address and port it received, because remember that a typical NAT merely maps a port to a port on one of its managed/internal endpoints. The mapping that was created for the STUN server is just as good for use by the other peer.

You could do all of that with your own protocol, but...

Some NATs will include the remote IP in the "key" of the mapping, or even more restrictive approaches, meaning that STUN will have to fall back to other strategies and eventually give up and use TURN.

These days you'll also find that mDNS and other local broadcasts play a role, so that the internet can be avoided entirely for LAN peers.

Right, so hole punching alone doesn’t solve the problem of NAT traversal, which is why TURN and things like it are needed.

when I wrote my other comment in my head TURN and STUN were practically synonymous, since I’ve never seen one without the other.

Isn't STUN hole punching? TURN is what you do when STUN fails.

Without TURN, two clients that want to do streaming communication connect directly to each other, letting both ends know things like IP addresses, supported protocols, and other fingerprintable features. This was the norm for a long time - “I got your IP, I know where you live”

I’m not sure what you mean by fingerprinting and supported protocols. None of that would be present inherently in a UDP stream unless the application included it. As for hiding IP address, that is a valid use case for a TURN server but I’m guessing 99% of TURN server usage occurs only because the NAT hole punch failed.

> by fingerprinting and supported protocols. None of that would be present inherently in a UDP stream unless the application included it.

Much like TLS, both clients offer all the protocols, versions, and media encodings that they support so that they can find a common set that they can use together.

This is standard negotiation when establishing connections in WebRTC and it's obviously fingerprintable information.

You’re talking about WebRTC which may or may not make use of a TURN server. And I assume there are other uses of TURN which are completely unrelated to WebRTC.

Use of a TURN server does not imply hiding of negotiation details. The TURN RFC [1] does not mention anything related to media encodings or WebRTC negotiations at all.

[1] https://datatracker.ietf.org/doc/html/rfc5766

Basically. I guess part of the issue is that NAT is also used as a security measure, so there are competing interests in making the ports chosen by outgoing UDP packets deterministic to make STUN easy, versus randomizing and restricting return traffic to the original recipient to make attacking harder and STUN impossible.

> They are electrically connected by sets of physical cables.

Pedantic: Fibre and wireless do not fit this criteria, but I still agree with the spirit.

Extra pedantic: Ethernet cables are galvanically isolated at both ends. There is no electrical connection at all.

That isolation is within the devices, so the devices are still electrically connected, right?

I guess we can say both instances are electromagnetically attached. But then, basically everything is.

Yep. But this is what IPv6 was supposed to solve.

I don’t know much about IPv6 but it seems like even if we are stuck with IPv4 we could still make some sort of protocol where my computer could manipulate the NAT table entries allocated to it. Maybe something like DHCP but it deals with ports.

Isn't something like that what UPnP / zeroconf is supposed to do[1][2]?

[1]: https://en.wikipedia.org/wiki/Universal_Plug_and_Play

[2]: https://en.wikipedia.org/wiki/Zero-configuration_networking

Very interesting. I even found some protocols that exactly implement the functionality I was thinking of!

https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...

https://en.wikipedia.org/wiki/Port_Control_Protocol

NAT may go away, but stateful firewalls won't. There will still be many environments where you can't easily get a point to point connection even though the IP is addressable and there is a route.

Won’t the firewall know to let return traffic through if my computer explicitly sends a request first?

Reply on news.ycombinator.com