RFC: Fake TCP with UDP

In p2p systems, it's useful to use udp, as connection state and reliability can be done at a higher layer (i.e. {uTP,DCCP,SCTP}/UDP/IP). NAT Traversal sucks. Many aggressive NATs will block all UDP access. TURN sometimes fails. WebRTC has not gotten 100% connectivity.

As @feross pointed out, SSL/TCP is usually accepted. It would be pretty bad if NATs blanket-blocked HTTPS access. It is generally annoying to do p2p relaying on TCP, as TCP has all the session magic in its stack. It would be nicer to be able to use standard UDP (particularly when you have your own reliability / congestion control on top).

So, what if one does {uTP,DCCP,SCTP}/SSL/UTCP, Unreliable TCP. Use what -- to the NAT -- looks like legitimate TCP traffic, but is simply UDP. Will still have to keep track of seqnos (windowing) on a per-flow basis, as NATs/Firewalls may rewrite/drop a packet based on those.

```
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TCP Header Format

```

Nothing else seems to matter. I think this would totally bypass most NATs.