Details

CCH uses a technique similar to that used by Skype and other P2P applications
to poke holes in your firewall from the inside out. It's slightly different
in that it creates a TCP connection instead of a UDP hole.

It also demonstrates how easy it is to use DNS for "out of band" messaging.
In order to make the connection process work, the peers must be coordinated
in time, and share compatible connection parameters.

The time coordination and exchange of parameters is done using DNS messaging.
Each peer "registers" to connect on an "end point" with the connection broker.
The peer identifies the port and IP to use (the SEQ/ACK pair is derived from
this information, in order to minimize the amount of data that needs to be
exchanged). After registering, the peer goes into a "ping" mode, in which
it repeatedly queries the coordinator for status. This is roughly similar to
a server listening on a port.

When the second peer registers on the end point, each side receives a
"CONNECT" response to it's next status "ping". This response contains the
remote peer's port and IP (from which the SEQ/ACK pair are derived), and a
delay counter intended to cause the peers to try and connect within a few
seconds of each other.

The coordinator is implemented using a patched version of BIND9's "named"
program. The hooks that are added watch for requests that include a
familiar segment (*.lb.domain.tld). The "lb" segment is used to indicate
the request should be delegated to the connection broker, and not processed
as part of the normal named DNS query/answer processing.

Once the peers begin the connection sequence, the normal SYN/SYN-ACK/ACK
handshake is replaced with:

Connection Open Sequence

        Initiator                      Peer

t0      ---- S:1000:0 ------->|       |<---- S:2000:0 ---------

t1      ---- SA:1000:2001 --->

t2                                     <----- SA:1001:2000 ----

t3      ---- A:1001:2001 ---->

t4                                     <----- A:2001:1001  ----

tC      ---- 1001:2001 ------>         <------ 2001:1001 ------

At time 0 (t0), both peers send a SYN packet. This packet exits the local
firewall, but is dropped by the remote firewall. This conditions the local
firewall to be in the SYNSENT state, expecting a response from the "server".

At t1, the initiator (chosen based on a function of the two IP/port pairs,
which both sides have knowledge of) sends a SYN/ACK packet. This is allowed
to enter the remote firewall. Why not? It's exactly what's expected by the
peer in response to the SYN that was sent.

At t2, the non-initiator peer sends a SYN/ACK packet. This, from the
perspective of the remote firewall, looks very reasonable and is allowed
through. The unexpected outbound SYN/ACK that was sent at t1 does not affect
this.

At t3 and t4, ACK packets are exchanged to complete the "normal" handshake
and establish the connection. At tC (connected), both sides are operating
in the ESTABLISHED state with the expected SYN/ACK parameters.