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

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 2 May 2014 10:02:00 +0000

A new revision of the TURN server discovery draft has been published.
Notable updates :

* 300 (Try Alternate) response for anycast.
* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients own
address to populate the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa)
with appropriate NAPTR records pointing to the TURN server.
* Learning domain names from own identity.

-Prashanth

On 5/2/14 3:25 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt
>has been successfully submitted by Prashanth Patil and posted to the
>IETF repository.
>
>Name:		draft-patil-tram-turn-serv-disc
>Revision:	01
>Title:		TURN Server Auto Discovery
>Document date:	2014-05-02
>Group:		Individual Submission
>Pages:		11
>URL:            
>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.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-01
>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01
>
>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.
>
>                  
>        
>
>
>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: Paul Kyzivat <[email-masked]>
Date: Fri, 02 May 2014 14:43:56 -0400

There is another possible mechanism for retrieving a domain name for 
service discovery that isn't mentioned. It is analogous to "From own 
Identity". I guess I would call it "From target identity". In the case 
of SIP it would be to use the domain name of the To-URI.

This would be useful when a domain wants to make itself be reachable 
even from clients that have no better way of discovering a TURN server.

In general it is probably better to use one of the other techniques when 
possible, because the result can be used to talk to any target. But this 
is still a good option when the others fail. And it should be attractive 
to servers that want to maximize their reachability.

(I mentioned this one before, some time ago, but I guess it got lost 
along the way.)

Is there any reason not to include this as 4.1.4?

	Thanks,
	Paul

On 5/2/14 6:02 AM, Prashanth Patil (praspati) wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 6 May 2014 13:55:45 +0000

>Is there any reason not to include this as 4.1.4?

The intent was to provide best possible means to discover TURN offered by
your domain/network, 'from target identity' was hence not included.

Not necessarily within the scope of server discovery, but on what basis
would the TURN server from target domain allow requests from unknown users?

-Prashanth

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 14:02:51 -0400

> your domain/network, 'from target identity' was hence not included.

I didn't see anything in the description of service discovery that 
limited it that way.

> would the TURN server from target domain allow requests from unknown users?

What I had in mind was that this service could be provided by the target 
domain for the benefit of those attempting to reach it. The goal being 
to maximize its reachability, even from clients that cannot discover a 
turn service at the source end.

I guess what you are suggesting is that somebody might abuse this, 
discovering this TURN server and then using it to contact some unrelated 
party.

I haven't thought about it a lot, but perhaps it could arrange to only 
work when the other end is within the domain it supports.

	Thanks,
	Paul

---

From: Simon Perreault <[email-masked]>
Date: Tue, 06 May 2014 18:13:13 -0400

> work when the other end is within the domain it supports.

The problem is the server doesn't know who the other end is when it
receives an allocate request...

Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Sun, 18 May 2014 14:43:36 +0200

I browsed through this document and to me it looks mature enough to be 
pushed forward (hopefully soon) to get an IANA anycast address etc., so 
these things can be put into current WebRTC browsers. As we know, many 
enterprises cannot use WebRTC at all today due to their restrictive 
firewall policies - they need a TURN server on their LAN, discovered 
and used by the WebRTC browsers to even begin using WebRTC.

However, I raised a few questions and some suggestions 
http://www.ietf.org/mail-archive/web/tram/current/msg00480.html 
at the end of the previous version of this draft that never became 
discussed and remain:

A) Under 8.2 there is a suggested way to assure that the TURN server 
returned by the anycast method, is provided by the network 
provider (and not some far away TURN server that should not be trusted 
to use without authentication): "... can set an IP TTL on their TURN 
requests that limits how far they can travel into the public Internet."

I suggest that this TTL limitation is specified (e.g. Don't look further 
than 3 steps - local firewall + max 2 ISP routers) and brought into 
section "5. Discovery using Anycast" of the draft.

B) Shall we really have more than one method? If the Anycast method can 
be used by everyone, why then also have DHCP and now a two more methods?

I assume you intend that all webrtc browsers implement and can use all 
methods? Or? (If a service provider e.g. deploys DHCP discovered TURN 
servers, but some webrtc browser in some operating system don't 
find/cannot use the TURN server, it would be bad.)

In previous discussions, there were some fears that DHCP options are 
not available in some common OSs. If so, I think the DHCP method should 
be skipped. 

Also, if the other methods (other than anycast) may fail, why have them? 
Are they better to deploy and provision for network service providers?

And will webrtc browsers implement all these methods?

Do we have input/feedback on these questions?

Should the "connect speed factor" not also be considered? Even though 
the auto discovery can be done in advance of a call, we should consider 
the mobility use case. With a mobile client changing network, 
LAN/LTE/public WiFi etc., we want to get up and run as soon as possible, 
so the auto discovery of a new TURN server should not be a tedious process

And should the quick anycast auto discovery not be the first to be 
tried/used (which it is not now in the draft)?

C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery 
is now RFC7216.

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Prashanth Patil (praspati)
Skickat: den 2 maj 2014 12:02
Till: [email-masked]
Ämne: [tram] FW: New Version Notification for
draft-patil-tram-turn-serv-disc-01.txt

-Prashanth

On 5/2/14 3:25 PM, "[email-masked]" <[email-masked]>
wrote:

>submission until the htmlized version and diff are available at 
>tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Brandon Williams <[email-masked]>
Date: Mon, 19 May 2014 04:47:45 -0400

I'm not sure how realistic it is to define a specific TTL limitation. 
That assumes a perhaps unrealistic degree of uniformity in both the 
local network implementation and the ISP network implementation.

Regarding whether multiple methods should be in the spec, one other 
important question to answer is whether all of the proposed methods have 
identical security properties. There were some security limitations for 
anycast (at least the well-known-address version) discussed on the list. 
These security limitations still need some discussion in the draft.

Regarding connect time, in what way is the anycast method faster than 
name resolution? Under some conditions it may be faster, but typically 
it will require an extra round-trip between the client and the anycast 
address just as name resolution will require a round-trip between the 
client and the DNS server.

--Brandon

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

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 19 May 2014 13:05:19 +0200

> require a round-trip between...
- I wasn't concerned about round-trips, but rather possible time-outs when
there is nothing to find - I haven't really checked (concerned about that we
don't specify something slow creating a need to trickle or something)

Regarding multiple methods and TTL limitation, is the intention of this
draft that it may/could be used by rtcweb as:
"... webrtc browsers MUST use turn servers discovered by the anycast method
in draft-patil-tram-turn-serv-disc-01.txt with TTL limitation set to 3..." ?

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Brandon Williams
Skickat: den 19 maj 2014 10:48
Till: [email-masked]
Ämne: Re: [tram] New Version Notification for

I'm not sure how realistic it is to define a specific TTL limitation. 
That assumes a perhaps unrealistic degree of uniformity in both the local
network implementation and the ISP network implementation.

Regarding connect time, in what way is the anycast method faster than name
resolution? Under some conditions it may be faster, but typically it will
require an extra round-trip between the client and the anycast address just
as name resolution will require a round-trip between the client and the DNS
server.

--Brandon

On 05/18/2014 08:43 AM, Karl Stahl wrote:
> pushed forward (hopefully soon) to get an IANA anycast address etc., 
> so these things can be put into current WebRTC browsers. As we know, 
> many enterprises cannot use WebRTC at all today due to their 
> restrictive firewall policies - they need a TURN server on their LAN, 
> discovered and used by the WebRTC browsers to even begin using WebRTC.
>
> returned by the anycast method, is provided by the network provider 
> (and not some far away TURN server that should not be trusted to use 
> without authentication): "... can set an IP TTL on their TURN requests 
> that limits how far they can travel into the public Internet."
>
> I suggest that this TTL limitation is specified (e.g. Don't look 
> further than 3 steps - local firewall + max 2 ISP routers) and brought 
> into section "5. Discovery using Anycast" of the draft.
>
> B) Shall we really have more than one method? If the Anycast method 
> can be used by everyone, why then also have DHCP and now a two more
methods?
> not available in some common OSs. If so, I think the DHCP method 
> should be skipped.
>
> the auto discovery can be done in advance of a call, we should 
> consider the mobility use case. With a mobile client changing network, 
> LAN/LTE/public WiFi etc., we want to get up and run as soon as 
> possible, so the auto discovery of a new TURN server should not be a 
> tedious process
>
> * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients 
> own address to populate the DNS reverse zone (i.e., in-addr.arpa or 
> ip6.arpa) with appropriate NAPTR records pointing to the TURN server.

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

---

From: Brandon Williams <[email-masked]>
Date: Mon, 19 May 2014 08:22:28 -0400

I would be more concerned about anycast timing out than DNS. If the dns 
server exists but has no answer, it will tell you. I think you would 
only need a timeout for non-existent DNS servers. On the other hand, the 
only way you know that the anycast address doesn't work is a timeout 
waiting for a response. You could use an ICMP ttl-exceeded response, but 
they aren't reliably sent or delivered.

I would argue strongly against MUST for supporting anycast, because of 
the security issues that have been raised. I would say SHOULD support, 
and those that do MUST allow users to define security policies that 
prohibit using anycast.

--Brandon