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

[Justin Uberti <[e-mail]>]

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.

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
>
>