Re: P2P Filesharing over UDP

--- Saikat Guha <[email protected]> wrote:

> Hi,
>=20
> FYI, I ran into an interesting (and disturbing) P2P filesharing app
> (Rodi) that seems to use UDP and traverses NATs.=20
> http://larytet.sourceforge.net/btRat.shtml
>=20
[suresh] This sounds interesting. I will give this a read.

> It has an interesting approach to UDP NAT Hole-punching that doesn't us=
e
> a _public_ STUN-like server per say.
>=20
> 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 tha=
t
> responded.
>=20
> 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=
.

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

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

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

> The other end replies back with the external IP:port mapping, just as
> STUN would.=20
>=20
> Basically, the approach trades off a public STUN server in exchange for
> a port-scan and full-cone support.
>=20
[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.

> 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.=20
>=20
> Just an FYI.
>=20
[suresh] Cool. This seems to add yet another voice to full-Cone NAT deplo=
yment
in providing flexibility from a P2P application vantage. I.e., this is al=
so
pointing to bi-directional NAT behavior beng preferable to traditional NA=
T
behavior from a P2P application vantage.=20

cheers,
suresh
=20
> --=20
> Saikat =20
> > _______________________________________________
> Ietf-behave mailing list
> [email protected]
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>=20