verification of our STUN/TURN implementation

[robert-cronin]

We need to decide if it's appropriate or even useful for us to make our NAT traversal implementation conform to the STUN/TURN RFCs. There is something to say about having a full-blown STUN/TURN implementation, which I can see 2 main benefits of:

1. with conformance to the RFCs, we can be confident that NAT traversal will work in all situations that STUN/TURN work in.
2. our implementation will be usable by other services.

On the other hand, if we just wanted to make our implementation work with other polykey nodes, there is likely to be a lot of redundancy in conformance to the RFC. We could perhaps just stick with custom NAT traversal utilities and not call it STUN/TURN at all.

Edit: I should add that a detailed cross-check of where our implementation falls short of the RFCs would still be useful in the latter choice as we can be sure about what we are missing out on

[CMCDragonkai]

You should still review the RFCs to see if anything was missing. Like the review we did yesterday and we found out that symmetric NAT problem.

…

On 16 September 2020 12:44:11 pm AEST, Robbie Cronin ***@***.***> wrote: We need to decide if it's appropriate or even useful for us to make our NAT traversal implementation conform to the STUN/TURN RFCs. There is something to say about having a full-blown STUN/TURN server implementation, which I can see 2 main benefits of: 1) conforming to the RFCs will allow use to feel confident that NAT traversal will work in all situations that STUN/TURN work in. 2) our implementation will be usable by other services. On the other hand, if we just wanted to make our impl. work with other polykey nodes, there is likely to be a lot of redundancy in conformance to the RFC. We could perhaps just stick with custom NAT traversal utilities and not call it STUN/TURN at all. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #101

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[CMCDragonkai]

This is related to #100. TURN is covered by the usage of relay and kademlia. So in a way I'm not sure how closely it will follow the standard.

But STUN isn't always reliable. Using UDP to achieve this is possible, but I think there were some issues with the current implementation which wouldn't work where the NAT operated like a normal router.

The Tetra project should be verified to actually simulate a "normal router" NAT.

[CMCDragonkai]

I think mobile-NAT busting we will leave that after the MVP (this might actually be achieved by our Kademlia-TURN).

[robert-cronin]

Closing on account of migration to gitlab