
TCP simultaneous open and peer to peer networking - jonchang
https://rachelbythebay.com/w/2013/06/29/sim/
======
latitude
This works and it works reasonably well.

I had used simultaneous-open TCP punching as a fallback for UDP punching when
I was doing [0] and it did help in 10-20% of cases when (a fairly elaborate
version of) UDP punching failed. That's on a scale of several hundred thousand
mediated connections per day.

One caveat though is that it requires implementing a bot-like functionality in
the clients, meaning that a mediating server should be able to tell a client -
"create a socket, bind it to this ip:port, wait, wait... connect to that
ip:port". Obviously, this is an ideal platform for DDoS attacks _if_ someone
ever manages to re-point clients to a rogue mediation server. So, yeah, it
works well, but there are some not so obvious trade-offs.

[0] [http://swapped.cc/hamachi](http://swapped.cc/hamachi)

~~~
malloc2x
Is there a Free software package that does something like this today?

~~~
synctext
TCP simultaneous open is _very_ difficult to use.

In our experience with a deployed P2P system, UDP hole punching is more
successful with all the strange NAT boxes deployed. Our success rate is 95.3%
now in the wild. As said above, this TCP fallback sounds like an excellent way
to get to 97% connection success rate!

Note that there is an upcoming IETF Internet Standard describing UDP hole
punching: [http://tools.ietf.org/html/draft-ietf-ppsp-peer-
protocol-06#...](http://tools.ietf.org/html/draft-ietf-ppsp-peer-
protocol-06#section-3.10)

We've implemented this as LGPL code:
svn.tribler.org/libswift/branches/ppsp-03/

------
phlo
STUN[1] does a very similar thing, including some trickery to get through all
kinds of plastic boxes messing with your packets.

AeroFS[2] is another, interesting approach. It's basically a dropbox clone
where all data remains on the user's computer. Transfers are encrypted with
TLS and tunneled through the company's servers.

Another interesting thing might be Opera Unite[3]. It's an in-browser web
server that can be souped up using various extensions like photo sharing,
games or chat. As far as I know its NAT traversal is somewhat limited, though.

[1]
[http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for...](http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT)
[2] [https://aerofs.com/](https://aerofs.com/) [3]
[http://unite.opera.com/applications/](http://unite.opera.com/applications/)

~~~
nwf
While on the topic of clever UDP-based NAT traversal techniques, I think my
favorite to date is pwnat [[http://samy.pl/pwnat/](http://samy.pl/pwnat/)].
Uses ICMP in a clever way, requires no 3rd party.

------
dfc
TCP/IP Illustrated Vol. 1, Stevens, pg: 250-252

------
PurplePanda
This is exactly what one of those UDP "weird hole punching tricks" does.
Except of course without connections, it not being TCP. nat-traverse
([http://m19s28.dyndns.org/iblech/nat-
traverse/](http://m19s28.dyndns.org/iblech/nat-traverse/)) works this way as I
understand it.

~~~
syassami
here's an excellent paper on hole punching/nat traversal
[http://www.brynosaurus.com/pub/net/p2pnat/](http://www.brynosaurus.com/pub/net/p2pnat/)

~~~
petercooper
For anyone who wants to fiddle as well, I wrote some very simple Ruby code
several years ago to do it too: [http://www.rubyinside.com/skype-style-
firewall-busting-with-...](http://www.rubyinside.com/skype-style-firewall-
busting-with-ruby-and-udp-399.html)

------
mixedbit
As the author notes, for such hack to have any chances of working reliably a
third party is needed to synchronize connection setup. But a third party with
a public IP could also forward an encrypted TCP connection between two
machines that do not have public IP addresses. Such approach does not require
any hacks and gives a strong guarantee that the third party can not snoop the
connection.

The only thing that the third party learns is that there is a connection, but
the proposes solution also has this drawback.

~~~
idupree
That's standardized as TURN, if I'm not mistaken (
[https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT)
). Other NAT traversal mechanisms (STUN) don't make the server pay for
bandwidth. (Which methods work with TCP, in practice?)

~~~
dfc
There was a good thread on p2p-hackers a little while back. I apologize for
not digging up the link but I'm on my way to bed. I think the thread was
something like "state of the art NAT traversal"

------
eridius
Because nobody has linked it yet, the referenced XKCD is
[http://xkcd.com/949/](http://xkcd.com/949/)

------
gcb0
Why not just adopt ipv6 and connect to the box directly and intuitively when
all ipv4 nat boxes in the middle die?

~~~
yxhuvud
We have had customers ask us if we support NAT for IPv6, so don't assume NAT
will automatically die.

Sadly enough.

~~~
winthrowe
I can kinda see edge cases where 1-1 NAT makes sense, depending on the
product, or are they asking for NAPT like most people think of NAT?

~~~
yxhuvud
The latter, AFAIK. It has been some months since the product manager in
question forwarded the question to us.

As for 1:1 NAT, we already support other solutions that have similar effects,
such as scriptable proxying.

------
throwawaykf02
I'm not sure what OP has against UPnP port mapping. It's not an ideal option
and certainly not the best-designed specification, but it's a way to
explicitly tell the NAT to do what we want, rather than having to trick it
into doing what we want.

Also, one option not mentioned here yet is Teredo:
[http://en.m.wikipedia.org/wiki/Teredo_tunneling](http://en.m.wikipedia.org/wiki/Teredo_tunneling)

It's primarily an IPv6 transition technology, but it comes with NAT traversal,
hole-punching and all that built-in. What you get is a virtual IPv6 network
interface to which you simply bind your socket, and you can connect to other
Teredo / IPv6 sockets... if the whimsies of the Gods of Middleboxes allow.

What makes it attractive is that it is deployed on all Windows machines WinXP
and later (and enabled by default on Vista and later), giving it a huge
deployment base. It's not present on non-Windows machines, of course, but
there is a liberally licensed implementation for OSX and Linux called Miredo.
uTorrent is one popular application that uses Teredo.

However, Teredo tunneling does not work very reliably (apparently, its
designers traded off connectivity for additional security), and it would be
unadvisable to have that as your only NAT traversal method. But I think
getting that option with minimal additional code is not a bad deal.

------
chacham15
From my understanding a NAT is going to remap an internal port to a different
external port and upon receiving a RST will delete the mapping. Is this not
correct?

Also, doesnt connection reversal solve this problem? (Connection reversal:
have A connect to intermediary S. have B connect to intermediary S. S sends A
B's info and vice versa. A connects to B before closing connection with S.)
This also does not require S to forward data, only connection information. Am
I missing something there?

~~~
digitalsushi
There are like 4 different NAT port translation models. In some of the models,
the NAT algorithm will actually preserve the ephemeral port number in the NAT
mapping. This falls apart quickly when you have a few NAT clients. But it can
make legacy software work a lot better. We have weeded most of that software
out at this point, or at least provided application gateways that inspect the
content of the packet and tweak little things - consider how you need an extra
kernel module for FTP and SIP and stuff.

The models are detailed nicely in this diagram.
[https://en.wikipedia.org/wiki/Network_address_translation#Me...](https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation)

------
peterwwillis
[http://nmap.org/misc/split-handshake.pdf](http://nmap.org/misc/split-
handshake.pdf)

------
ricardobeat
Isn't this called "NAT punching", and generally used by games and other sw to
establish peer-to-peer connections?

~~~
DennisP
That's usually UDP. With this method, you "get all of the utility [TCP]
provides without trying to reproduce it over UDP."

------
maffydub
I'm surprised this works... or at least works reliably. I understood many
simple firewalls just blocked inbound SYNs (without performing any kind of IP
address lookup). This would obviously prevent this mechanism from working. Is
this not (or no longer) the case?

~~~
amenod
I am not an expert in this area, but from what I understand, firewalls keep a
list of outbound connections. If inbound connection comes from a known
destination IP+port, it will be forwarded to the internal "source" IP+port.

This is how I understand it: if both A and B are behind firewalls, they use C
to reach an agreement about IPs and ports used. Then A sends a packet to B,
which is silently dropped at B's firewall. Then B send a packet to A - since
it looks like an "answer" to previous request it is forwarded by A's firewall
to A. Then A sends another packet to B, which is also forwarded by B's
firewall to B. Voila, connection made. :)

Note that this is just my understanding, so I would appreciate if someone more
knowledgeable in this area would chime in.

------
AndreasFrom
BitTorrent Sync [1] can help with the explicit file sharing problem from the
xkcd. Too bad it's not open source.

[1]:
[http://labs.bittorrent.com/experiments/sync.html](http://labs.bittorrent.com/experiments/sync.html)

------
wtracy
Is this the sort of technology that P2P systems like BitTorrent use? I've
never understood how BT works in setups that block incoming connections.

------
czzarr
what was the title of the book you read?

