TCP splicing through simultaneous SYN exchange

This was originally a Slashdot post.

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:

1. Side1 Binds their TCP socket to a particular port.
2. Side1 Tries to connect to Broker on an agreed upon port.
3. Broker Replies with an RST when it recieves the expected SYN. Records source IP and source port.
4. Side2 Binds their TCP socket to a particular port.
5. Side2 Tries to connect to Broker on an agreed upon port.
6. Broker Replies with an RST when it recieves the expected SYN. Records source IP and source port.
7. Broker Informs Side1 of Side2's source port and source IP.
8. Broker Informs Side2 of Side1's source port and source IP.
9. Source1 Uses same socket originally bound to connect to Source2's IP and port.
10. Source2 Uses same socket originally bound to connect to Source1's IP and port.
11. 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:

1. 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.
2. 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.
3. 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.