This is an excellent article!<p>The tribal knowledge seems to be that you shouldn't do TCP-based hole punching because it's harder than UDP. The author acknowledges this:<p>> You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go.<p>However, I only see marginally added complexity (given the already complex UDP flows). IMO this complexity doesn't justify discarding TCP hole punching altogether. In the article you could replace raw UDP packets to initiate a connection with TCP SYN packets plus support for "simultaneous open" [0].<p>This is especially true if networks block UDP traffic which is also acknowledged:<p>> For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic.<p>My point is that many articles gloss over TCP hole punching with the excuse of being harder than UDP while I would argue that it's almost equally feasible with marginal added complexity.<p>[0] <a href="https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.html" rel="nofollow">https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcp...</a>
Fascinatingly effective, but maybe I'm the only one getting the heebie-jeebies when someone suggests implementing this in production corp networks. Sure it's super convenient, but the thought of bypassing all traditional NATs and firewalls, and instead relying solely on a software ACL, seems super risky. Maybe I just don't understand how it works, but it seems that a bad actor getting access to a stray VM with Tailscale on it in, say, your AWS testing env, essentially has an clear path all the way into your laptop on the internal corp network, through the kernel, into user space and into the Tailscale ACL code as the sole arbiter of granting or blocking access. Would I even know someone unauthorized made it that far?
I wish there was a tailscale-like equivalent without connectivity encryption, for devices which encrypt at the application layer (like almost the entire internet does). We don't always need the lower layers to be encrypted, this is especially computationally expensive for low power devices (think IoT stuff running a tailscale like tunnel).<p>GRE tunnels exist and I actually use them extensively, but UDP hole punching is not handled so hub-and-spoke architecture is needed for them, no peer to peer meshes with GRE (ip fou).<p>Are there equivalent libraries out there which do UDP hole punching and unencrypted GRE tunnels following an encrypted handshake to confirm identity?
> So, to traverse these multiple stateful firewalls, we need to share some information to get underway: the peers have to know in advance the ip:port their counterpart is using.
> [...] To move beyond that, we built a coordination server to keep the ip:port information synchronized<p>This is where I wish SIP lived up to its name (<i>Session</i> Initiation Protocol, i.e. <i>any</i> session, such as a VPN one...) and wasn't such a complicated mess making it not worth the hassle. I mean it was <i>made</i> to be the communication side-channel used for establishing p2p rtp streams.
This is the article I sent people to for NAT traversal<p>This may be the only way we ever have to build p2p apps. IPv6 doesn't have enough steam since NAT and SNI routing solve most problems for most people.<p>And ISPs are very much not incentivized for that to change.
IMO: this is arguably one of the most detailed articles on NAT traversal on the entire Internet. But it is missing information on delta behaviors (its not that complex -- just that some NATs have observable patterns in how they choose to assign successive external ports. The most common one is simply preserving the source port. But there can also be others, e.g. an increment of the former mapping.)<p>It's a very good theoretical article. I wonder to what extent a software engineer could use this though. Because although it does describe many things I'm not sure there's enough detail to write algorithms for it. Like, could an engineer wrote an algorithm to test for different types of NATs on the basis of this article? Could they adapt their own hole punching code? I've personally read papers where simple tables were more useful than entire articles like this (as extensive as it is.) Maybe still a good starting point though.<p>Also, the last section in the article is extremely relevant. It has the potential to bypass symmetric NATs which are used in the mobile system. The latest research on NAT traversal uses similar techniques and claims near 100% success rates.
Interesting blast from the past. We built an oblivious p2p mesh network that did this in 2010. Back then, nobody cared about security as much as we thought they should. Since then, nobody still cares about security as much as they should. Devices have increased and their value has increased, and still, they are quite insecure. Truly secure endpoints with hardware root-of-trust and secure chains of trust for authn/authz and minimal temporary privileges is still hard, and network perimeter security theater is still ongoing in home networks, corp networks and even large production datacenter networks. Only reason we don't find these to be the primary root-cause for security breaches is because more easier attack chains are still easily available!
A bit OT:<p>A read a bit about this space a few weeks ago after not knowing anything about it beforehand. My impression is that ip6 dices all of this and NAT traversal isn't necessary anymore. So why isn't ip6 more popular and how do I get started with it for my home network and tailscale VPN?
Another year, another repost of an article about NAT traversal, another couple replies about how this is insecure followed by people explaining that NAT is not a security feature.