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

["Karl Stahl" <[e-mail]>]

In this multiple methods discussion, what about this WebRTC use case that I
think will be common:

An enterprise installs a TURN server with one LAN-port (paralleling its
firewall), because it wants to use WebRTC but maintain a restrictive
firewall policy, that stops WebRTC media or it wants to have a better media
path than through his ordinary data crowded Internet access.

Would it then be sufficient to add a route in its ordinary firewall, so the
anycast-address goes to that local TURN-server - and the Web-browsers really
use that path?

I don't see the enterprise wanting to set up other discovery methods also.

/Karl


-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]] 
Skickat: den 20 maj 2014 09:14
Till: Karl Stahl; Prashanth Patil (praspati); [e-mail]; 'Simon
Perreault'
Ämne: RE: [tram] New Version Notification for
draft-patil-tram-turn-serv-disc-01.txt

> -----Original Message-----
> From: tram [mailto:[e-mail]] On Behalf Of Karl Stahl
> Sent: Tuesday, May 20, 2014 3:58 AM
> To: Prashanth Patil (praspati); [e-mail]; 'Simon Perreault'
> Subject: Re: [tram] New Version Notification for 
> draft-patil-tram-turn-serv-disc- 01.txt
> 
> I read "We'll probably need both if we want to maximize chances of 
> discovery." in the draft also, but don't really get it.

With Secure DHCPv6 with Public Key
http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02, DHCP has benefits
over Anycast.
But since DHCP is not workable in some cases, clients may end-up using both
the techniques (for e.g. use happy-eyeball mechanism) and give precedence to
TURN server learnt using secure DHCP.

> 
> Do you mean that if the network provider offers one particular TURN 
> server to his network users, that TURN server should be advertised in 
> both suggested ways?

Yes

-Tiru

By maximize, the draft really means discovering servers that may not support
all discoverable methods. For example, if a provider already has TURN
application service provisioned in DNS (as in RFC5928), it can be readily
discovered without needing anycast.

-Prashanth

> 
> /Karl
> 
> -----Ursprungligt meddelande-----
> Från: tram [mailto:[e-mail]] För Prashanth Patil 
> (praspati)
> Skickat: den 19 maj 2014 20:12
> Till: Karl Stahl; [e-mail]; 'Simon Perreault'
> Ämne: Re: [tram] New Version Notification for 
> draft-patil-tram-turn-serv-disc-01.txt
> 
> Hi Karl,
> 
> On 5/18/14 6:13 PM, "Karl Stahl" <[e-mail]> wrote:
> 
> >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.
> 
> I think the decision should be left up to the application. We could, 
> maybe, make a recommendation at best (i.e. it is not a MUST).
> 
> 
> >
> >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?
> 
> There are essentially 2 methods described in the draft (1) Service 
> resolution and (2) Anycast. We'll probably need both if we want to 
> maximize chances of discovery.
> DHCP happens to be one method to obtain the domain-name for (1) 
> Service resolution. While the DHCP method may not workable in some 
> cases, the other two methods (one of them inspired by 
> draft-kist-alto-3pdisc) could offer better results. We can do away with
DHCP,  if that is the WG consensus.
> 
> 
> >
> >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?
> 
> Anycast may fail, too.
> 
> 
> >
> >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)?
> 
> Given that there is a service resolution mechanism for TURN over DTLS 
> (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it 
> seems useful to do service resolution before.
> 
> >
> >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery
> >is now RFC7216.
> 
> Thanks, will update.
> 
> -Prashanth
> 
> 
> >
> >/Karl
> >
> >
> >-----Ursprungligt meddelande-----
> >Från: tram [mailto:[e-mail]] För Prashanth Patil
> >(praspati)
> >Skickat: den 2 maj 2014 12:02
> >Till: [e-mail]
> >Ämne: [tram] FW: New Version Notification for 
> >draft-patil-tram-turn-serv-disc-01.txt
> >
> >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, "[e-mail]"
> ><[e-mail]>
> >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
> >>.tx
> >>t
> >>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
> >>
> >
> >_______________________________________________
> >tram mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/tram
> >
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram