Re: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP

ivan c <ivan@cacaoweb.org> Fri, 21 June 2013 17:39 UTC

Return-Path: <ivan@cacaoweb.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2921F9F8B for <behave@ietfa.amsl.com>; Fri, 21 Jun 2013 10:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW0k7Vf5Mwww for <behave@ietfa.amsl.com>; Fri, 21 Jun 2013 10:39:37 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id DA2A321F9F8F for <behave@ietf.org>; Fri, 21 Jun 2013 10:39:36 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1Uq5K0-000836-85; Fri, 21 Jun 2013 19:40:28 +0200
To: Dan Wing <dwing@cisco.com>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_29953c12b941797c1a2ce71d1ca8a83b"
Date: Fri, 21 Jun 2013 19:40:28 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <6728C5CA-F1DD-4564-A218-E4809BF92B6F@cisco.com>
References: <cede1171c9c67a89094bab7eeadcadfa@cacaoweb.org> <6728C5CA-F1DD-4564-A218-E4809BF92B6F@cisco.com>
Message-ID: <d3e9c266ec71951b4523bd67415af838@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Cc: Behave <behave@ietf.org>
Subject: Re: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2013 17:39:42 -0000


On Wed, 19 Jun 2013 20:50:11 -0700, Dan Wing  wrote:    

Surprisingly,
I am not aware of any applications that rely on that. All the p2p
applications that I know of use different techniques for TCP Hole Punching
or use other alternatives, such as UPnP, port forwarding, etc.  I found
this discussion of folks utilizing TCP hole punching (as I summarized
above) for their projects,
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d82f5cd9-b33c-4ea6-aeef-e489750021e4/tcp-simultaneous-open-for-tcp-hole-punching
[1].   

That's what I mean, besides proof-of-concepts and academic
discussions, this does not seem to have found a use so far in any
real-world application. 

It is easy to see if any application uses it:
check TCP connections with tcpdump/wireshark, if you see that each
connection is "doubled" by a previous one on the same local endpoint, this
is very likely to be STUNT. 

Here are the reason why this technique didn't
get much love so far: 

1) It requires a STUNT server for *each* outgoing
TCP connection. 

This is in opposition to STUN (for UDP NAT traversal)
where the server is typically only needed once, to discover the external
port. After that the application re-uses the same UDP socket for its whole
lifetime.
Using a STUNT server (for TCP NAT traversal) doesn't scale well
for very large p2p networks that can have millions of peers and billions of
TCP connections / day. Additionally, a TCP connection costs a lot more to a
server than a UDP session. The server needs to keep state in TCP, in UDP it
does not. 

* a STUNT server *has to* be used for each TCP session / a STUN
server need only to be used once, as applications multiplex their UDP
sessions over the same socket
* lots of TCP connections cost a lot for a
STUNT server 

2) It requires setting up the SO_REUSEADDR on all sockets


Besides SO_REUSEADDR being an unspecified characteristic of POSIX, it
should be noted that what it does on systems that support it is bypass
completely the TIME_WAIT state. It means TIME_WAIT state doesn't last
2*MSL, or a bit less, it means it does not exist anymore.
If SO_REUSEADDR
is used on all the sockets of all p2p apps of a system, what you get is
TIME_STATE that is bypassed for all your sockets. As soon as a local
endpoints are reused, and this is very likely to happen if the system is
busy, you introduce the possibility of data corruption (a new connection
will happily accept an old TCP segment). So the application would have to
build a layer to protect against data corruption. Not ideal and goes
against OSI layers isolation, breaks TCP data corruption provisions, etc.


This is what happens when you mess with the TCP protocol. 

Again, this
is just to explain why the STUNT technique for TCP NAT traversal has not
seen much use. I would still consider it a useful technique that NATs
should try to support if they can, after all it is up to the applications
to choose what they are comfortable with. But not present it as the only
available technique, this is misleading and dangerous. 

-- 
_Ivan
Chollet_
 

Links:
------
[1]
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d82f5cd9-b33c-4ea6-aeef-e489750021e4/tcp-simultaneous-open-for-tcp-hole-punching