From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 23:38:01 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0937F16A41F for ; Sun, 27 Nov 2005 23:38:01 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 250D443D49 for ; Sun, 27 Nov 2005 23:37:59 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id jARNbqjc017941 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 00:37:52 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jARNbmrv012760; Mon, 28 Nov 2005 00:37:48 +0100 (MET) Date: Mon, 28 Nov 2005 00:37:48 +0100 From: Daniel Hartmeier To: Julian Elischer Message-ID: <20051127233748.GA7212@insomnia.benzedrine.cx> References: <43894FC9.6040205@elischer.org> <20051127211014.GA31851@uk.tiscali.com> <438A314E.2090403@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438A314E.2090403@elischer.org> User-Agent: Mutt/1.5.10i Cc: net@freebsd.org, Brian Candler Subject: Re: proposal: TCP rendevous X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 23:38:01 -0000 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