proposal: TCP rendevous

[Daniel Hartmeier]

On Sun, Nov 27, 2005 at 02:21:02PM -0800, Julian Elischer wrote:

> yes, which means it might unexpectedly fail.

I don't see how it can be done with TCP, assuming both peers are behind
NATing firewalls (like pf).

Some tricks to consider are:

Let one peer send a SYN through the firewall towards the other peer, but
set the TTL low, so the firewall creates a state entry but there will be
no RST from the peer tearing down the state entry (the TTL-exceeded ICMP
error is not a problem).

The NATing firewall will pick a random source port as replacement and
might even randomize the sequence numbers (as in pf's "modulate state").
Can the first peer find out what source port and ISN was chosen, so it
can relay the information to an external third party?

One idea would be to craft an ICMP error sent by the first peer, say a
fake TTL-excceded message. In the inner IP and TCP header (the one in
the ICMP payload), pretend that the first peer received a SYN+ACK from
the second peer, and that the second peer chose the very same ISN as the
first peer. But in the outer IP header, set the destination address to
the external third party. This would pass pf's state engine and pf would
demodulate the sequence number quoted in the payload. Hence, the
external third party would receive both the random source part and the
externally visible ISN of the first peer. It could then relay that
information to the second peer.

But here comes the problem. The second peer could similarly send a
low-TTL SYN to create a state entry on his firewall, and then pass out a
SYN+ACK to the first peer's port and ack'ing the proper ISN. But the
firewall would similarly pick a random source port replacement for the
second peer, which wouldn't match what the first peer picked as initial
destination port.

In short, the random NAT source ports are only decided when the first
packet is sent. But the first packet already needs to contain the other
peer's port.

Which puts us back to square one ;)

Daniel