Re: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-tram-turn-server-discovery

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

(Being hinted to add [e-mail] to my response, I hope this now propagates to the WG list - sorry if you got more than once.)
Hi Brandon,

In view of point 2) of previous email I have suggested a good way get your point in.
(Will enter into red-lined Word document, attached to NEXT email)

/Karl

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[e-mail]] 
Skickat: den 10 december 2016 17:43
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Pal Martinsen (palmarti)'
Kopia: 'Prashanth Patil (praspati)'; [e-mail]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-tram-turn-server-discovery

I'm not sure we're quite at consensus yet Karl, but I think we're close.

I agree that the text you quote from the doc covers the client side 
considerations, and that framing it as recommendations rather than 
requirements still makes sense. It's up to the client to decide which 
security elements are required for the application use case, and that 
text was intended to provide guidance without trying to force a security 
posture that is more complicated than the use case requires.

[Karl] Just want mention (for all to follow) that all this text has been in the draft since version -7

For the server side, in order to allow the client to fall back to 
(D)TLS, the TURN server MUST support (D)TLS at least for opportunistic 
privacy. This doesn't mean that the server has to require (D)TLS. It can 
still allow fallback to cleartext if the client so chooses.

[Karl] Yes, of course - nothing new regarding this has been entered since version -7 of the draft

So, I agree with you on reverting the MUST for the client, as long as we 
continue to strongly recommend (D)TLS as the fallback. 

[Karl] That is where we are with the proposed text, yes.

If we do that 
though, I think we need to make it clear that a TURN server configured 
to allow sessions without STUN auth MUST support (D)TLS so that the 
client has the option of (D)TLS fallback.

[Karl] When that is the case, it HOWEVER CANNOT BE THIS DRAFT that imposes a "MUST support (D)TLS" - It should be done by a draft relying on TURN server usage from TURN servers discovered by this draft. E.g. the RETURN draft for WebRTC browsers may come to such MUST for their particular needs (based on recommendations here).

I think we are agreeing to this change.

OLD:

"A TURN client MUST use (D)TLS in the absence of ..."

NEW:

"A TURN client SHOULD use (D)TLS in the absence of ..."

And I am proposing the addition of this paragraph at the end of the 
section 9, just before section 9.1.

"In order to allow the TURN client to select fallback to (D)TLS as 
described above, a TURN server that does not require either STUN long 
term authentication [RFC5389] or STUN Extension for Third Party 
Authorization [RFC7635] MUST support (D)TLS. Such a TURN server MAY also 
allow fallback to clear text."

[Karl] We could instead put in this variant:
"In order to allow the TURN client to select fallback to encryption-only (D)TLS and clear text as described above, the TURN server has to support (D)TLS and clear text. TURN clients that does not use either STUN long term authentication [RFC5389] or STUN Extension for Third Party Authorization [RFC7635] for their particular application, should consider to require TURN servers with such support".

That means the same, but hopefully don't brake consensus of the -7 text now added to, by now and suddenly mandating USAGE from this DISCOVERY draft.

[Karl] I will put in this variant in my red-line Word document for review



--Brandon

On 12/05/2016 11:59 AM, Karl Stahl wrote:
> All I want to do in the (D)TLS discussion is to delete the sentence “A
> TURN client MUST use (D)TLS in the absence of STUN long-term credential
> mechanism [RFC5389] or STUN Extension for Third-Party Authorization
> [RFC7635].” under 9.  Security Considerationsthat was thrown-into
> version -10 during the discuss.
>
>
>
> **We leave all the rest regarding (D)TLS as it has been since version -7
> of this draft.**
>
>
>
>
>
> Brandon,
>
>
>
> I see there already are the (general) SHOULD or RECOMMEND that you
> wanted (I did not suggest to change those – they are there since version
> -7 I believe): “It is RECOMMENDED that the TURN client use one of the
> following techniques with (D)TLS to validate the TURN server:” and further…
>
>
>
>
>
> for Tiru, this is already in the draft since -7 and I am not suggesting
> to change that:
>
>
>
> “   An auto-discovered TURN server is considered to be only as trusted as
>
>    the path between the client and the TURN server.  In order to safely
>
>    use auto-discovered TURN servers for sessions with 'strict privacy'
>
>    requirements, the user needs to be able to define privacy criteria
>
>    (e.g.  a trusted list of servers, networks, or domains) that are
>
>    considered acceptable for such traffic.  Any discovered TURN server
>
>    outside the criteria is considered untrusted and therefore MUST NOT
>
>    be used for privacy sensitive communication.
>
>
>
>    In some auto-discovery scenarios, it might not be possible for the
>
>    TURN client to use (D)TLS authentication to validate the TURN server.
>
>    However, fall-back to clear text in such cases could leave the TURN
>
>    client open to on-path injection of spoofed TURN messages.  Instead,
>
>    with an explicit administrator choice, a TURN client SHOULD fall-back
>
>    to encryption-only (D)TLS when (D)TLS authentication is not
>
>    available.  Another reason to fall-back to encryption-only is for
>
>    privacy, which is analogous to SMTP opportunistic encryption
>
>    [RFC7435] where one does not require privacy but one desires privacy
>
>    when possible.
>
>
>
>    It is suggested that a TURN client attempt (D)TLS with authentication
>
>    and encryption, falling back to encryption-only if the TURN server
>
>    cannot be authenticated via (D)TLS.  A TURN client could fall back to
>
>    clear text, with an explicit administrator choice, if it does not
>
>    support unauthenticated (D)TLS, but fallback to clear text is NOT
>
>    RECOMMENDED because it makes the client more susceptible to man-in-
>
>    the-middle attacks and on-path packet injection.
>
> ”
>
>
>
>
>
> **Tiru – Below you are pointing at the -10 version changes that WE ARE
> discussing here.**
>
>
>
> Praspanth put them on the table again and I brought up that the
>
> “A TURN client MUST use (D)TLS in the absence of STUN long-term
> credential mechanism [RFC5389] or STUN Extension for Third-Party
> Authorization [RFC7635].”
>
> must go away (leave the rest), since it effectively forbids TURN servers
> provided by the local and access network.
>
>
>
> Brandon had agreed that MUST should go away, when you jumped in with the
> attacks arguments, when we were discussing whether there should still be
> a SHOULD or RECOMMEND. – Then you got me (and others?) lost, and….
>
>
>
> So catch up from point (1) of my:
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
>
>
>
>
> And you may notice that in
>  https://mailarchive.ietf.org/arch/msg/tram/3svO9djFxeZyTtNsgqQf8zCTiVY
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
> that you referred to
>
> “Making STUN authentication OPTIONAL”
>
> is ALREADY COMPENSATED for by “IP address authentication” (the
> foundation of today’s IP telephony authentication):
>
> “A TURN server in such cases must be configured to only process STUN
>
>    requests from the trusted local network or subscribers of the access
>
>    network. Operational measures must be taken in order protect the
>
>    TURN server; some of these measures include, but not limited to,
>
>    access control by means of access-lists, firewalls, subscriber quota
>
>    limits, ingress filtering etc.”
>
> where ”firewalls” specifically applies to TURN servers that local or
> access network providers allow only their own users to access.
>
>
>
> And Author’s: “Please refer
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section-9
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D10-23section-2D9&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=b0fJ1ANqhE8C2BrlnGY3iWCwVEr2OhYyFlE__oOHtSE&e=>for
> more details.”
>
> already (since version -7 I think) in detail discusses the (D)TLS
> implications in this context (that you are redoing).
>
>
>
> Please, again, let us stay with the consensus since version -7 of this
> draft: No (D)TLS mandate.
>
>
>
> Thanks,
>
> Karl
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 4 december 2016 08:33
> *Till:* Pal Martinsen (palmarti); Karl Stahl; tram mailing list
> *Kopia:* Brandon Williams; Prashanth Patil (praspati);
> [e-mail] <mailto:[e-mail]>; Dan Wing; Spencer
> Dawkins at IETF
> *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Prashanth has already summarized the changes done to draft during ISEG
> review in
> https://mailarchive.ietf.org/arch/msg/tram/3svO9djFxeZyTtNsgqQf8zCTiVY
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
>
>
>
>
> Karl’s comment is to not mandate (D)TLS, and we don’t agree with him.
>
>
>
> Request you, WG members, WG chairs and AD to share their thoughts on
> mandating the use of (D)TLS when STUN authentication is not used to
> handle the threats discussed in RFC5766.
>
>
>
> -Tiru
>
>
>
> *From:*Pal Martinsen (palmarti)
> *Sent:* Friday, December 2, 2016 11:27 PM
> *To:* Karl Stahl <[e-mail] <mailto:[e-mail]>>;
> tram mailing list <[e-mail] <mailto:[e-mail]>>
> *Cc:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; Brandon Williams
> <[e-mail] <mailto:[e-mail]>>;
> Prashanth Patil (praspati) <[e-mail]
> <mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]>; Dan Wing <[e-mail]
> <mailto:[e-mail]>>; Spencer Dawkins at IETF
> <[e-mail] <mailto:[e-mail]>>
> *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Karl (and tramsters),
>
>
>
> I am sympathetic to your arguments but they might have been lost
> somewhere in the email thread (A mix of quoting, repeating and inline
> commenting have at least made my email client somewhat confused.)
>
>
>
> The best thing you can do at this moment is to provide text. I suggest
> you write up a draft as a counter proposal and submit it. In that way
> the WG members can read through and comment.
>
>
>
> I encourage the WG chairs to give Karl enough time to write this up,
> before progressing the other draft.
>
>
>
>
>
> .-.
>
> Pål-Erik
>
>
>
>     On 2 Dec 2016, at 09:38, Karl Stahl <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>
>     Hi Tiru,
>
>
>
>     I am trying to make the point that there is no option for this
>     draft, supposed to fulfill:
>
>     *[tram] Milestone 3: TURN server auto-discovery mechanism for
>     enterprise and ISPs*
>
>     to result in: “We forbid usage of such (yellow) network provided
>     TURN servers (use gray or grayish TURN servers instead)”,  which is
>     the consequence of mandating (D)TLS.
>
>
>
>     Simply leave the consensus since version -7 of this draft by
>     removing the (D)TLS mandating for TURN servers provided by  the
>     local or access network thrown-in during the discuss.
>
>
>
>     /Karl
>
>
>
>     PS: I believe the attack discussion below is already done, and that
>     you are wrong in thinking that authentication which protects against
>     spoof attacks can be exchanged for encryption, and that any of these
>     things protects against DDOS attacks . These security things address
>     different things and are not interchangeable, nor are they universal
>     means against attacks of various kinds.
>
>
>
>     And the outcome of any such discussion doesn’t change the above.
>
>
>
>     Please note (sorry to repeat)  that for the purpose of getting a
>     better path for real-time traffic than through the default gateway
>     path, we cannot expect to also get a higher security or trust level,
>     nor to resolve every problem in the world.
>
>
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>     *Skickat:* den 28 november 2016 10:53
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [e-mail] <mailto:[e-mail]>
>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Karl,
>
>
>
>     Yes, I am discussing TURN servers provided by local or access
>     networks, referring to inside attacks launched by attackers inside
>     the local or access network.
>
>     a)An inside attacker sends faked permissions to the TURN server to
>     launch attack (DOS or DDOS) on the victim (TURN client).
>
>     b)An inside attacker sends spoofed TURN requests to the TURN server
>     to close allocations.
>
>
>
>     Both above attacks can be prevented by using opportunistic
>     encryption with (D)TLS.
>
>
>
>     -Tiru
>
>
>
>     *From:* tram [mailto:[e-mail]] *On Behalf Of *Karl Stahl
>     *Sent:* Monday, November 28, 2016 2:49 PM
>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
>     <mailto:[e-mail]>>; 'Brandon Williams'
>     <[e-mail] <mailto:[e-mail]>>;
>     Prashanth Patil (praspati) <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins at
>     IETF' <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Tiru,
>
>
>
>     Now I don’t know where you are again.
>
>
>
>     Are you discussing TURN servers provided by the local or access
>     network (the yellow TURN servers), that are released from
>     authentication (no dispute there), but for which (D)TLS mandate was
>     thrown in-during the discuss (making them gray)? That is the
>     showstopper that must go away.
>
>
>
>     Some comments below. Hope we agree  the below does not relate to the
>     yellow TURN server.
>
>
>
>     /Karl
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>     *Skickat:* den 28 november 2016 04:02
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [e-mail] <mailto:[e-mail]>
>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Karl,
>
>
>
>     No, I don’t agree that (D)TLS is not mandatory. Opportunistic
>     encryption is not new. It’s discussed in RFC7435, and used in TCP
>     increased security (TCPINC WG) and DNS privacy exchange (DPRIVE WG).
>
>
>
>     How do you propose to handle the following passive attacks without
>     (D)TLS or STUN authentication ?
>
>
>
>     a) https://tools.ietf.org/html/rfc5766#section-17.2.1
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4BznlG1EamuIy_K7ak0U40RbM&e=>,
>     where attacker sends faked permissions to the TURN server to launch
>     attack (DOS or DDOS) on the victim (TURN client).
>
>     > Since the _TURN server sits outside_ the firewall, at attacker outside the
>     firewall can now send a
>
>     --- A TURN server provided by local or access network, shall only be
>     accessible by users inside the firewall.
>
>
>
>     b) https://tools.ietf.org/html/rfc5766#section-17.3.3
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.3.3&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=eH-u5a6yq0GxTqHFJMTssCJefcXLrMGLQdz-7MK_l7c&e=>,
>     attacker sends spoofed TURN requests to the TURN server to close
>     allocations.
>
>     --- I don’t think (D)TLS helps if you can spoof and have such
>     attackers inside your network. (that paragraph says:  TURN prevents
>     this by requiring that the credentials used”) meaning authentication
>     (not certificate checking, nor encryption).
>
>
>
>
>
>     -Tiru
>
>
>
>     *From:* tram [mailto:[e-mail]] *On Behalf Of *Karl Stahl
>     *Sent:* Monday, November 28, 2016 1:39 AM
>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
>     <mailto:[e-mail]>>; 'Brandon Williams'
>     <[e-mail] <mailto:[e-mail]>>;
>     Prashanth Patil (praspati) <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins at
>     IETF' <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Tiru,
>
>
>
>     So we agree that the (D)TLS mandate thrown-in during the discuss
>     (making yellow TURN servers gray) shall go away and we are back to
>     what was consensus since version -7 of the draft. I think the
>     attacks you are discussing now have been listed already and for TURN
>     servers in a local or access network (no change since version -7),
>     we should not expect a higher security or trust level when sending
>     our real-time traffic through another path than the through default
>     gateway, both paths are provided by the same network provider.
>
>     * *
>
>     If “protects the client from various attacks discussed in previous
>     mails” related to discovery of TURN servers, really is possible by
>     introducing something (why reopen that now?), we have to be careful
>     not to make yellow TURN servers grayish, which I am afraid self
>     signed certificates might do, and further, does this belong in a
>     discovery draft, risking to pick a fight with the WebRTC browser
>     makers supposed to use this specification. We know they don’t fancy
>     self signed certificates…
>
>     <image002.jpg>
>
>
>
>     Isn’t it specifications for some specific usage/application (like
>     the return draft for WebRTC browsers) that should consider such
>     things (not this draft), without any recommendation from this
>     specification?
>
>
>
>     /Karl
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>     *Skickat:* den 23 november 2016 04:15
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [e-mail] <mailto:[e-mail]>
>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     I am not suggesting that authentication is mandatory for TURN
>     servers provided by local or access networks using (D)TLS but use of
>     (D)TLS [Karl: “these become gray not yellow” or are you suggesting
>     certificated signed by the network provider]
>
>
>
>     [TR] No, they are yellow and not grey; clients will use (D)TLS but
>     do not validate the TURN server certificate (referred to as
>     Opportunistic security in the draft).
>
>
>
>     [Karl: Seems like you are suggesting self signed certificates to
>     just get the encryption (again – also discussed)]
>
>
>
>     [TR] Yes, that’s one possible option to mandate (D)TLS. Client
>     cannot validate the TURN server certificate but use encryption-only
>     (D)TLS and protects the client from various attacks discussed in
>     previous mails.
>
>
>
>     -Tiru
>
>
>
>     *From:* Karl Stahl [mailto:[e-mail]]
>     *Sent:* Tuesday, November 22, 2016 11:12 PM
>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
>     <mailto:[e-mail]>>; 'Brandon Williams'
>     <[e-mail] <mailto:[e-mail]>>;
>     Prashanth Patil (praspati) <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins at
>     IETF' <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:* SV: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Tiru,
>
>
>
>     Please understand that in this context:
>
>     - Authentication is to only allow certain users to use the TURN
>     server resource
>
>     - Certificate checking as when using (D)TLS is to assure the user is
>     using a trusted TURN server (and further is sets up an encrypted
>     channel).
>
>
>
>     These things are not interchangeable or do the same things or
>     achieves the same, which has been discussed over and over again in
>     this draft already.
>
>
>
>     Let it rest with that we cannot/should not expect a higher trust or
>     security level when sending our real-time traffic through the TURN
>     server path, than trough the default gateway path. You simply have
>     to trust the access from the network provider you select to connect
>     to, or refrain from using it.
>
>
>
>     Please also understand that “the gray TURN servers” are provided by
>     others than the local or access network, and you chose to trust them
>     with your real-time traffic based on checking their certificate (Who
>     configures which to allow into the WebRTC browser?).
>
>
>
>     In a specification which main purpose is to auto discover TURN
>     servers provided by the local or access network (“the yellow ones”),
>     you CANNOT LOGICALLY end up with saying you MUST/SHOULD or are
>     RECOMMENDED to use “the gray ones” instead, provided by some
>     authority or Brandon maybe (which are meant for other purposes).
>     Then you have not delivered the specification we need = The showstopper.
>
>
>
>     /Karl
>
>
>
>     PS: Some comments below.
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>     *Skickat:* den 22 november 2016 04:31
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [e-mail] <mailto:[e-mail]>
>     *Kopia:* [e-mail] <mailto:[e-mail]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Karl,
>
>
>
>     I am not suggesting that authentication is mandatory for TURN
>     servers provided by local or access networks using (D)TLS but use of
>     (D)TLS [Karl: “these become gray not yellow” or are you suggesting
>     certificated signed by the network provider] without authenticating
>     the TURN server is mandatory to avoid various attacks listed in
>     previous mails.
>
>
>
>     In short, the TURN servers provided by local or access networks must
>     use (D)TLS but it’s not mandatory for these TURN servers to get
>     certificates from CA or any explicit configuration is required on
>     the client to trust the TURN server. [Karl: Seems like you are
>     suggesting self signed certificates to just get the encryption
>     (again – also discussed)]
>
>
>
>     -Tiru
>
>
>
>     *From:* Karl Stahl [mailto:[e-mail]]
>     *Sent:* Monday, November 21, 2016 2:10 AM
>     *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
>     <mailto:[e-mail]>>; 'Brandon Williams'
>     <[e-mail] <mailto:[e-mail]>>;
>     Prashanth Patil (praspati) <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>; 'Dan Wing'
>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins at
>     IETF' <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:* SV: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Tiru,
>
>
>
>     Trying to clarify as you request: I have lost track of in which
>     context you are when you are "discussing various attacks" and what
>     you mean with the ?? I marked below.
>
>
>
>     My concern was whether this may again lead to that WE
>     HAVE *_NO_* TURN SERVERS in the yellow area below resulting from the
>     (D)TLS mandating that was thrown-in into version -10 during the
>     discuss (=the showstopping), since TURN servers with
>     certificates are NOT provided by the local or access network (those
>     are provided by some "trust anchor store [RFC6024] allows a TURN
>     client ..." or by "Certification authorities that issue TURN server
>     certificates" etc..)
>
>
>
>     <image004.png>
>
>
>
>     So, just let me rest with that your discussion does not take away
>     the allowance to use TURN servers provided by the local or access
>     network without authentication that was re-introduced in version -7
>     of the draft (after long discussions, including with you Tiru).
>     Remember, _those yellow TURN servers were the requirement of this
>     draft to auto discover_ so they can be used by the WebRTC browsers –
>     Usage cannot be forbidden (or un-recommended as Brandon suggests,
>     although Brandon is agreeing to that the (D)TLS mandate must vanish
>     for the yellow TURN servers).
>
>
>
>
>
>     FURTHER JUST TO REMIND AUTHORS of what is needed to be addresses in
>     this draft; it is found in
>
>     https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
>
>     and the contradiction in section 7.2 as said in
>
>     https://www.ietf.org/mail-archive/web/tram/current/msg02226.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02226.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=EtiuiVt5Mnjbw9WsDtmjiu2l-dv1RoHVpdAlTXtgZIQ&e=>
>
>     while this discussion with Author Tiru and >“I don't run a local
>     network or an access network and would not expect to deploy relays
>     meant to function in that mode“ Brandon*, has been on more or less
>     deviated subjects, or repeating what we already have been through
>     earlier (PS: Notice that Author Prashanth already listed/discussed
>     the attack stuff during the discuss. I feared you were redoing that.)
>
>
>
>     /Karl
>
>
>
>     * https://www.ietf.org/mail-archive/web/tram/current/msg02217.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02217.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=glxP3ovYX7Cd4f12zIILJhbTcEJ0ViqVgJQySQkJHYQ&e=>
>
>
>
>
>
>     -----Ursprungligt meddelande-----
>     Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>     Skickat: den 18 november 2016 04:00
>     Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [e-mail] <mailto:[e-mail]>
>     Kopia: [e-mail] <mailto:[e-mail]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
>     Hi Karl,
>
>
>
>     I don't understand your concerns, please clarify. The draft mandates
>     (D)TLS but does not mandate TURN server validation.
>
>     We are discussing various attacks possbile for the WG to decide if
>     (D)TLS is a MUST or SHOULD.
>
>
>
>     -Tiru
>
>
>
>
>
>     > -----Original Message-----
>
>     > From: Karl Stahl [mailto:[e-mail]]
>
>     > Sent: Friday, November 18, 2016 2:11 AM
>
>     > To: Tirumaleswar Reddy (tireddy) <[e-mail] <mailto:[e-mail]>>; 'Brandon Williams'
>
>     > <[e-mail] <mailto:[e-mail]>>;
>     Prashanth Patil (praspati)
>
>     > <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>
>     > Cc: [e-mail] <mailto:[e-mail]>; 'Dan Wing'
>     <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins
>
>     > at IETF' <[e-mail] <mailto:[e-mail]>>
>
>     > Subject: SV: [tram] draft-ietf-tram-turn-server-discovery
>
>     >
>
>     > Continuing the thread of this subject with the view that it should be about the
>
>     > MUST/SHOULD/RECOMMEND discussion regarding D(TLS) for the USAGE of
>
>     > an already discovered TURN server, which must be totally independent of the
>
>     > method used for discovery.
>
>     >
>
>     > I can't say I understand where Brandon's/Tiru's discussion fits in and whether
>
>     > are right things are said and are in the right context:
>
>     >
>
>     > ?? > > The draft mandates (D)TLS but does not mandate TURN server
>
>     > validation.
>
>     > ?? (D)TLS helps avoid various attacks, like attacker sending spoofed TURN
>
>     > messages ??  We should discuss all such possible attacks, before we decide to
>
>     > go with MUST or SHOULD.
>
>     >
>
>     > Where are we know?
>
>     >
>
>     > Please, just keep the clearance from authentication as it was from version
>
>     > -07 of the draft already, until the D(TLS) mandate was thrown in during the
>
>     > DISCUSS.
>
>     >
>
>     > Simply, logically:
>
>     > > >> TURN servers *provided by* (and maintained by?) some "trust anchor
>
>     > > >> store [RFC6024] allows a TURN client ..." or by "Certification
>
>     > > >> authorities that issue TURN server certificates"
>
>     > are NOT under the clearance discussed, which is for "TURN servers *provided
>
>     > by* the local network or by the access network".
>
>     > so a SHOULD or RECOMMENDED of D(TLS) does not even belong under the
>
>     > clearance discussed.
>
>     >
>
>     >
>
>     > FURTHER, When I read:
>
>     >
>
>     > 7.2.  Recursively Encapsulated TURN
>
>     >
>
>     >    WebRTC endpoints SHOULD treat any TURN server discovered through the
>
>     >    mechanisms described in this specification as an enterprise/gateway
>
>     >    or access network server, in accordance with Recursively Encapsulated
>
>     >    TURN [I-D.ietf-rtcweb-return].
>
>     >
>
>     > Isn't that "any" in total contradiction to the clearance being discussed?
>
>     > I thought: "enterprise/gateway or access network" was the same as your
>
>     > "local or access network" and that for OTHER discovered TURN servers
>
>     > (outside the local or access network), it must be the application that instructs
>
>     > the TURN client how to use.
>
>     >
>
>     > I suggest the 7.2 section is replaced with my:
>
>     > > >>> (4) "Deployment Considerations for TURN Servers Provided by the
>
>     > > >>> Local or
>
>     > > >> Access Network"
>
>     >
>
>     > which mentions Recursively Encapsulated TURN [I-D.ietf-rtcweb-return].
>
>     > (you can spell it out like that)
>
>     >
>
>     > /Karl
>
>     >
>
>     > -----Ursprungligt meddelande-----
>
>     > Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>
>     > Skickat: den 15 november 2016 05:01
>
>     > Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati); [e-mail] <mailto:[e-mail]>
>
>     > Kopia: [e-mail] <mailto:[e-mail]>; 'Dan Wing';
>     'Spencer Dawkins at IETF'
>
>     > Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery
>
>     >
>
>     > Hi Brandon,
>
>     >
>
>     > I just listed one possible attack, there could be various other attacks like the
>
>     > one discussed in https://tools.ietf.org/html/rfc5766#section-17.2.1
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4BznlG1EamuIy_K7ak0U40RbM&e=>,
>
>     > where attacker sends faked permissions to the TURN server to launch attack
>
>     > (DOS or DDOS) on the victim (TURN client).
>
>     >
>
>     > We should discuss all such possible attacks, before we decide to go with
>
>     > MUST or SHOULD.
>
>     >
>
>     > -Tiru
>
>     >
>
>     > > -----Original Message-----
>
>     > > From: tram [mailto:[e-mail]] On Behalf Of Brandon
>
>     > > Williams
>
>     > > Sent: Monday, November 14, 2016 7:31 PM
>
>     > > To: Tirumaleswar Reddy (tireddy) <[e-mail] <mailto:[e-mail]>>; Karl Stahl
>
>     > > <[e-mail] <mailto:[e-mail]>>; Prashanth
>     Patil (praspati)
>
>     > > <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>
>     > > Cc: [e-mail] <mailto:[e-mail]>; 'Dan Wing'
>     <[e-mail] <mailto:[e-mail]>>; 'Spencer
>
>     > > Dawkins at IETF' <[e-mail] <mailto:[e-mail]>>
>
>     > > Subject: Re: [tram] draft-ietf-tram-turn-server-discovery
>
>     > >
>
>     > > +1 on the rationale. It makes almost no difference how you secure the
>
>     > > local or access network at the border, it's still possible that there
>
>     > > are
>
>     > on-path
>
>     > > adversaries, and using some type of authentication (either (D)TLS or
>
>     > > STUN) helps to protect against them.
>
>     > >
>
>     > > I still agree with Karl on downgrading the MUST back to SHOULD or
>
>     > > RECOMMENDED, since I think there's room for disagreement about how
>
>     > > critical it is to mitigate against that attack. Ease-of-use might win
>
>     > > out
>
>     > for some
>
>     > > networks provided they have other protection mechanisms at either the
>
>     > > network or datalink layer. I don't think it should drop below the
>
>     > > recommendation level though, because most network will not have such
>
>     > > mechanisms in place.
>
>     > >
>
>     > > --Brandon
>
>     > >
>
>     > > On 11/14/2016 06:36 AM, Tirumaleswar Reddy (tireddy) wrote:
>
>     > > > There seems to be confusion why (D)TLS is mandated in the draft.
>
>     > > >
>
>     > > > The draft mandates (D)TLS but does not mandate TURN server validation.
>
>     > In
>
>     > > scenarios where the TURN client cannot validate the TURN server,
>
>     > > (D)TLS helps avoid various attacks, like attacker sending spoofed TURN
>
>     > > messages
>
>     > to
>
>     > > TURN client and server. For example, when (D)TLS is not used, attacker
>
>     > > can send spoofed TURN requests to the TURN server to close allocations.
>
>     > > >
>
>     > > > The above attack is possible when TURN servers are provided by
>
>     > > > either
>
>     > local
>
>     > > or access networks.
>
>     > > >
>
>     > > > -Tiru
>
>     > > >
>
>     > > >> -----Original Message-----
>
>     > > >> From: tram [mailto:[e-mail]] On Behalf Of Karl Stahl
>
>     > > >> Sent: Monday, November 14, 2016 1:38 PM
>
>     > > >> To: 'Brandon Williams' <[e-mail] <mailto:[e-mail]>>;
>     Prashanth
>
>     > > >> Patil
>
>     > > >> (praspati) <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>
>     > > >> Cc: [e-mail] <mailto:[e-mail]>; 'Dan Wing'
>     <[e-mail] <mailto:[e-mail]>>; 'Spencer
>
>     > > >> Dawkins at IETF' <[e-mail]
>     <mailto:[e-mail]>>; Tirumaleswar
>
>     > > >> Reddy
>
>     > > >> (tireddy) <[e-mail] <mailto:[e-mail]>>
>
>     > > >> Subject: Re: [tram] draft-ietf-tram-turn-server-discovery
>
>     > > >>
>
>     > > >> Hi Brandon,
>
>     > > >>
>
>     > > >> In this draft, you have been pushing for "validation" of the
>
>     > > >> discovered TURN server by using DTLS. The use case for that has not
>
>     > > >> been spelled out, but the use case of "TURN servers *provided by*
>
>     > > >> the local network or by the access network", really needs to be
>
>     > > >> clarified in this draft. For this use case, clearance from
>
>     > > >> authentication and validation was made in version -07 of the draft
>
>     > already.
>
>     > > >>
>
>     > > >> Regarding your comment below, it is not clear which use case YOU
>
>     > > >> NOW are considering.
>
>     > > >>
>
>     > > >> Further, DISCOVERY and USAGE are not the same in this discussion.
>
>     > > >> You mix that, especially regarding the anycast method. No one is
>
>     > > >> suggesting that the TURN server is USED when addressed by anycast.
>
>     > > >> There is only ONE packet addressed by anycast and sent to the
>
>     > > >> STUN/TURN server and that is for DISCOVERING it.
>
>     > > >>
>
>     > > >> See further inline below.
>
>     > > >>
>
>     > > >> Thanks,
>
>     > > >> Karl
>
>     > > >>
>
>     > > >> -----Ursprungligt meddelande-----
>
>     > > >> Från: Brandon Williams [mailto:[e-mail]]
>
>     > > >> Skickat: den 11 november 2016 19:08
>
>     > > >> Till: Karl Stahl; 'Prashanth Patil (praspati)'; [e-mail] <mailto:[e-mail]>
>
>     > > >> Kopia: [e-mail] <mailto:[e-mail]>; 'Dan Wing';
>     'Spencer Dawkins at IETF';
>
>     > > >> 'Tirumaleswar Reddy (tireddy)'
>
>     > > >> Ämne: Re: [tram] draft-ietf-tram-turn-server-discovery
>
>     > > >>
>
>     > > >> (1) I agree with Karl that the MUST for (D)TLS or STUN auth should
>
>     > > >> revert to a SHOULD or a RECOMMENDED, given that network perimeter
>
>     > > >> control is called out with MUST (note that there are a few "must"
>
>     > > >> to "MUST" edits required in that text). Although I would disagree
>
>     > > >> with an enterprise network admin who chooses not to do one of those
>
>     > > >> two things (see my comments about (3)/(4) below), I think there's
>
>     > > >> room for difference of opinion there, so MUST is unlikely to be
>
>     > > >> complied
>
>     > with
>
>     > > anyway.
>
>     > > >>
>
>     > > >> [Karl] Good that you agree the MUST (thrown-in during discuss) must
>
>     > > >> go away, but for the use case of "TURN servers *provided by* the
>
>     > > >> local network or by the access network." there should not even be
>
>     > SHOULD
>
>     > > or RECOMMEND.
>
>     > > >> Your are relating to TURN servers *provided by* (and maintained
>
>     > > >> by?) some "trust anchor store [RFC6024] allows a TURN client ..."
>
>     > > >> or by "Certification authorities that issue TURN server
>
>     > > >> certificates" that *provide TURN servers with their certificates
>
>     > > >> in* that you expect to be discovered and where the TURN client (the
>
>     > > >> WebRTC browser) must be equipped to accept those certificates. That
>
>     > > >> is NOT FOR "the TURN servers *provided by* the local network or by
>
>     > > >> the access network" that
>
>     > is
>
>     > > being discussed here.
>
>     > > >>
>
>     > > >>
>
>     > > >> (2) I disagree with Karl about anycast. A server that properly
>
>     > > >> supports anycast [Karl] What is "a server that properly supports
>
>     > > >> anycast"? It is certainly NOT A [RFC5766] TURN server that is
>
>     > > >> supposed
>
>     > to
>
>     > > be discovered by this draft.
>
>     > > >> Also notice that we are talking about one anycast packet FOR
>
>     > > >> DISCOVERY, NOT USAGE (relaying traffic) with anycast adressing.
>
>     > > >> (I asked that the confusing "supports anycast" statement is removed
>
>     > > >> from the beginning of the draft.)
>
>     > > >>
>
>     > > >> will indeed treat incoming requests differently depending upon
>
>     > > >> whether they arrive on the anycast address or the unicast address.
>
>     > > >> I strongly disagree with the idea of using Try Alternate on the
>
>     > > >> binding request, because you want redirect for the long-lived
>
>     > > >> allocate request, not for the query-response binding request.
>
>     > > >> [Karl] With a TURN server provided by the local or access network,
>
>     > > >> STUN is NOT USED for setting up any binding and no subsequent
>
>     > > >> traffic. The STUN binding response 300 Try Alternate (statically
>
>     > > >> configured) in my proposed text, is only an indication used at
>
>     > > >> DISCOVERY, that a network provided TURN server is there and should
>
>     > > >> be used at its unicast address revealed in the
>
>     > > >> 300 response. The long-lived TURN allocate IS USED for the traffic.
>
>     > > >> The STUN server portion of the TURN server paralleling the default
>
>     > > >> gateway router is never used for any binding.
>
>     > > >>
>
>     > > >> Part of my reason for this is that good (by my definition) TURN
>
>     > > >> server distribution is broader than is reasonable for anycast
>
>     > > >> address management, and determining a redirect address to be
>
>     > > >> delivered increases the cost of handling the STUN bind request. It
>
>     > > >> is desirable for that cost to scale with the TURN allocate load,
>
>     > > >> not the STUN bind
>
>     > load.
>
>     > > >> [Karl] You just add a static route in you access router for the
>
>     > > >> anycast address to point to your TURN server!
>
>     > > >>
>
>     > > >> I don't oppose supporting both in the spec if someone wants to
>
>     > > >> propose language for that, but it would add burden to client
>
>     > > >> implementations because they would be required to support both even
>
>     > > >> though the server could use either. On the other hand, the
>
>     > > >> currently defined method shouldn't require changes to clients at all.
>
>     > > >> [Karl] ?! But it does not find [RFC5766] TURN servers...
>
>     > > >>
>
>     > > >> (3)/(4) I disagree with Karl's assessment of the deployment
>
>     > > >> considerations, especially the conclusion that anycast is the
>
>     > > >> better path for local/access networks.
>
>     > > >> [Karl] If you mean traffic paths (like I did), "paths" are for
>
>     > > >> USAGE and no one is suggesting anycast for that.
>
>     > > >> Independent of how discovered (by anycast or any of the DNS
>
>     > > >> methods) ALL USAGE through paths is by unicast addressing.
>
>     > > >>
>
>     > > >> It might be better for the server
>
>     > > >> implementer, but not for the the client, because I think it's
>
>     > > >> particularly difficult for a client to determine whether it's
>
>     > > >> network
>
>     > is
>
>     > > "sealed".
>
>     > > >> [Karl] No, not at all. Blocking STUN packets at the default gateway
>
>     > > >> is the way to "network wise" seal the local network (and only allow
>
>     > > >> the parallel TURN path)! That is easily detected by a TURN client.
>
>     > > >>
>
>     > > >> The client has to trust that the network is properly sealed, since
>
>     > > >> it's difficult (at
>
>     > > >> least) for the client to verify. Also, I think that the DNS and
>
>     > > >> DHCP methods are likely to be easier for enterprise and access
>
>     > > >> networks to implement, since they will have the necessary systems
>
>     > > >> in place already. Even a home network gateway appliance will
>
>     > > >> already have both integrate DNS and integrate DHCP, so I suspect
>
>     > > >> that a small local network will have an easier time with these than you
>
>     > suggest as well.
>
>     > > >>
>
>     > > >> [Karl] So you agree that for a TURN server in a local network, its
>
>     > > >> address shall only be deployed in local DNS - I think the draft
>
>     > > >> should
>
>     > say
>
>     > > that also.
>
>     > > >>
>
>     > > >> Despite the fact that I disagree with the assessment, I don't run a
>
>     > > >> local network or an access network and would not expect to deploy
>
>     > > >> relays meant to function in that mode, so I will not have strong
>
>     > > >> objections to including that language if there is broad support
>
>     > > >> within
>
>     > the
>
>     > > WG for Karl's framing.
>
>     > > >>
>
>     > > >> --Brandon
>
>     > > >>
>
>     > > >> On 11/10/2016 05:48 PM, Karl Stahl wrote:
>
>     > > >>> (1) The downgrade of the MUST level requirement for authentication
>
>     > > >>> defined
>
>     > > >> in [RFC5766] was "rightly" (to use the term from below) introduced
>
>     > > >> and made OPTIONAL for TURN servers provided by the local or access
>
>     > > network.
>
>     > > >>>
>
>     > > >>> HOWEVER, Prashanth's: "I think we can mandate (D)TLS *if* STUN
>
>     > > >> authentication or third-party authorization is not used." thrown-in
>
>     > > >> during the DISCUSS, must be deleted from the -10 version of this
>
>     > > >> discovery since it BLOCKs the usage and deployment of network
>
>     > > >> provided TURN servers, which was the main purpose of this discovery
>
>     > > >> draft. (Also, Authors's did not follow Ben Campbell's: "I saw a
>
>     > > >> comment on my DISCUSS email thread from Karl Stahl, stating that
>
>     > > >> DTLS could not be mandated. Has that input been
>
>     > > >> considered?")
>
>     > > >>>
>
>     > > >>> The thrown-in addition in version -10 (not shown in full below)
>
>     > > >>> highlights
>
>     > > >> this:
>
>     > > >>>
>
>     > > >>>    A TURN client MUST use (D)TLS ... in the absence of STUN long-term
>
>     > > >>>    credential mechanism [RFC5389] or STUN Extension for Third-Party
>
>     > > >>>    Authorization [RFC7635].  ...
>
>     > > >>>
>
>     > > >>>    o  For certificate-based authentication, a pre-populated trust
>
>     > anchor
>
>     > > >>>       store [RFC6024] allows a TURN client ...
>
>     > > >>>
>
>     > > >>>    o  Certification authorities that issue TURN server certificates
>
>     > > >>>       ...
>
>     > > >>>
>
>     > > >>>    o  For TURN servers that don't have a certificate trust chain
>
>     > (e.g.,
>
>     > > >>>       because they are on a home network or a corporate network), a
>
>     > > >>>       configured list of TURN servers can contain the Subject
>
>     > > >>> Public
>
>     > Key
>
>     > > >>>       Info (SPKI) fingerprint of the TURN servers... etc.
>
>     > > >>>
>
>     > > >>> What does the Authors have in mind - a regulated network of TURN
>
>     > > >>> servers,
>
>     > > >> when the purpose was for everyone to be able to use good WebRTC
>
>     > > >> everywhere you can surf, including behind your home Best Buy bought
>
>     > > >> WiFi router (which we can hope, some day, will include a default
>
>     > > >> configured, ready to use, TURN server path paralleling its default
>
>     > > >> gateway path (i.e. the NAT/firewall/access router/default gateway)?
>
>     > > >>>
>
>     > > >>> This specification shall (at least) specify discovery of network
>
>     > > >>> provided
>
>     > > >> TURN servers to allow real-time communication, in situations where
>
>     > > >> it otherwise is not possible or bad:
>
>     > > >>> - to meet the auto configuration of RFC 7478 (Web Real-Time
>
>     > > >>> Communication
>
>     > > >> Use Cases and Requirements) 2.3.5.1.
>
>     > > >>> - providing a discovery method suitable for
>
>     > > >>> draft-ietf-rtcweb-return-01
>
>     > > >>>
>
>     > > >>> The above has already been discussed many times in this WG:
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg01319.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01319.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Osl0dTxisM85YhdJ__0idlmEuHZDO94zeETh0KuWOUg&e=>
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg01742.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01742.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ovkKpAFtadl_tW-sGE9lKBidFiJ9DwAxrKyC-KgdC6w&e=>
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg02191.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02191.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=6qTmzqnEW5fWRDNt6JT9RWtnkKecOUYG8OyPtBVY9Ek&e=>
>
>     > > >>>
>
>     > > >>> Just as credentials for authentication cannot be expected to be
>
>     > > >>> available
>
>     > > >> for this general usage, nor can we impose that certificates should
>
>     > > >> be
>
>     > used.
>
>     > > >> For the network provided TURN server, we should not/must not expect
>
>     > > >> some higher level of trust or security when the real-time media
>
>     > > >> flows through the TURN server than when it goes through the default
>
>     > gateway!
>
>     > > >>>
>
>     > > >>> The use of (D)TLS has been discussed intensively in the -04
>
>     > > >>> version of the
>
>     > > >> draft
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg01821.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01821.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJm49cE6V10iisqHp3jNeSnqE7wHzDtSrIhsQU8Sx3A&e=>
>
>     > > >>> and was NOT mandated for the TURN server provided by the local or
>
>     > > >>> access
>
>     > > >> network. It cannot be thrown-in now again!
>
>     > > >>>
>
>     > > >>> Any arguments against have been of type: We need security in
>
>     > > >>> itself
>
>     > > >>> -
>
>     > > >> protect this and that - do every authentication/validation in the
>
>     > > >> book (whether needed or not) etc., which only leads to responses
>
>     > > >> like I had to bring up during the discuss:
>
>     > > >>> [Karl] Do you think we need to discover TURN servers for the
>
>     > > >>> pleasure of
>
>     > > >> doing "security that deal directly with TURN messages" in itself,
>
>     > > >> and not for what they are supposed to do (relay "application data")
>
>     > > >> and do you also think that is why a network provider will deploy
>
>     > > >> such TURN
>
>     > > server for his users?
>
>     > > >> Please do not stop the purpose (by such phrases)!
>
>     > > >>> (Also, encryption and protection against man-in-the-middle
>
>     > > >>> attacks, for
>
>     > > >> the payload (real-time traffic) are for the endpoints to do - like
>
>     > > >> with WebRTC, mandating DTLS-SRTP media - it should not be expected
>
>     > > >> to be done by a TURN server, especially when not always used.)
>
>     > > >>>
>
>     > > >>>
>
>     > > >>> (2) Also as pointed out during the DISCUSS
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg02144.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02144.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=hti885FH0I_-3z7dolfYCAia4FX3i12sUCWsGesND6s&e=>
>
>     > > >>> and two times earlier (during WG discussions, but not addressed or
>
>     > > >> responded to by the Authors):
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02081.htm&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=f-GzOTsPm86NUqzFXyjAgPz6x-BiA-buLhIFPt9QfEg&e=> l
>
>     > > >>> and https://www.ietf.org/mail-
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2D&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Sa3jwtA2TFtNAIAnfTem32vW9jIfcBlsUwxIBelblDs&e=>
>
>     > > archive/web/tram/current/msg01976.html
>
>     > > >>>
>
>     > > >>> The anycast method does not work with RFC5766 TURN servers! That
>
>     > > >>> has not
>
>     > > >> been addressed at all.
>
>     > > >>>
>
>     > > >>> A TURN server doesn't react one way (answering 300 Try Alternate)
>
>     > > >>> when
>
>     > > >> addressed by an anycast address and another way (accepting the
>
>     > > >> Allocate
>
>     > > >> request) when addressed by its unicast address, does it?
>
>     > > >>>
>
>     > > >>> Author's (during the DISCUSS): "We intend to add the following to
>
>     > > >>> explain
>
>     > > >> server behavior a little better:
>
>     > > >>> "A TURN anycast server performs checks 1 to 7 discussed in Section
>
>     > > >>> 6.2 of
>
>     > > >> RFC5766. If all checks pass, the TURN anycast server MUST respond
>
>     > > >> with a
>
>     > > >> 300 (Try Alternate) error as described in [RFC5766];"
>
>     > > >>> does not help and I responded: [Karl] That must be an update of
>
>     > RFC5766.
>
>     > > >> Or does "TURN anycast server" imply that there ALSO is a "TURN
>
>     > > >> unicast server" at the same interface accepting the Allocate request?
>
>     > > >> What are these things?
>
>     > > >>>
>
>     > > >>> I have proposed this modification of the anycast method, which is
>
>     > > >>> better
>
>     > > >> (in several aspects) and doesn't need to update RFC5766:
>
>     > > >>>
>
>     > > >>> "When a client requires TURN services, it sends a STUN binding
>
>     > > >>> request to
>
>     > > >> the assigned anycast address.  The STUN server
>
>     > > >>> responds with a 300 (Try Alternate) error as described in
>
>     > > >>> [RFC5389]; The
>
>     > > >> response contains a unicast address in the ALTERNATE-SERVER
>
>     > > >> attribute, which the client compares with the source address of the
>
>     > > >> response and if the
>
>     > > >>> addresses are the same, it is an indication to use the TURN server
>
>     > > >>> at that
>
>     > > >> address.
>
>     > > >>>
>
>     > > >>> For subsequent communication with the TURN server, the client uses
>
>     > > >>> that
>
>     > > >> responding server's unicast address."
>
>     > > >>>
>
>     > > >>> The sentence in the -10 draft under "3 Discovery Procedure": "not
>
>     > > >>> all TURN
>
>     > > >> servers may support anycast" can then be removed.
>
>     > > >>>
>
>     > > >>>
>
>     > > >>> (3) I cannot see this -10 draft telling which discovery method
>
>     > > >>> that is fit
>
>     > > >> for the TURN servers provided by the local or access network (the
>
>     > > >> network provided TURN server). However, there are confusing client
>
>     > > >> behavior recommendations, like the sentences in the draft under "3
>
>     > > >> Discovery
>
>     > > >> Procedure": "For best results, a client SHOULD implement all
>
>     > > >> discovery mechanisms described above." and under "1 Introduction":
>
>     > > >> "three discovery mechanisms, so as to maximize opportunity for
>
>     > > >> discovery, based on the network in which the TURN client finds itself."
>
>     > > >>>
>
>     > > >>> A network provided TURN server is only meant for the users on the
>
>     > > >>> specific
>
>     > > >> network - others should not be able to use such TURN server, and it
>
>     > > >> would then be preferred that it is only advertized and discovered
>
>     > > >> at that local network - which is badly described by "maximize
>
>     > > >> opportunity
>
>     > for
>
>     > > discovery".
>
>     > > >>>
>
>     > > >>> If a DNS method would be used to discover the network provided
>
>     > > >>> TURN
>
>     > > >> server, its private address should only be configured in private
>
>     > > >> (local) DNS (we don't like to put our private IP addresses in
>
>     > > >> public DNS), but I see no such recommendation. Further, the DNS
>
>     > > >> methods are complex and expensive to deploy and one of them depends
>
>     > > >> on DHCP that is not available on all access networks. That makes (a
>
>     > > >> working) anycast discovery method the clear choice for a TURN
>
>     > > >> server provided by
>
>     > > the local or access network.
>
>     > > >>>
>
>     > > >>> Network provided TURN servers paralleling a NAT/firewall/access
>
>     > > >> router/default gateway is a new concept that came up during WebRTC
>
>     > > >> standardization work to deal with traversal and quality problems of
>
>     > > >> real-time traffic. However, this draft give little or no guidance
>
>     > > >> for deployment and I therefore suggest that a separate section is
>
>     > > >> added, that spells out the deployment considerations for TURN
>
>     > > >> servers provided by the local or access network (which now is
>
>     > > >> missing, but I propose the following
>
>     > > >> text):
>
>     > > >>>
>
>     > > >>>
>
>     > > >>> (4) "Deployment Considerations for TURN Servers Provided by the
>
>     > > >>> Local or
>
>     > > >> Access Network"
>
>     > > >>> (Suggested text for an additional section)
>
>     > > >>>
>
>     > > >>> The concept of paralleling a NAT/firewall/access-router/default
>
>     > > >>> gateway at
>
>     > > >> the local or access network with a TURN server, to deal with
>
>     > > >> traversal and quality problems of real-time traffic, is new and
>
>     > > >> came up during the WebRTC standardization work.
>
>     > > >>>
>
>     > > >>> Such network provided TURN servers, only accessible by the users
>
>     > > >>> on the
>
>     > > >> local or access network, must be automatically discovered and used,
>
>     > > >> without specific configuration or having credentials for
>
>     > > >> authentication or certificates for validation, to be useful for e.g.
>
>     > > >> a WebRTC browsers to allow quality media traffic "everywhere you
>
>     > > >> can
>
>     > > surf".
>
>     > > >>>
>
>     > > >>> Just as for the Internet access itself, the TURN server is offered
>
>     > > >>> by the
>
>     > > >> network provider and there is no change in the trust or security
>
>     > > >> level (which should not be expected) when real-time traffic flows
>
>     > > >> through the TURN server path, than through the default gateway path.
>
>     > > >> (The purpose of the network provided turn server is to allow
>
>     > > >> traversal of real-time media traffic in environments with
>
>     > > >> restrictive NAT/firewalls closed for UDP traffic and/or to allow
>
>     > > >> better quality through the often data congested router at the
>
>     > > >> default
>
>     > > >> gateway.)
>
>     > > >>>
>
>     > > >>> The discovery of the network provided TURN server should meet the
>
>     > > >>> auto
>
>     > > >> configuration of RFC 7478 (Web Real-Time Communication Use Cases
>
>     > > >> and
>
>     > > >> Requirements) 2.3.5.1. and draft-ietf-rtcweb-return-01 is defining
>
>     > > >> the TURN client behavior for WebRTC browsers.
>
>     > > >>>
>
>     > > >>> For quality reasons, a sealed network configuration - i.e. the
>
>     > > >>> media has
>
>     > > >> to go through the TURN server, not through the default gateway (by
>
>     > > >> using STUN instead of TURN) - is the typical intention when a TURN
>
>     > > >> server is deployed in the local or access network. The sealed
>
>     > > >> configuration can be enforced and signaled to the TURN client by
>
>     > > >> the network provider blocking STUN packets at the default gateway.
>
>     > > >>>
>
>     > > >>> A network configuration enforcing sealed behavior, has the good
>
>     > > >>> effect of
>
>     > > >> allowing the TURN client (e.g. a WebRTC browser) in itself to have
>
>     > > >> a
>
>     > > >> non- sealed default configuration. (ietf-rtcweb-return-01 explains
>
>     > > >> that a sealed default configuration in the browser itself, would
>
>     > > >> result in that media between local clients would have to pass the
>
>     > > >> TURN server, which is not
>
>     > > >> desirable.)
>
>     > > >>>
>
>     > > >>> The above assumes that the TURN client using a TURN server in the
>
>     > > >>> local or
>
>     > > >> access network shall use unencrypted STUN/TURN (over UDP for best
>
>     > > >> quality) so the STUN cookie can be detected and stopped in the
>
>     > > >> default
>
>     > > gateway.
>
>     > > >>>
>
>     > > >>> A TURN server included in the router at the default gateway, that
>
>     > > >> intercepts and responds to an allocate request, should   be treated as
>
>     > a
>
>     > > >> discovered network provided sealed TURN server configuration by a
>
>     > > >> TURN client (without having to review any 300 Try Alternate
>
>     > > >> response as outlined in anycast method description) allowing for
>
>     > > >> tolerant and
>
>     > secure
>
>     > > deployment.
>
>     > > >>>
>
>     > > >>> A web application that wants to try the default gateway path
>
>     > > >>> instead of
>
>     > > >> the TURN server path (in spite of a sealed network configuration)
>
>     > > >> can suggest encrypted (D)TLS STUN and TURN candidates that will not
>
>     > > >> be blocked by STUN cookie recognition at the default gateway. It is
>
>     > > >> then up to application's TURN client whether to try the default
>
>     > > >> gateway
>
>     > path.
>
>     > > >>>
>
>     > > >>> A further advantage of detecting a sealed network configuration,
>
>     > > >>> is that a
>
>     > > >> TURN client can select to *only in a sealed network configuration*
>
>     > > >> look for a TURN server by the anycast method for discovery, thus
>
>     > > >> eliminating the leakage risk mentioned under 9.3. Further, there
>
>     > > >> will be no risk that a far away TURN server will be discovered and
>
>     > > >> used and there will be no need for the TTL limitation suggested under 9.3.
>
>     > > >>>
>
>     > > >>> The anycast discovery method, combined with the above
>
>     > > >>> recommendations,
>
>     > > >> allow for an easy and robust deployment of network provided TURN
>
>     > > >> servers, fitting all types of local and access networks.
>
>     > > >>>
>
>     > > >>> The DNS based methods of this specification are more complex and
>
>     > > >>> expensive
>
>     > > >> to deploy and one of them depends on DHCP that is not available on
>
>     > > >> all access networks. If any of the DNS based methods is used to
>
>     > > >> advertize and discover a TURN in the local or access network, its
>
>     > > >> private addresses should only be configured in private (local) DNS
>
>     > > >> and not be published publicly, which adds further to the complexity
>
>     > > >> and
>
>     > > cost of deployment.
>
>     > > >>>
>
>     > > >>>
>
>     > > >>> (5) Most (all?) of what is considered and summed up under (4) (the
>
>     > > >> suggested additional text), has been brought forward on the TRAM WG
>
>     > > >> list before, but not brought into the current -10 draft, see:
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg00132.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg00132.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=I4tX_vQd-ANV8cBjPGlHlFIVEUZ-3lYmVI6GbGtjxvc&e=>
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg00138.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg00138.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJWVyPhhTbhTpkcOmQRdB49hx2gOMNKOL7qMT3bq630&e=>
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg01721.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01721.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=QnbJOsYAvuDWr9YyEGsxUOv8S1ha8ow9Do5VDOq6Gs0&e=>
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg01745.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01745.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=duED3YRw_gPiLwPnjC7zgW0KbQXqQBjN-BJC4bzmt44&e=>
>
>     > > >>> The links given under (1) and (2) above
>
>     > > >>> https://www.ietf.org/mail-archive/web/tram/current/msg02155.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02155.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=5fxjtRf2Ndt9R-RDwWpgG0d7mctpUT2lUZrKGaThZ40&e=>
>
>     > > >>>
>
>     > > >>> /Karl
>
>     > > >>>
>
>     > > >>>
>
>     > > >>> -----Ursprungligt meddelande-----
>
>     > > >>> Från: tram [mailto:[e-mail]] För Prashanth Patil
>
>     > > >>> (praspati)
>
>     > > >>> Skickat: den 2 november 2016 22:18
>
>     > > >>> Till: [e-mail] <mailto:[e-mail]>
>
>     > > >>> Kopia: [e-mail] <mailto:[e-mail]>; Dan Wing;
>     Spencer Dawkins at IETF;
>
>     > > >> Tirumaleswar Reddy (tireddy)
>
>     > > >>> Ämne: [tram] draft-ietf-tram-turn-server-discovery
>
>     > > >>>
>
>     > > >>> The TURN discovery draft originally suggested that STUN
>
>     > > >>> authentication be
>
>     > > >> relaxed and made OPTIONAL for TURN servers provided by the local or
>
>     > > >> access network. The intention was to allow new/guest users (who do
>
>     > > >> not necessarily possess long term credentials for STUN
>
>     > > >> authentication) in the network to discover and use TURN services
>
>     > offered
>
>     > > by the network.
>
>     > > >>> Ben Campbell raised an objection during IESG evaluation that we
>
>     > > >>> clearly
>
>     > > >> indicate that this is a downgrade of a MUST level requirement
>
>     > > >> defined in [RFC5766] and explain its consequences. It was also
>
>     > > >> rightly suggested that we mandate the use of (D)TLS in the absence
>
>     > > >> of STUN authentication for protection against a variety of attacks;
>
>     > > >> the draft now makes it a MUST that TURN servers use (D)TLS in the
>
>     > > >> absence of STUN
>
>     > > authentication.
>
>     > > >>>
>
>     > > >>> To put it simply, the draft mandates that TURN servers in a local
>
>     > > >>> or
>
>     > > >> access network do at least one of (D)TLS or STUN authentication. If
>
>     > > >> you have an opinion about this change, please let the working group
>
>     > > >> know on the mailing list before the end of IETF 97.
>
>     > > >>>
>
>     > > >>> See below for snippets of what changed.
>
>     > > >>>
>
>     > > >>> Excerpt from Security Considerations of
>
>     > > >> draft-ietf-tram-turn-server-discovery-09:
>
>     > > >>>
>
>     > > >>>    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
>
>     > > >>>    authentication is OPTIONAL for TURN servers provided by the local
>
>     > > >>>    network or by the access network.  A network provided TURN
>
>     > > >>> server
>
>     > > MAY
>
>     > > >>>    be configured to accept Allocation requests without STUN
>
>     > > >>>    authentication, and a TURN client MAY be configured to accept
>
>     > > >>>    Allocation success responses without STUN authentication from a
>
>     > > >>>    network provided TURN server.  In order to protect against man-in-
>
>     > > >>>    the-middle attacks when accepting a TURN allocation response
>
>     > without
>
>     > > >>>    STUN authentication, it is RECOMMENDED that the TURN client use
>
>     > one
>
>     > > >>>    of the following techniques with (D)TLS to validate the TURN
>
>     > server"
>
>     > > >>>
>
>     > > >>>
>
>     > > >>> Updated text in Security Considerations of
>
>     > > >> draft-ietf-tram-turn-server-discovery-10:
>
>     > > >>>
>
>     > > >>>    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
>
>     > > >>>    authentication is OPTIONAL for TURN servers provided by the local
>
>     > > >>>    network or by the access network.  A network provided TURN
>
>     > > >>> server
>
>     > > MAY
>
>     > > >>>    be configured to accept Allocation requests without STUN
>
>     > > >>>    authentication, and a TURN client MAY be configured to accept
>
>     > > >>>    Allocation success responses without STUN authentication from a
>
>     > > >>>    network provided TURN server.
>
>     > > >>>
>
>     > > >>>    Making STUN authentication OPTIONAL is a downgrade of a MUST
>
>     > level
>
>     > > >>>    requirement defined in [RFC5766].  The downgrade allows TURN
>
>     > servers
>
>     > > >>>    provided by local or access network to accept Allocation requests
>
>     > > >>>    from new and/or guest users in the network who do not necessarily
>
>     > > >>>    possess long term credentials for STUN authentication.  The
>
>     > > >>>    intention, in such deployments, being to provide TURN services
>
>     > > >>> to
>
>     > all
>
>     > > >>>    users in the local or access network.  However, this opens up a
>
>     > TURN
>
>     > > >>>    server to a variety of attacks described in Section 17 of
>
>     > [RFC5766].
>
>     > > >>>    A TURN server in such cases must be configured to only process STUN
>
>     > > >>>    requests from the trusted local network or subscribers of the
>
>     > access
>
>     > > >>>    network.  Operational measures must be taken in order protect the
>
>     > > >>>    TURN server; some of these measures include, but not limited to,
>
>     > > >>>    access control by means of access-lists, firewalls, subscriber
>
>     > quota
>
>     > > >>>    limits, ingress filtering etc.
>
>     > > >>>
>
>     > > >>>    A TURN client MUST use (D)TLS in the absence of STUN long-term
>
>     > > >>>    credential mechanism [RFC5389] or STUN Extension for Third-Party
>
>     > > >>>    Authorization [RFC7635]."
>
>     > > >>>
>
>     > > >>> Please refer
>
>     > > >> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=--B-kAp9De1f6HhRKLEtD1bVS33BpG2S5MYzWBQ_YDI&e=>
>
>     > > >> 0#
>
>     > > >> section
>
>     > > >> -9 for more details.
>
>     > > >>>
>
>     > > >>> Thanks,
>
>     > > >>> Authors
>
>     > > >>>
>
>     > > >>> _______________________________________________
>
>     > > >>> tram mailing list
>
>     > > >>> [e-mail] <mailto:[e-mail]>
>
>     > > >>> https://www.ietf.org/mailman/listinfo/tram
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     > > >>>
>
>     > > >>> _______________________________________________
>
>     > > >>> tram mailing list
>
>     > > >>> [e-mail] <mailto:[e-mail]>
>
>     > > >>> https://www.ietf.org/mailman/listinfo/tram
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     > > >>>
>
>     > > >>
>
>     > > >> _______________________________________________
>
>     > > >> tram mailing list
>
>     > > >> [e-mail] <mailto:[e-mail]>
>
>     > > >> https://www.ietf.org/mailman/listinfo/tram
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     > >
>
>     > > _______________________________________________
>
>     > > tram mailing list
>
>     > > [e-mail] <mailto:[e-mail]>
>
>     > > https://www.ietf.org/mailman/listinfo/tram
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     _______________________________________________
>     tram mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tram
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.