TCP splicing through simultaneous SYN exchange
TCP allows a connection to be established if both sides simultaneously send
eachother a SYN packet. This method requires a little NAT cooperation, but
only a little. Here's how it could work:
- Side1 Binds their TCP socket to a particular port.
- Side1 Tries to connect to Broker on an agreed upon
port.
- Broker Replies with an RST when it recieves the expected SYN.
Records source IP and source port.
- Side2 Binds their TCP socket to a particular port.
- Side2 Tries to connect to Broker on an agreed upon
port.
- Broker Replies with an RST when it recieves the expected SYN.
Records source IP and source port.
- Broker Informs Side1 of Side2's source port
and source IP.
- Broker Informs Side2 of Side1's source port
and source IP.
- Source1 Uses same socket originally bound to connect to
Source2's IP and port.
- Source2 Uses same socket originally bound to connect to
Source1's IP and port.
- Voila! They connect via exchange of simultaneous SYNs.
This requires cooperation between the sources and their NATs. Specifically,
it requires these three things from a NAT:
- The NAT should keep the same outgoing port for the same TCP port on a
client for a period of time. This is very similar to how a NAT handles
UDP.
- A NAT must not reply to SYNs it recieves on a bound TCP port that don't
originate from the connected to IP. Normally it would reply with an
RST.
- A NAT must change the IP it's expecting TCP packets from if the client
sends out a new SYN to a different IP and port combo.
There is one non-problem I expect people to bring up. There seems to be an
apparent race condition in step 11. This isn't really a race condition because
of requirement 2 for NATs. Basically, the two sources can SYN eachother all
day, and it won't matter until both NATs have performed the step required by
requirement 3, at which point it will appear to both sources as if the SYNs
were simultaneous.
It's a hack, but I think it'd work.