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

From: ivan c <[email-masked]>
Date: Tue, 18 Jun 2013 19:25:37 +0200

Hello, 

Does any of you has examples of applications that use a STUNT
server together with an EIM NAT for TCP? 

This is the single purpose
(besides the convenience of the implementation) of having an EIM NAT in the
first place: performing port prediction with the help of a STUNT server.
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.

It would be important to somewhat quantify the usage of this technique in
the wild. 

-- 
_Ivan Chollet_

---

From: Dan Wing <[email-masked]>
Date: Wed, 19 Jun 2013 20:50:11 -0700

On Jun 18, 2013, at 10:25 AM, ivan c <[email-masked]> wrote:

> Hello,
> 
> Does any of you has examples of applications that use a STUNT server together with an EIM NAT for TCP?
> 
> This is the single purpose (besides the convenience of the implementation) of having an EIM NAT in the first place: performing port prediction with the help of a STUNT server.
> 
I don't think you mean 'port prediction' where the software is trying to guess the next-used port ("predicting"), but I believe you mean learning the external IP address and TCP port (by talking to a TCP server on the Internet) and communicating that learned address/port to a rendezvous server of some kind (DNS server, SIP server, game server, whatever).

> 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.

-d

> It would be important to somewhat quantify the usage of this technique in the wild.
> 
>  
> --
> 
> Ivan Chollet
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 21 Jun 2013 02:32:17 +0000

Another example would be ICE support for TCP http://tools.ietf.org/html/rfc6544 using simultaneous-open between ICE TCP candidates exchanged in offer/answer.

--Tiru.
From: Dan Wing (dwing)
Sent: Thursday, June 20, 2013 9:20 AM
To: [email-masked]
Cc: Behave
Subject: Re: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP

On Jun 18, 2013, at 10:25 AM, ivan c <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

-d

--

Ivan Chollet
_______________________________________________
Behave mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/behave

---

From: ivan c <[email-masked]>
Date: Fri, 21 Jun 2013 19:40:28 +0200

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