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
- [BEHAVE] p2p applications using STUNT and EIM NAT… ivan c
- Re: [BEHAVE] p2p applications using STUNT and EIM… Dan Wing
- Re: [BEHAVE] p2p applications using STUNT and EIM… Tirumaleswar Reddy (tireddy)
- Re: [BEHAVE] p2p applications using STUNT and EIM… ivan c