4 ms·

My knowledge is about 2 years old on this but I can try to explain: TURN/STUN are to facilitate users communicating behind NAT and firewalls. TURN routes all tr

My knowledge is about 2 years old on this but I can try to explain: TURN/STUN are to facilitate users communicating behind NAT and firewalls. TURN routes all traffic through a central server and pushes it to clients which it has an established connection with, thus getting around NAT/Firewall. STUN is a bit more lightweight in that it really just helps users to negotiate a normal P2P connection and then they send messages directly to eachother.

wrkronmiller 6y ago
Thanks! That's in-line with what I thought was going on. It sounds like TURN is very close to being an open proxy. Rather than falling back from p2p to STUN to TURN, why not replace TURN with something more application/protocol-specific? Perhaps a webrtc-only proxy that performs authentication and can perform authorization along the lines of: user A is (only) allowed to connect to user B using protocol WebRTC.
- cjbprime 6y ago
  I think many TURN servers do this, but Slack's didn't.
- mypalmike 6y ago
  A custom intermediary needs to perform some expensive operations, such as decryption and re-encryption of the DTLS and SRTP going through it. It's much simpler and cheaper to just forward packets.
- jlokier 6y ago
  A TURN server has to do much less computation, and it also doesn't need to decrypt the payload. It's more or less a fancy packet forwarder. In addition, only a fraction of users will need TURN; the rest can use direct peer connections with the aid of NAT traversal; the two kinds of connection are more or less the same to higher layers. Conversely, if the application depended on an application server to process data, chances are you wouldn't implement a second version of the same protocol that works without the server. So a single TURN server can handle a lot more traffic than an application server, is potentially more secure, and is more easily shared between different applications, and even different owners. If you want it geo-distributed for latency, the ability to share the same TURN servers between different applications and owners gives you cost-latency advantages too.
  - ackbar03 6y ago
    > In addition, only a fraction of users will need TURN; the rest can use direct peer connections with the aid of NAT traversal; Is there actually any data on this or is it mostly anecdotal? Because I've done my own experiments on hole punching before and its almost impossible with today's routers, almost all of which it seems implement symmetric NAT (impossible to match the ports after initial contact with the STUN sever cause it becomes assigned randomly). Compound this with the fact that some ISPs have more than 1 layer of NAT, I have trouble believing that the majority of Slack users either have a direct public IP or a convenient way to conduct NAT traversal successfully.
    - hatefulmoron 6y ago
      > I have trouble believing that the majority of Slack users either have a direct public IP or a convenient way to conduct NAT traversal successfully. Google's libjingle documentation[1] alludes to a statistic that says that "8% of connection attempts require an intermediary relay server". This will obviously depend on the user demographic, I would guess that users on corporate connections are probably less likely to form successful p2p connections. [1]: https://developers.google.com/talk/libjingle/important_concepts?csw=1 https://developers.google.com/talk/libjingle/important_conce...

wrkronmiller 6y ago

Thanks! That's in-line with what I thought was going on. It sounds like TURN is very close to being an open proxy. Rather than falling back from p2p to STUN to TURN, why not replace TURN with something more application/protocol-specific? Perhaps a webrtc-only proxy that performs authentication and can perform authorization along the lines of: user A is (only) allowed to connect to user B using protocol WebRTC.

cjbprime 6y ago
I think many TURN servers do this, but Slack's didn't.
mypalmike 6y ago
A custom intermediary needs to perform some expensive operations, such as decryption and re-encryption of the DTLS and SRTP going through it. It's much simpler and cheaper to just forward packets.
jlokier 6y ago
A TURN server has to do much less computation, and it also doesn't need to decrypt the payload. It's more or less a fancy packet forwarder. In addition, only a fraction of users will need TURN; the rest can use direct peer connections with the aid of NAT traversal; the two kinds of connection are more or less the same to higher layers. Conversely, if the application depended on an application server to process data, chances are you wouldn't implement a second version of the same protocol that works without the server. So a single TURN server can handle a lot more traffic than an application server, is potentially more secure, and is more easily shared between different applications, and even different owners. If you want it geo-distributed for latency, the ability to share the same TURN servers between different applications and owners gives you cost-latency advantages too.
- ackbar03 6y ago
  > In addition, only a fraction of users will need TURN; the rest can use direct peer connections with the aid of NAT traversal; Is there actually any data on this or is it mostly anecdotal? Because I've done my own experiments on hole punching before and its almost impossible with today's routers, almost all of which it seems implement symmetric NAT (impossible to match the ports after initial contact with the STUN sever cause it becomes assigned randomly). Compound this with the fact that some ISPs have more than 1 layer of NAT, I have trouble believing that the majority of Slack users either have a direct public IP or a convenient way to conduct NAT traversal successfully.
  - hatefulmoron 6y ago
    > I have trouble believing that the majority of Slack users either have a direct public IP or a convenient way to conduct NAT traversal successfully. Google's libjingle documentation[1] alludes to a statistic that says that "8% of connection attempts require an intermediary relay server". This will obviously depend on the user demographic, I would guess that users on corporate connections are probably less likely to form successful p2p connections. [1]: https://developers.google.com/talk/libjingle/important_concepts?csw=1 https://developers.google.com/talk/libjingle/important_conce...