[Standards] Do we need STUN?

Sean Egan seanegan at gmail.com
Thu Mar 8 17:44:33 UTC 2007


On 3/8/07, Evgeniy Khramtsov <xramtsov at gmail.com> wrote:
> Do we really need a STUN support in Jingle implementations?

Yes.

> 1) Lack of protocol stability.
> Currently RFC3489 does not have much sense and there are exist only
> deeply drafts of 3489bis.

Could you elaborate a bit on what you mean here? STUN is a very well
supported protocol with a lot of existing implementations. I'm not
sure what you're arguing.

> 2) Lack of integration with XMPP services.
> I don't see any methods how to authenticate XMPP-users on the STUN/TURN
> server.

Right now XEP 176 (The ICE transport) says you should use disco to
locate a STUN server to use. Because you often need more than just a
single STUN server to get through NATs and firewalls, Google Talk uses
a simple "get" protocol to locate a STUN server, relay servers, and
relay server authentication:
http://code.google.com/apis/talk/jep_extensions/jingleinfo.html

In either case, the NAT tunneling has to occur out of band, so even if
you choose to re-invent STUN, you're still going to be faced with this
problem.

> 3) Complexity.
> This is the main problem. I completely disagree with guys who say that
> STUN is simple.
> Furthermore, I think that STUN is *unfairly* complex. I don't see the
> rationality
> of a lot of things.

This may be because you are not an expert at NAT traversal protocols,
and the authors of STUN are. This is exactly the reason XEP 134 says
we should reuse existing protocols in areas outside our core
competencies of XML streaming and instant messaging.

Especially if you consider the subset of STUN required by ICE (ICE
doesn't need to do NAT categorization), STUN is a very simple,
stateless, protocol:just a ping (binding request) and a ping response
(binding response). Implementations of it that I'm familiar with
include Gaim's (http://gaim.svn.sourceforge.net/viewvc/gaim/trunk/libgaim/stun.c?revision=16863&view=markup)
which is 433 lines of C (including NAT categorization) and Google
Talk's (http://libjingle.googlecode.com/svn/trunk/talk/p2p/base/stun.cc)
which is 578 lines of C++.

If you want to convince us that STUN is unfairly complex, you're going
to need to provide some examples of this complexity.

> Also, the RFC3489bis authors are trying to save the
> compatibility with it predecessor:

Could you also elaborate on this?

> no doubt, there are a lot of SIP software with STUN support, but is
> there exist one for XMPP?

STUN happens entirely out-of-band from XMPP, so all the STUN software
written for SIP applications (and other applications that use STUN)
can be used in a Jingle context.

> I just wonder if it possible to modify XEP-0065 and to adapt XEP-0176
> for this.

Adaptng XEP 65 is essentially giving up on the NAT traversal problem.
Trying to come up with something "better" is reinventing the wheel at
the huge cost of incompatibility. NAT traversal is almost at the state
where it can be considered a solved problem, and STUN has long been a
critical part of that solution.



More information about the Standards mailing list