Subject: [P2Prg] Announcing: TCP NAT Traversal/Hole-Punching Library

From: Saikat Guha <[email-masked]>
Date: Wed, 28 Sep 2005 06:46:12 -0400

Hi all,
(apologies if you get multiple copies of this)

I am pleased to announce the availability of our open-source TCP NAT
Traversal/Hole-Punching library based on our research published in [1].

[1] "Characterization and Measurement of TCP Traversal through NATs 
     and Firewalls", S. Guha and P. Francis. IMC 2005.
http://nutss.net/pub/imc05-tcpnat.pdf

The key result of the paper is: TCP NAT traversal can work 85%-90% of
the time today (without any special assumptions about NATs), and 100% of
the time between pairs of certain popular, well-behaved NATs. See [1]
for more details.

An open-source Java library for TCP NAT Traversal is now available:
 webpage: http://nutss.net/stunt.php
 faq: http://nutss.net/jstunt-faq.php
 library and example: http://nutss.net/jstunt-examples.php

The above library has been tested for pair-wise connectivity across 11
brands of NATs from Windows and Linux hosts. NATs tested were Linksys,
DLink, Netgear, Belkin, 3Com, Netopia, Allied Telesyn, SMC, Trendnet,
USR, Buffalo Tech. Out of the 121 possible pair-wise combinations, 113
connections are successful. The only ones that failed are when both the
endpoints are behind the _same_ NAT device that does not support TCP
hairpin-behavior yet (see [1]). 

The java library is released under LGPL; contact me if this does not
meet your needs. Feel free to extend it/port it etc.

Q: I am a P2P developer/researcher. How does this help me?
A: The library adds TCP NAT traversal out-of-the-box. This increases the
connectivity in your P2P network since two users behind their NATs can
now exchange data without having to go through an intermediary node. You
can:
- Use this library as is (for development of P2P software, research,
  small deployments, etc in java)
- Study it to provide TCP NAT Traversal in your existing P2P
  applications in your language of choice.
- etc.

If you have any questions, comments, suggestions, or problems, do not
hesitate to contact me. Cheers,
-- 
Saikat
_______________________________________________
P2prg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2prg

---

From: Bill Yeager <[email-masked]>
Date: Thu, 29 Sep 2005 08:47:37 -0700

Hello,

I forgot to Cc: the RG on my message to which this is a response.

By the way, Saikat, et. al.'s paper is excellent reading.

Bill

From: Saikat Guha <[email-masked]>
Date: September 28, 2005 10:29:44 PM PDT
To: Bill Yeager <[email-masked]>
Subject: Re: [P2Prg] Announcing: TCP NAT Traversal/Hole-Punching Library

On Wed, 2005-09-28 at 19:01 -0700, Bill Yeager wrote:

> Hello Saikat,

Hi Bill,

> how someone discovers the external IP address of my NAT.
> It seems to me that one needs a third party in the open internet to
> aid in this process.
>

You are absolutely correct. There needs to be some sort of rendezvous
mechanism in place (such as SIP). STUNT and the other TCP traversal
approaches assume the UDP STUN model of deployment where there is a
public STUN server that assists in discovering the external IP and port,
call this a STUNT server that echoes back the IP address and TCP port.
In addition, there is a public rendezvous service, like a SIP proxy
network operated by the VoIP company that sold the IP-phone that uses
STUN in the first place.

> This also implies my systems behind NAT need a  unique identity (name)
>

Absolutely. The unique name can be any application level identifier that
the rendezvous service understands. For SIP, it would be a SIP URI, or
an email address, or a registered username etc.

> That way we can have a 3rd party name service in the
> Internet that can dynamically respond to name to address lookups as
> well as give the current external IP address of the NAT box.
>

Yes. The library I posted, by default, uses the STUNT service and
rendezvous service I am running here at Cornell for p2p developers and
researchers. We envision that as applications (like BitTorrent) buy into
NAT traversal, parts of the application will provide this service (e.g.
the BT trackers) for the rest of the application (BT clients).
Eventually, if this becomes necessary for a large fraction of
applications, it would spin off a DNS-like global infrastructure that
provides this service for all applications (SIP is already geared to
fill that role).

> Finally, of course, I do not want my firewall/NAT to let external TCP
> SYN's pass through do I.
>

Very true. There are two points of concern here. First, whether or not
can anyone initiate an unsolicited connection (send you a SYN). That is
not possible since the NAT/firewall, by default, is blocking all
incoming SYNs just as it does today (we do not modify the NAT/firewall
for TCP traversal). The only time a SYN is allowed in (during the STUNT
exchange) is when both ends have explicitly consented to accept the
connection by each sending their outbound SYNs first. So it is
impossible for a remote host to send an _unsolicited_ SYN.

The second concern is that once a connection has been established, can
someone else send a SYN. That is much like the situation today -- once
your webbrowser connects out, can someone else send a SYN through the
mapping established at the NAT. Most security conscious NATs (Type
EF:Address and Port in the paper) block such incoming SYNs.

So in either case, the approaches do not compromise security any more
than what already exists today.

> Otherwise, sure, your paper makes good sense, and is an excellent  
> read.
>

Thanks. :)

-- 
Saikat