Subject: RE: Effectiveness of STUN protocol

From: "Christian Huitema" <[email-masked]>
Date: Mon, 19 Jan 2004 20:31:09 -0800

> Yes indeed. Probably the #1 biggest use for STUN short term is going
to be
> SIP. It seems like not too much information has to go thru the known
> reachable machine. Maybe just about the same loading as a DNS server?
> 
> So, although its kind of a work around, its probably going to do the
job.
> Does that seem right?

Well, sort off. 

STUN is indeed a great protocol, with all the right authors, but it
makes a couple of assumptions about the type of NATs and about the
structure of the network. 

The assumption about NAT boxes tend to be correct, mostly because
vendors know about STUN and about similar workaround used by various
video-games manufacturers as well as by some IPv6 services (Teredo).
Most new NATs adopt the "cone" or "protected cone" model that work for
STUN, rather than the so call "symmetric" model. But there are still
some old fashioned designs that try hard to break things, so YMMV.

The assumption about topology is more likely to be wrong. STUN works
well in a "core and leaves" model in which privates networks are
directly to a globally addressed IPv4 core, with a single NAT. In this
model, two STUN hosts are either on the same private network, or
connected through the core. Things get much harder when there are
multiple layers of NAT, or when there are backdoor connections between
private networks.

STUN is an OK solution now, but it will stop working when the topology
becomes more complex -- communications will randomly fail. It is just as
easy to deploy IPv6 using Teredo now. As we go on deploying IPv6, we
have a chance to support these more complex topologies.

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Mon, 19 Jan 2004 20:54:15 -0800

> Christian Huitema wrote:
> STUN is indeed a great protocol, with all the right
> authors, but it makes a couple of assumptions about the
> type of NATs and about the structure of the network.

Indeed, but its assumptions are well in line with the predicted
clientele: home/soho.

We were talking about SIP; enterprises do not have too much of a problem
with SIP and NAT, because a) they have a somehow knowledgeable staff b)
they can deploy gateways/proxies/whatever at the edge of their network,
where NAT occurs. If SIPPhone and FWD can deploy SIP proxies, so can
Microsoft, Cisco, and a bunch of others. SIPPhone, FWD and consorts do
already connect together and there are beta tests to connect private
Call Manager domains to them.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 19 Jan 2004 20:59:22 -0800

> Christian Huitema wrote:
> It is just as easy to deploy IPv6 using Teredo now.

Yeah right. Find me a Teredo client (not to mention any IPv6 in the
first place) for

Grandstream:
http://www.grandstream.com/y-product.htm

Or Sipura:
http://www.sipura.com/products/spa2000.htm

The internet is _not_ limited to Microsoft and Cisco, BTW.

Michel.

---

From: [email-masked] (Dan Kolis)
Date: Tue, 20 Jan 2004 11:00:33 -0500

>> Masataka Ohta wrote about STUN
>> Is it a client server app or a P2P app?

Hi.

Well, I read the RFC in some detail, and it is an application which should
be on the public internet side on a stable server. Its "clients" could be
all kinds of processes/apps, from P2P programs mostly, but its a general
resource to decode what a NAT is doing.
          
The RFC reminds the reader there could be lots of transactions sometimes, so
it should be scaled for the purpose.

Regs,
Dan