Subject: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 11 Feb 2014 05:26:48 +0000

This document describes two mechanisms to auto discover TURN server. Please review and provide your valuable comments.

-Authors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 11, 2014 10:50 AM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Dan Wing (dwing); Prashanth Patil (praspati)
Subject: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt

A new version of I-D, draft-patil-tram-turn-serv-disc-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository.

Name:		draft-patil-tram-turn-serv-disc
Revision:	00
Title:		TURN Server Auto Discovery
Document date:	2014-02-11
Group:		Individual Submission
Pages:		9
URL:            http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-00.txt
Status:         https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/
Htmlized:       http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-00

Abstract:
   Current Traversal Using Relays around NAT (TURN) server discovery
   mechanisms are relatively static and limited to explicit
   configuration.  These are usually under the administrative control of
   the application or TURN service provider, and not the enterprise or
   the ISP on whose network the client is located.  Enterprises and ISPs
   wishing to provide their own TURN servers need auto discovery
   mechanisms that a TURN client could use with no or minimal
   configuration.  This document describes two such mechanisms for TURN
   server discovery.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Feb 2014 09:17:36 -0500

> This document describes two mechanisms to auto discover TURN server. Please review and provide your valuable comments.

Nice. A few comments/questions...

1. Does WPAD play any role in this? Why/why not? (DHCP options are often
inaccessible/very hard to get to from end-user applications, namely
browsers.)

2. About the anycast mechanism:

   When a client requires TURN services, it sends a TURN allocate
   request to the assigned anycast address.  The responding TURN anycast
   server puts its own unicast address as the source address in the
   reply message.

That won't work because it won't get through most firewalls and many
NATs. The response's 5-tuple has to be the same as the request's.

I suggest you look into the 300 (Try Alternate) response mechanism. The
response would contain the unicast address in an ALTERNATE-SERVER
attribute. See also RFC 5766 section 2.9.

3. It would be nice to make anycast work with TCP.

4. In the IANA Considerations section, it seems you are requesting a
single IPv4 address and a single IPv6 address. If we want anycast to
work across AS boundaries, we need to request a /24 and a /48,
respectively. I think we want that, so that TURN service can easily be
provided by a third party. (On the other hand, single addresses are
interesting security-wise in that they won't travel very far in BGP.)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 11 Feb 2014 17:40:35 +0000

Hi Simon,

On 2/11/14 7:47 PM, "Simon Perreault" <[email-masked]> wrote:

>> This document describes two mechanisms to auto discover TURN server.
>>Please review and provide your valuable comments.
>

For WPAD, my understanding is that some browsers use DHCP Inform to
request and obtain information from a DHCP server for use in their local
configuration.
WPAD is a viable option, given that it's used quite a bit. I suppose we
could suggest it as an option in the draft, but WPAD is not standardized.

>attribute. See also RFC 5766 section 2.9.

Good point, will update.

>3. It would be nice to make anycast work with TCP.

Yep. However, do we really need it in the context of discovery? If a
client can discover a server using UDP, the client can choose to
subsequently contact the same server over TCP.

>interesting security-wise in that they won't travel very far in BGP.)

-Prashanth

>_______________________________________________
>tram mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tram

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Feb 2014 13:13:25 -0500

> subsequently contact the same server over TCP.

Right, that would be one possible method. One drawback would be that it
would confuse the _tcp and _udp SRV stuff, and servers would be forced
to provide TCP and UDP service on the same address(es).

Another possibility would be to just go ahead and do discovery over TCP.
I don't think routing stability would be an issue for such a short-term
session.

Simon