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

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

Hi Tiru, you misinterpreted the use case, let me clarify.

Because there are restrictive firewalls (or other reasons) that media cannot
get THROUGH (as you report below), as a solution we PARALLEL that firewall
with a TURN server having one LAN and one WAN interface, where the TURN
server at the LAN interface is offered to the enterprise LAN users to be
used without further authentication.

This is (part of) use case "3.3.5.  Simple Video Communication Service,
enterprise aspects" in draft-ietf-rtcweb-use-cases-and-requirements-14.txt :
"TURN server that straddles" ... "It must be possible to configure the
browsers used in the enterprise with network specific STUN and TURN servers.
This should be possible to achieve by auto-configuration methods.  The
RTCWEB functionality will need to utilize both network specific STUN and
TURN resources and STUN and TURN servers provisioned by the web
application."

Resulting in requirement:
   F20     The browser must support the use of STUN and TURN
           servers that are supplied by entities other than
           the web application (i.e. the network provider).

And in the enterprise case discussed, you don't expect the enterprise to
advertise that LAN TURN server with more than one (simple to configure)
method, do you?
- Anycast method: Just add a route in the existing restrictive
firewall/router
- DHCP method: Add the TURN servers LAN IP-Address to a local DHCP server
(which may be available in the existing restrictive firewall.
- DNS stuff: Set up something more complex on the LAN

My questions - or rather wanting to hear your thoughts - that maybe should
be spelled out in the draft:

In this case, isn't advertizing by the Anycast-method (always?) sufficient?
If using other methods - browsers of course MUST use all methods for
discovery.

Let us hear your thoughts/considerations.
(Including, what should go into some webrtc-draft how browsers use the auto
discovery in your draft.)

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]] 
Skickat: den 21 maj 2014 19:17
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 6:06 PM
> To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); 
> [e-mail]; 'Simon Perreault'
> Subject: Re: [tram] New Version Notification for 
> draft-patil-tram-turn-serv-disc- 01.txt
> 
> 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.

Enterprise firewall policies to permit WebRTC media and data channels is an
interesting problem it was discussed in pntaw ietf mailing list sometime
back. Various mechanisms like
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-0
3, PCP etc were discussed. As far as I remember there was no conclusion that
only anycast approach would work. 

Cheers,
-Tiru

> 
> /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-dis
> > >>c-
> > >>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-0
> > >>1
> > >>
> > >>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
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram