Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

[Justin Uberti <[e-mail]>]

On Thu, Feb 13, 2014 at 10:45 AM, Justin Uberti <[e-mail]> wrote:

> Karl,
>
> You sent 23 messages to the list on this same thread in the past few
> hours. This is not an effective way of presenting your ideas; I myself have
> lost track of what you are hoping to accomplish.
>
> Right now the only currently viable mechanism for auto-discovery is WPAD.
> If you think the anycast mechanism is worth pursuing, I suggest writing it
> up as an I-D.
>

I now see that http://www.ietf.org/id/draft-patil-tram-turn-serv-disc-00.txtcovers
the anycast mechanism.

>
> There have also been several mechanisms proposed for doing QoS
> provisioning, namely
> http://tools.ietf.org/search/draft-penno-pcp-mobile-qos-00 and
> http://tools.ietf.org/html/draft-martinsen-tram-discuss-00. If you think
> those proposals are insufficient, I suggest pointing out your concerns in
> threads specific to those documents.
>
> Justin
>
>
>
>
> On Thu, Feb 13, 2014 at 4:04 AM, Karl Stahl <[e-mail]>wrote:
>
>> Note that some things being questioned in this discussion already are in
>> the draft-ietf-rtcweb-use-cases-and-requirements document (pointed out
>> below). I think this may clarify some things also…
>>
>>
>>
>>
>>
>> On the side of this TRAM-list, I also got this question:
>>
>> > Regarding the enterprise case, I am not sure I follow your argument.
>>
>> > Do you mean that by setting up an enterprise TURN server, and open the
>> firewall for media over UDP from/to TURN server be the solution?
>>
>> ---- As we all realize, that would of course not help or improve things
>>
>>
>>
>> The intended solution in the enterprise case has not yet been spelled out
>> in this TRAM-list discussion, so for better understanding, let me copy a
>> few things from the discussion in September/October on the RTCWEB-list and
>> what is (since long) spelled out in the
>> draft-ietf-rtcweb-use-cases-and-requirements.
>>
>>
>>
>> For better understanding, I also want to point out that a TURN can have
>> two interfaces (acting like a router for media between different networks).
>> This allows to easier understand that can TURN servers can direct a best
>> media path (rather than just thinking that a TURN service is a device which
>> media just bounces against at one interface).
>>
>>
>>
>> And, we can also hope for that a TURN server becomes a (common) component
>> of a firewall, which would allow the firewall to understand that the media
>> directed to it is RTC and should be prioritized whereby the firewall can
>> traffic shaped (back-off data traffic that may be filling its Internet
>> pipe) as well as e.g. set diffserve bits or take other measures to assist
>> proper quality handling thought the network. (These are common mechanisms
>> available and used in firewalls/NATs/access routers, but TURN servers are
>> not yet included such devices.) The same goes for access routers/default
>> gateways, DPIs in the transport network itself – TURN servers included in
>> such points were media can pass and quality measures applied may/will be
>> very useful to get us WebRTC media with through networks without quality
>> destruction.
>>
>>
>>
>> From the RTCWEB mailing list September 20th (by me):
>>
>> An enterprise network that want to keep a restrictive firewall not
>> allowing UDP traffic, could provide a real-time path using a TURN server
>> paralleling the firewall, instead of tunneling RTP through always open http
>> or https ports resulting in RTP media over TCP – with severe quality
>> problems from TCP retransmissions of dropped packets. The TURN server
>> address is most easily provided in the same way as the IP address and DNS
>> address. (That would also put the right party in control – The network
>> provider (here the enterprise) decides what is allowed on his network.)
>>
>>
>>
>> The browser should select which available TURN server address to use in
>> the following priority order, where ICE could be used to try several:
>>
>>
>>
>> 1) TURN server address configured in the browser by the user (special
>> cases, normally not used)
>>
>> 2) TURN server address configured by the network administrator via an
>> “admin policy template”
>>
>> 3) TURN server address supplied by DHCP or similar automatic network
>> method
>>
>> 4) TURN server address being supplied by the web application"
>>
>>
>>
>>
>>
>> And from yesterdays(!)
>> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14these enterprise things and necessity are spelled out in:
>>
>>
>>
>> F19     The browser must be able to use several STUN and TURN servers
>>
>>    ----------------------------------------------------------------
>>
>>
>>
>> A22
>>
>> *3.3.5*<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5>*.
>> Simple Video Communication Service, enterprise aspects*
>>
>> *3.3.5.1*<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.1>*.
>> Description*
>>
>>    This use-case is similar to the Simple Video Communication Service
>>
>>    use-case (Section 3.3.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1>
>> ).
>>
>>
>>
>>    What is added is aspects when using the service in enterprises.  ICE
>>
>>    is assumed in the further description of this use-case.
>>
>>
>>
>>    An enterprise that uses a RTCWEB based web application for
>>
>>    communication desires to audit all RTCWEB based application sessions
>>
>>    used from inside the company towards any external peer.  To be able
>>
>>    to do this they deploy a TURN server that straddles the boundary
>>
>>    between the internal and the external network.
>>
>>
>>
>>    The firewall will block all attempts to use STUN with an external
>>
>>    destination unless they go to the enterprise auditing TURN server.
>>
>>    In cases where employees are using RTCWEB applications provided by an
>>
>>    external service provider they still want the traffic to stay inside
>>
>>    their internal network and in addition not load the straddling TURN
>>
>>    server, thus they deploy a STUN server allowing the RTCWEB client to
>>
>>    determine its server reflexive address on the internal side.  Thus
>>
>>    enabling cases where peers are both on the internal side to connect
>>
>>    without the traffic leaving the internal network.  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.
>>
>> *3.3.5.2*<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.2>*.
>> Additional Requirements*
>>
>>    ----------------------------------------------------------------
>>
>>    REQ-ID      DESCRIPTION
>>
>>    ----------------------------------------------------------------
>>
>>    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).
>>
>>    ----------------------------------------------------------------
>>
>>
>>
>> There are further requirement listed, helping us to understand the need
>> for auto discovery and a network provided TURN-server should be used to
>> ENFORCE that media takes that path (and thus, other paths e.g. suggested by
>> the remote MUST not happen to be used). This is related to the mobility
>> aspect (valid even without the roaming idea):
>> 3.3.6<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6>.
>> Simple Video Communication Service, access change 3.3.6.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.1>.
>> Description
>>
>>    This use-case is almost identical to the
>>
>>    Simple Video Communication Service use-case (Section 3.3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1>).  The
>>
>>    difference is that the user changes network access during the
>>
>>    session.
>>
>>
>>
>>    The communication device used by one of the users has several network
>>
>>    adapters (Ethernet, WiFi, Cellular).  The communication device is
>>
>>    accessing the Internet using Ethernet, but the user has to start a
>>
>>    trip during the session.  The communication device automatically
>>
>>    changes to use WiFi when the Ethernet cable is removed and then moves
>>
>>    to cellular access to the Internet when moving out of WiFi coverage.
>>
>>    The session continues even though the access method changes.
>>
>> 3.3.6.2<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.2>.
>> Additional Requirements
>>
>>    ----------------------------------------------------------------
>>
>>    REQ-ID      DESCRIPTION
>>
>>    ----------------------------------------------------------------
>>
>>    F17     The communication session must survive across a
>>
>>            change of the network interface used by the
>>
>>            session
>>
>>    ----------------------------------------------------------------
>>
>> 3.3.7<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7>.
>> Simple Video Communication Service, QoS 3.3.7.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.1>.
>> Description
>>
>>    This use-case is almost identical to the
>>
>>    Simple Video Communication Service, access change use-case
>>
>>    (Section 3.3.6 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6>).  The use of Quality of Service (QoS) capabilities is
>>
>>    added:
>>
>>
>>
>>    The user in the previous use case that starts a trip is behind a
>>
>>    common residential router that supports prioritization of traffic.
>>
>>    In addition, the user's provider of cellular access has QoS support
>>
>>    enabled.  The user is able to take advantage of the QoS support both
>>
>>    when accessing via the residential router and when using cellular.
>>
>> 3.3.7.2<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.2>.
>> Additional Requirements
>>
>>    ----------------------------------------------------------------
>>
>>    REQ-ID      DESCRIPTION
>>
>>    ----------------------------------------------------------------
>>
>>    F17     The communication session must survive across a
>>
>>            change of the network interface used by the
>>
>>            session
>>
>>    ----------------------------------------------------------------
>>
>>    F22     The browser must be able to receive streams and
>>
>>            data from multiple peers concurrently.
>>
>>    ----------------------------------------------------------------
>>
>>
>>
>> Further from the RTCWEB mailing list September 20th (by me):
>>
>>
>>
>> There are several reasons for a network service provider to supply a TURN
>> server as part of his offered access:
>>
>> - to keep media paths short, specifically not sending media outside its
>> own network to some distant application provided TURN server
>>
>> - to support mobility, i.e. you may want to move from a LAN with a
>> configured TURN server to accessing via WiFi or 3G/4G OTT channels
>>
>> - to offer a media path with better quality (than best effort data
>> traffic).
>>
>> Getting “WebRTC-ready” access and we look forward to telepresence for
>> everyone.
>>
>>
>>
>>
>>
>> I hope this (a bit lengthy) summary of already thought-out and discussed
>> aspects/requirements will help us understand that the auto-discovered TURN
>> server is an ORDER from the enterprise and/or the NSP/ISP  to send the
>> media through this TURN path, and that other media paths that may exist
>> MUST NOT BE USED. (That is why we especially have to watch/advice that
>> workable media paths proposed by the remote party not becomes used “by
>> accident”.
>>
>>
>>
>> /Karl
>>
>>
>>
>>
>>
>> *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]<[e-mail]>]
>>
>> *Skickat:* den 13 februari 2014 04:37
>> *Till:* Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal
>> (mperumal)
>> *Kopia:* [e-mail]; Simon Perreault; Oleg Moskalenko;
>> [e-mail]; Marc Blanchet; Dan Wing (dwing); Karl Stahl
>> *Ämne:* RE: [tram] Milestone 3: TURN server auto-discovery mechanism for
>> enterprise and ISPs
>>
>>
>>
>> Hi Andy,
>>
>>
>>
>> There are other ways to solve the problem for example using PCP. Can you
>> clarify how deploying a TURN server in the Enterprise protects the users
>> and the network ?
>>
>>
>>
>> -Tiru.
>>
>> *From:* tram [mailto:[e-mail] <[e-mail]>] *On
>> Behalf Of *Hutton, Andrew
>> *Sent:* Thursday, February 13, 2014 1:00 AM
>> *To:* Justin Uberti; Muthu Arul Mozhi Perumal (mperumal)
>> *Cc:* [e-mail]; Simon Perreault; Oleg Moskalenko; [e-mail];
>> Marc Blanchet; Dan Wing (dwing); Karl Stahl
>> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
>> for enterprise and ISPs
>>
>>
>>
>> The case where the TURN server is the only option may become common
>> within enterprise networks and that might be deliberate enterprise policy
>> because it provides the better path (UDP through the F/W) and protects the
>> users and the network.
>>
>>
>>
>> Andy
>>
>>
>>
>>
>>
>> *From:* tram [mailto:[e-mail] <[e-mail]>] *On
>> Behalf Of *Justin Uberti
>> *Sent:* 12 February 2014 17:46
>> *To:* Muthu Arul Mozhi Perumal (mperumal)
>> *Cc:* [e-mail]; Simon Perreault; Oleg Moskalenko; [e-mail];
>> Marc Blanchet; Dan Wing (dwing); Karl Stahl
>> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
>> for enterprise and ISPs
>>
>>
>>
>> Agree. If TURN is indeed being provided for the user's benefit, the
>> client's ICE logic (based on RTT or similar) should result in it preferring
>> the TURN path.
>>
>>
>>
>> On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <
>> [e-mail]> wrote:
>>
>> Yes, I believe the second case is rare, but would be better than a rat
>> race b/w administrators trying to block p2p traffic and force it through a
>> TURN server and apps/endpoints finding smarter ways to bypass them.
>>
>>
>>
>> Muthu
>>
>>
>>
>> *From:* Oleg Moskalenko [mailto:[e-mail]]
>> *Sent:* Wednesday, February 12, 2014 1:07 PM
>> *To:* Muthu Arul Mozhi Perumal (mperumal)
>> *Cc:* Justin Uberti; Karl Stahl; [e-mail]; Marc Blanchet;
>> [e-mail]; Dan Wing (dwing); Simon Perreault
>>
>>
>> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
>> for enterprise and ISPs
>>
>>
>>
>> The TURN server has to be used when it is either the only option, or if
>> it provides a better path (I guess the second case is rather rare).
>>
>>
>>
>> On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) <
>> [e-mail]> wrote:
>>
>> +1
>>
>>
>>
>> Forcing all traffic through a TURN server and expecting it would provide
>> the best user experience doesn't look the right approach. Instead, if a
>> path through a TURN server exists and does provide lower RTT, jitter etc,
>> being able to detect and use (or switch to) that path might be desirable..
>>
>>
>>
>> Muthu
>>
>>
>>
>> *From:* tram [mailto:[e-mail]] *On Behalf Of *Justin Uberti
>> *Sent:* Wednesday, February 12, 2014 11:43 AM
>> *To:* Karl Stahl
>> *Cc:* [e-mail]; Marc Blanchet; [e-mail]; Dan Wing
>> (dwing); Simon Perreault
>> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
>> for enterprise and ISPs
>>
>>
>>
>> Inline.
>>
>>
>>
>> On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <[e-mail]>
>> wrote:
>>
>> Listening to this thread, I am afraid we are missing the very point and
>> necessity for this milestone!
>>
>> - There are severe NAT traversal and quality issues that should and can
>> be dealt with by a good auto-discovery mechanism and the right usage by the
>> turn client (the WebRTC browser)
>>
>>
>>
>> There are ways, not only: Enterprises or ISPs wishing to provide their
>> own TURN server, in an attempt to reduce so-called "triangle routing",need
>> a new auto-discovery mechanism
>>
>> But also: - NSPs (Network Service Providers) want to provide a path where
>> the bandwidth of WebRTC is better coped with.
>>
>> - NSPs or Enterprises want to offer an Internet access quality pipe for
>> prioritized RTC (Real Time Communication) traffic.
>>
>> - Enterprises having restrictive firewalls, want to provide a UDP-path
>> for WebRTC and possibly also for better quality where RTC do not compete
>> with data traffic.
>>
>> Also considering
>>
>> - Mobility; It is common to move from a LAN to accessing via WiFi or
>> 3G/4G OTT channels, all should be able to automatically offer their own
>> optimal TURN server
>>
>>
>>
>> This leads us into  “TURN…to identify WebRTC flows” etc! It is not a
>> mistake, but the very need for this milestone!
>>
>>
>>
>> Again, it has not been demonstrated why TURN is the right technology
>> here, compared to a more transparent flow identification tool like MALICE.
>> We don't force all HTTP requests to locate a HTTP proxy via anycast, I
>> don't see why we need to do the same for WebRTC.
>>
>>
>>
>> What are the hesitations raised here?
>>
>> > TURN primarily to identify WebRTC flows, as opposed to using it as a
>> NAT traversal tool. This makes me concerned that we may be using the wrong
>> technology to solve the problem
>>
>> It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall
>> traversal problem associated with real-time communication (SIP at that
>> time). However, its largest flaw/problem is that quality things were not
>> (could not be?) considered. The method’s very idea (like all similar
>> methods for getting RTC through ordinary NAT/Firewalls) is to fool the
>> media through a NAT/Firewall that is unaware of what is happening. Thus,
>> this is root of quality issues (and bandwidth allocation optimization) that
>> needs to be dealt with: Real-time traffic fighting with a data traffic
>> crowded congestion point.
>>
>>
>>
>> I think that "fooling" is an incorrect description. The NAT is supposed
>> to be transparent to the client.
>>
>>
>>
>> But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate
>> request for a suitable pipe for quality demanding real time traffic. J
>>
>> ICE is a pre-protocol you use because you want a path for real-time media
>> between parties. Here: The browser says knock knock, I want to get media
>> through (and of course with as good quality as required and possible).
>>
>>
>>
>> If the NAT/Firewall owner and network owner are allowed to see these
>> requests, they can help/assist in achieving the good media path. If they
>> are not aware, they cannot help!
>>
>>
>>
>> Hope this made it understandable on an overview level how this can become“TURN…to identify WebRTC flows”
>>
>> It is also the ONLY way I can see to achieve what we want to achieve and
>> should be the aim and requirement of this milestone.
>>
>>
>>
>> I am talking about general usage of WebRTC over Internet/mobile OTT (not
>> feeding WebRTC into application specific networks like IMS where other
>> methods may exist).
>>
>>
>>
>> This is good, not evil!
>>
>>
>>
>> If the hesitations are raised because of a belief/hope/wish that there
>> are no or will not be severe quality issues “because it is all about
>> bandwidth”, “it will resolve itself with time” etc., I strongly object!
>> That is wrong and will be very detrimental for WebRTC usage. We already see
>> it and I can give numerous examples of how much less quality demanding VoIP
>> is/is not handled quality wise and that it matters. And, what would be bad
>> considering quality issues and allowing/encouraging methods to deal with
>> them?
>>
>>
>>
>> If the hesitations are raised, because of suspicion that the methods we
>> may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to
>> protect income from carrier telephony traffic), I could understand and
>> would fight the same battle. But hopefully, those days are (soon) over – At
>> least forward thinking carrier’s realize that already. Web RTC will happen.
>> Which customers want to pay for an access with blocked WebRTC? The
>> carrier’s offering/assuring good WebRTC will rather get the customers and
>> income J. (Maybe the Web browser can detect and encourage this…)
>>
>>
>>
>> If there are technical concerns of bad result, or better methods allowing
>> network providers and LAN managers to offer and inform the browser that
>> there are good media paths to be used, and that the web browser
>> automatically can chose those, then let us all understand those, so we can
>> achieve what should be achieved by this milestone.
>>
>>
>>
>> Skype, Hangouts, Facetime are doing billions of minutes per week and the
>> Internet has not melted yet. If we need to do flow identification to allow
>> traffic to be prioritized, fine (see above regarding my preferred
>> approach), but forcing all WebRTC traffic through a MITM (TURN server) is a
>> much bigger jump that I don't yet see the justification for.
>>
>>
>>
>> In short: TURN is a technology that is supposed to fade away with the
>> move to IPv6. I don't think we want to make it a critical element of WebRTC.
>>
>>
>>
>> /Karl
>>
>>
>>
>>
>>
>> *Från:* Dan Wing [mailto:[e-mail]]
>> *Skickat:* den 11 februari 2014 18:25
>> *Till:* Marc Blanchet
>> *Kopia:* Justin Uberti; [e-mail]; Karl Stahl; [e-mail];
>> Simon Perreault
>>
>>
>> *Ämne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
>> enterprise and ISPs
>>
>>
>>
>>
>>
>> On Feb 11, 2014, at 9:08 AM, Marc Blanchet <[e-mail]>
>> wrote:
>>
>>
>>
>> Le 2014-02-11 à 00:39, Dan Wing <[e-mail]> a écrit :
>>
>>
>>
>>
>> On Feb 10, 2014, at 5:30 PM, Justin Uberti <[e-mail]> wrote:
>>
>>
>>
>> Good to see there is a lot of interest for this milestone. But based on
>> the description here, it seems like we want to use TURN primarily to
>> identify WebRTC flows, as opposed to using it as a NAT traversal tool. This
>> makes me concerned that we may be using the wrong technology to solve the
>> problem.
>>
>>
>>
>> +1.
>>
>>
>>
>> I would prefer allowing flows to establish themselves using their 'best'
>> path, and the best path is seldom through a TURN server.  When we imagine
>> IPv6 in our future, we don't want to force an application-level proxy
>> (TURN) server on the path solely for traversing an IPv6 firewall.
>>
>>
>>
>>
>>
>> It seems this thread is conflating all the possible reasons /
>> justifications for TURN:
>>
>>   * mobility
>>
>>   * NAT traversal (both endpoints are behind endpoint-dependent mapping
>> NATs)
>>
>>   * firewall traversal (firewall blocks UDP)
>>
>>   * enhancing privacy
>>
>>
>>
>> Unfortunately the TURN server nor the endpoint really know which of those
>> use-cases is desired (by the user or by the IT network administrator) or
>> necessary (for the call to work at all).
>>
>>
>>
>> Dan, while I agree in principle, I doubt that a user could ever say "I
>> want mobility or I want NAT traversal". I think the user only want the call
>> to succeed, whatever the properties of its network point of attachment are.
>>
>>
>>
>> So what can we do?  Should the TURN server provide any and all services
>> the TURN client might possibly want, as that is what a robust TURN server
>> will do, and the endpoint should prefer TURN candidates over all others
>> because there might be some functionality / usefulness of TURN that the
>> user might gain through TURN (e.g., enhanced privacy)?
>>
>>
>>
>> -d
>>
>>
>>
>>
>>
>>
>>
>>  This seems problematic.  Perhaps we need a way to signal the desired
>> use-case ("trait"), or as Justin suggests, using a different technology for
>> some of these use-cases.
>>
>>
>>
>> -d
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <[e-mail]
>> > wrote:
>>
>> Simon,
>>
>> Good questions - see inline below --> .
>> Some more thought is required!
>>
>> /Karl
>>
>> -----Ursprungligt meddelande-----
>> Från: tram [mailto:[e-mail]] För Simon Perreault
>> Skickat: den 10 februari 2014 15:16
>> Till: Karl Stahl; [e-mail]; [e-mail]
>> Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
>> enterprise and ISPs
>>
>>
>> Karl,
>>
>> It is great to see such enthusiasm! Thanks!
>>
>> I have a couple technical questions...
>>
>> Le 2014-02-08 08:11, Karl Stahl a écrit :
>> > - Note that to achieve some of the above points, TURN must be favored
>> > over STUN to enforce that the TURN-path actually is used. (The Anycast
>> > method suggested below, “automatically” does this.)
>>
>> I understand the STUN vs TURN priority issue. But I don't see how anycast
>> affects it in any way. Can you please explain?
>>
>> --- Good point - I was a bit quick here (maybe too quick)
>> We have given this quite bit of thought, since even if a TURN server is
>> provided and discovered, CURRENT usage of ICE may suggest a candidate from
>> the remote party that will make a connection without the need/usage of the
>> TURN server (that we wanted to be used for the good purposes listed).
>>
>> The only way we found around this, was to stop STUN through the IP
>> default gateway (like a restrictive Enterprise firewall does inhibiting ICE
>> connectivity, which others are concerned about...). Since the provisioning
>> of auto-discovery using the anycast mechanism, would be adding a route in a
>> default gateway, adding a firewall rule to eat STUN packets would assure
>> that the provisioned TURN server actually becomes used (and not bypassed
>> "by accident"). (That was the thought behind the “automatically” within
>> quotes.)
>>
>> BUT, since you brought up the question, assuming that we have the power
>> to enforce WebRTC usage of ICE, I believe a MUST requirement to use an
>> auto-discovered TURN server instead of STUN, would solve the same problem.
>> However, thinking further (in relation to your next question - "anyone
>> could set up a badly-maintained" - enforcing such ICE usage may not be
>> good.)
>>
>>
>>
>> > - 3^rd The Anycast method below – I see no problem
>> >
>> > It also has the advantage of encouraging (but not requiring) the
>> > STUN/TURN to be built in the default gateway or NAT/firewall/access
>> > router itself, with a second interface to a public IP address on the
>> > WAN side. (Current volume deployed, low cost NSP triple play modems
>> > usually have a quality assured level 2 or level 3 WAN pipe for just
>> > voice (and another for IPTV) – The anycast discovered TURN-server can
>> > be the access gateway to such quality pipe for WebRTC media, in a
>> > single NSP provided CPE, scaling from residential and up.)
>>
>> Suppose we define well-known anycast TURN server addresses. How would
>> this not be subject to the same service quality issues that plagued 6to4?
>> That is, anyone could set up a badly-maintained, under-provisioned TURN
>> server and announce it over BGP to the world, as it was done for
>> 6to4 relays. Or just bad BGP outbound filter configuration. And how can
>> we prevent triangle routing? There is nothing guaranteeing that the anycast
>> server you see is being provided to you by your ISP, rather than a server
>> sitting on the other side of the planet.
>>
>> --- Good point - needs to be resolved. For this I don't have a ready
>> answer...
>> An auto-discovered TURN server must be trusted (whatever method it is
>> discovered by). We are trusting the one providing us with an IP address and
>> default gateway anyway. It would be easy if we could reuse that trust,
>> instead of another mechanisms.
>>
>> Is there a good way for the browser to check that the anycast address is
>> not handled beyond the network service provider's default gateway? Ideas?
>>
>>
>>
>>
>> Thanks,
>> 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
>> _______________________________________________
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> tram mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
>>
>>
>>
>> _______________________________________________
>> tram mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
>