Subject: [Ietf-behave] P2P Filesharing over UDP

From: Saikat Guha <[email-masked]>
Date: Tue, 7 Jun 2005 15:40:03 -0700 (PDT)

Hi,

FYI, I ran into an interesting (and disturbing) P2P filesharing app
(Rodi) that seems to use UDP and traverses NATs. 
http://larytet.sourceforge.net/btRat.shtml

It has an interesting approach to UDP NAT Hole-punching that doesn't use
a _public_ STUN-like server per say.

The first Rodi client opens a UDP hole in the NAT. It does so by
initiating a UDP port-scan to some destination from a fixed local port.
It waits for one response packet. (at present finding the response
packet is manual; but can easily be automated). To keep the UDP hole
open, it keeps sending UDP packets at a low rate to the remote port that
responded.

Subsequent Rodi clients perform a port scan on a remote address as
before. If the address is a NAT'ed Rodi client (that has already
performed step 1 above), then one of the port-scan packets make it
through to the other end. This is assuming the NAT is Full Cone for UDP.
The other end replies back with the external IP:port mapping, just as
STUN would. 

Basically, the approach trades off a public STUN server in exchange for
a port-scan and full-cone support.

As a side note, its main mandate is to transfer files while being
indistinguishable from other traffic (Rodi packets can be made to look
like DNS, RTP etc). The default transport protocol of choice is UDP. :-/
It seems to implement its own "Rate Limiter (RL)" to provide congestion
control, but I can't seem to find how the RL works or how TCP-friendly
it is. 

Just an FYI.

-- 
Saikat  
Attachment:
signature.asc

---

From: Marc Manthey <[email-masked]>
Date: Wed, 8 Jun 2005 08:50:43 -0700 (PDT)

On Jun 8, 2005, at 12:39 AM, Saikat Guha wrote:
As a side note, its main mandate is to transfer files while being
indistinguishable from other traffic (Rodi packets can be made to look
like DNS, RTP etc).
hello saikat, great information thank you very much
i am looking  for  connection mechanism for open cuseeme.
as far as i see  the method  looks very similar .
provide congestion control
can you tell me more  about this ?

regards

marc

www.cuseeme.de
********************************************************
opencuseeme /  peer2peer multiparty conferencing
********************************************************
Attachment:
smime.p7s

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 19 Jun 2005 15:04:46 -0700 (PDT)

> http://larytet.sourceforge.net/btRat.shtml
[suresh] This sounds interesting. I will give this a read.

> through to the other end. This is assuming the NAT is Full Cone for UDP.

[suresh] I am not sure, I understand you correctly in your above comment about
assuming Full-Cone NAT. Is the following what you meant?  

It seems, if  the rodi clients (i.e., file-xfering subscrbers) are all behind
NAT device, then the NAT device just needs to be an Address restricted Cone
NAT. 

However, if the destination address (i..e, file-providing publishers) happen to
be behind a NAT, then the algorithm would only work if the NAT were a full cone
NAT. Right?

> a port-scan and full-cone support.
[suresh] Right. If I understood what you said correctly, You dont need an
external public server to get a list of file sharers behind NAT devices, when
the NAT devices exhibit full-Cone NAT behavior.

> control, but I can't seem to find how the RL works or how TCP-friendly
[suresh] Cool. This seems to add yet another voice to full-Cone NAT deployment
in providing flexibility from a P2P application vantage. I.e., this is also
pointing to bi-directional NAT behavior beng preferable to traditional NAT
behavior from a P2P application vantage. 

cheers,
suresh
 
> -- 
> Saikat  
> > _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: David Barrett <[email-masked]>
Date: Sun, 19 Jun 2005 16:42:37 -0700 (PDT)

Pyda Srisuresh wrote:
--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:
Subsequent Rodi clients perform a port scan on a remote address as
before. If the address is a NAT'ed Rodi client (that has already
performed step 1 above), then one of the port-scan packets make it
through to the other end. This is assuming the NAT is Full Cone for UDP.
Just curious, how "broad" is this port scan?  Does it do a total 
portscan (ie, of the complete range of possible UDP ports), or pick a 
subset that it somehow knows will work?

It'd seem that firewalls and routers would quickly identify this type of 
traffic as malicious, and then block the scan from completing.  Does 
Rodi do anything to somehow evade being flagged and blocked as such 
(maybe random delays or non-sequential scanning)?

Regardless, thanks for the great Rodi overview.  I agree this is further 
evidence that full-cone is the most P2P friendly, address-restricted 
less so, and symmetric even less than that.  The closer we can get to a 
total full-cone world (or even just a non-symmetric world), the better.

-david

---

From: Saikat Guha <[email-masked]>
Date: Tue, 21 Jun 2005 11:23:06 -0700 (PDT)

> subset that it somehow knows will work?

Last I looked into it, it asked the user to specify the range. For it to
work with existing NATs, this would be 1024--65536.

-- 
Saikat
Attachment:
signature.asc

---

From: Saikat Guha <[email-masked]>
Date: Tue, 21 Jun 2005 11:38:59 -0700 (PDT)

> assuming Full-Cone NAT. Is the following what you meant?  

If both the publisher and subscriber know of each other, then any kind
of NAT works (the algorithm basically degenerates to STUN with port-
scanning to traverse symmetric NATs). If the publisher is unaware of the
subscriber then, as far as I understand, the publisher needs to be
behind a full cone since the application does not implement any sort of
out-of-band signaling to get the publisher to punch a hole for that
specific subscriber in his NAT. Not sure if I answered your question.

> the NAT devices exhibit full-Cone NAT behavior.

I do not know how peers discover each other and find the file sharers.
You are correct in that Rodi does not have a central rendezvous server
(perhaps it has some gossip based discovery like gnutella, or the user
points it to the file server like in Bittorrent). What I was getting at
was that it doesn't use a public STUN server to discover its own
mapping.

> in providing flexibility from a P2P application vantage. 

True, but the only thing that supports full-cone is the port-scan. If
instead of the port-scan it implements a port-and-address scan then it
would work with restricted cone as well. That said, as Christopher and
David pointed out, port-scans are rarely welcomed by users and
administrators.  

-- 
Saikat
Attachment:
signature.asc

---

From: David Barrett <[email-masked]>
Date: Tue, 21 Jun 2005 16:10:11 -0700 (PDT)

On Tue, 21 Jun 2005 11:33 am, Saikat Guha wrote:
Last I looked into it, it asked the user to specify the range. For it 
to
work with existing NATs, this would be 1024--65536.
Huh.  I assumed a total portscan would raise all sorts of alarms and get 
blocked.  Interesting.

-david