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.
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.
Comments
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?
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.
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
Even if it is mainly about NAT, how else would you do NAT traversal?
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.
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.
You aren’t completely wrong apparently.
https://www.100ms.live/blog/webrtc-turn-server
Isn't STUN hole punching? TURN is what you do when STUN fails.
by not having nat?
...only if ipv6 wasn't written by the very people profiting from NAT.