[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Peter Saint-Andre stpeter at jabber.org
Wed Mar 28 02:54:57 UTC 2007

Kai Vehmanen wrote:
> Hi,
> btw, as a general comment, the ICE/TURN/STUN specs were reviewed
> last week in IETF68, and unlike in all previous meetings, no major 
> issues were raised in the documents anymore. It is expected that the specs 
> will go to last call (final review before publication as RFCs) soon-ish.

Yes, it seems that ICE-15 will be the release candidate.

> On 26 March 2007, Thiago Camargo wrote: 
>> 3> Client ask XMPP Server to allocate a Relay Channel on the 
>> selected Relay Server. Then server returns the IP address, 
>> password and port pair.
>> With this approach clients don't need to negotiate the 
>> allocation of a relay directly to a relay server.
> Alternative proposal:
> - client acquires short-term credentials with XMPP means (plus maybe
>   also the IP address and port of the relay)

Presumably the XMPP server and the TURN server need to have a shared 
secret or some way of negotiating credential requests.

> - client uses standard STUN/TURN procedure to allocate
>   a relay port and uses the acquired short-term credentials (username
>   plus password used as a key for the message-integrity field) for 
>   authentication
> To me, this is as simple as the mechanism you described, but
> with the added bonus that the service provider can use 
> an off-the-shelf TURN server. 

Off-the-shelf is a plus. We don't want to be off in our little XMPP 
ghetto here.

> I admit there are very few of these
> servers out there at the moment, but now that the specs are about 
> to be finished, that situation is certain to change.

By "out there" do you mean implemented or deployed? Given the bandwidth 
requirements for relay servers, I think a lot of XMPP service providers 
will have a hard time justifying deployment of a TURN server. I know we 
would at the XSF (barring a move to a new hosting service).

> Plus you get some bonuses:
>   - ability to use TCP, or TLS-over-TCP framing on the client-relay hop
>   - support for end-to-end TCP relaying
>   - various mechanism designed to protect the relay against
>     DoS attack attempts
>   - IPv6 ready

Those are all good things.


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070327/0bb403fa/attachment.bin>

More information about the Standards mailing list