Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-00.txt

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 09:31:41 -0400

I've read over the latest draft, and I think it's looking good re: the 
discovery mechanisms. The only comment I had about that on the original 
draft was resolved (i.e. sending "Try Alternate" error for allocate 
requests to an anycast address).

I would still like to see some discussion in "Security Considerations" 
about the use of (D)TLS in the context of auto-discovered relay servers, 
especially those that use the global anycast address. It's important to 
make sure that client implementers carefully consider what degree of 
privacy their users are getting from (D)TLS. There was a fair amount of 
on-list discussion about this back in late March, and I think it would 
be good to capture some of the outcomes from that thread in the draft.

--Brandon

On 07/24/2014 09:21 AM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the TURN Revised and Modernized Working Group of the IETF.
>
>          Title           : TURN Server Auto Discovery
>          Authors         : Prashanth Patil
>                            Tirumaleswar Reddy
>                            Dan Wing
> 	Filename        : draft-ietf-tram-turn-server-discovery-00.txt
> 	Pages           : 11
> 	Date            : 2014-07-24
>
> 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, the network in which 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 4 Sep 2014 12:54:08 +0000

Hi Brandon,

>be good to capture some of the outcomes from that thread in the draft.

Should details regarding degree of privacy obtained from (D)TLS have been
captured in RFC 7350 instead?

Since the intention of the draft was to only describe means to discover
TURN servers, 'Security Considerations' only discusses security aspects of
those means.

Having said that, we could certainly add some text in security
considerations based on discussion on the list.

-Prashanth

---

From: Brandon Williams <[email-masked]>
Date: Thu, 04 Sep 2014 09:25:41 -0400

I think security considerations that really only apply to cases where 
auto-discovery is used would be good to call out in the auto-discovery 
draft, especially considering the fact that the drafts related to (D)TLS 
are already published as RFCs.

--Brandon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 10 Sep 2014 09:43:00 +0000

>are already published as RFCs.

Sure, we'll call this out in the next revision.

-Prashanth

>>>>    This draft is a work item of the TURN Revised and Modernized
>>>>Working
>>>> Group of the IETF.
>>>>
>>>>      configuration.  These are usually under the administrative
>>>>control
>>>> of