Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A most elegant TCP hole punching algorithm

robertsdotpm.github.io

Post reply on HN
Print view View original

51–60 of 111 posts

Re: A most elegant TCP hole punching algorithm

#51

Post by jcalvinowens »

cperciva wrote: post #8
jcalvinowens wrote: post #2

If you're asking "where is the listener", you don't need one: https://datatracker.ietf.org/doc/html/rfc9293#simul_connect

RFCs may say that simultaneous connect must be allowed, but that doesn't mean that firewalls can't block it. Plenty of setups block incoming SYN,!ACK packets, and if both sides do that, the connection is never getting established.

In my experience most consumer routers are dumber than you're assuming they are, and will DNAT any inbound TCP packet that matches the 4-tuple after seeing the initial outbound SYN, including an inbound SYN. But yes, it doesn't work everywhere.

I wrote little paper on this technique in school and did some practical tests, at the time I was actually unable to find an example of consumer grade router that it didn't work on! But my resources were rather limited, they certainly do exist.

Re: A most elegant TCP hole punching algorithm

#52

Post by wolttam »

CamelCaseCondo wrote: post #20
sholladay wrote: post #7

This is a great algorithm! In this era where AI is eating away at how deterministic computers are, I really appreciate reading about an elegant solution to a real problem using deterministic logic.

We still live in an age of deterministic computers. It’s the software that’s become fuzzy. (And since we’re on the subject: there’s no AI)

> there’s no AI

This is a theistic statement at this point, no?

Re: A most elegant TCP hole punching algorithm

#54

Post by Arch485 »

athrowaway3z wrote: post #6

- you know each others IP's (or have a way to signal it) - can't decide on a port in the same message - don't suffer from NAT port randomization I'm not saying it will never happen, but the Venn diagram of this being the minimum complexity solution just doesn't seem very large?

I think many people know how to google "what is my IP" and send that to a friend, but don't necessarily know what a port is.

NAT randomization, I don't know. Depends on your setup, I guess.

Re: A most elegant TCP hole punching algorithm

#55

Post by subscribed »

getcrunk wrote: post #17
lxgr wrote: post #15

Earlier quoted context omitted.

Did you validate this solution yourself?

No, hence the all caps ai disclaimer. But seems plausible

You didn't even provide the exact model you pulled that out!

"Seems plausible".... Can you please read up about the ways LLM generate their output?

Re: A most elegant TCP hole punching algorithm

#56

Post by huhtenberg »

cperciva wrote: post #8
jcalvinowens wrote: post #2

If you're asking "where is the listener", you don't need one: https://datatracker.ietf.org/doc/html/rfc9293#simul_connect

RFCs may say that simultaneous connect must be allowed, but that doesn't mean that firewalls can't block it. Plenty of setups block incoming SYN,!ACK packets, and if both sides do that, the connection is never getting established.

> Plenty of setups block incoming SYN,!ACK packets

Even in the presence of a conntrack entry created by an earlier outbound SYN,!ACK ?

Got a source?

Re: A most elegant TCP hole punching algorithm

#57

Post by brewmarche »

TuxPowered wrote: post #39
eptcyka wrote: post #10

Earlier quoted context omitted.

Why not use plain IPv6 instead?

Even with IPv6 you still might have stateful firewalls allowing only for outbound connection at both ends (e.g. a CPE a.k.a. “WiFi router”) and to establish communication you’d need to punch a hole in those firewalls.

That’s true we won’t get rid of hole-punching with IPv6. But at least it will get rid of TURN.

Re: A most elegant TCP hole punching algorithm

#58

Post by aboardRat4 »

lxgr wrote: post #14

Does TCP hole punching actually work with common CPEs and CG-NATs? I don’t think I’ve ever seen it done successfully and have often wondered if it’s for a lack of use cases or due to its bad success rate and complexity compared to UDP hole punching. That said, I really wish there was a standardized way to do it. Some sort of explicit (or at least implicit but unambiguous) indicator to all firewalls that a connection…

The standard way to do it is called ipv6. Implementing it is probably easier than any of those RFCs

Re: A most elegant TCP hole punching algorithm

#59

Post by mycall »

CamelCaseCondo wrote: post #20
sholladay wrote: post #7

This is a great algorithm! In this era where AI is eating away at how deterministic computers are, I really appreciate reading about an elegant solution to a real problem using deterministic logic.

We still live in an age of deterministic computers. It’s the software that’s become fuzzy. (And since we’re on the subject: there’s no AI)

data = code in the AI age. Fuzzy data = fuzzy code.

Now combining AI with deterministic tool calling brings the best of both worlds.

Re: A most elegant TCP hole punching algorithm

#60

Post by jeroenhd »

Veserv wrote: post #9

Needing to punch holes in NAT is one of the most idiotic own-goals in the entire field of networking. NAT is effectively your router doing DHCP with a 17-bit suffix (16-bit port + 1 bit for UDP vs TCP) to each of your applications and then not telling you the address it gave you or how long it is good for (which is what a regular DHCP lease does). This is in addition to it, most likely, already doing regular DHCP and…

If only router manufacturers could be trusted to implement UPnP safely, then none I'd this bullshit would be necessary.

At least with IPv6 this crap becomes a little easier because you no longer have randomized source ports (which this article just ignores because some devices indeed maintain the same source port) and the IP address contains all the routing information you need. A simple simultaneous open is all you need.

Post reply on HN