Re: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery

[Brandon Williams <[e-mail]>]

Wait ... I take back my +1 here ...

As I was writing a separate response to the server-side requirement 
thread, I changed my thinking about this one (or rather remembered my 
earlier thinking). Keeping track of this discussion has become really 
difficult at this point.

Sorry about my confusion. I'll send a separate e-mail that describes my 
thinking about (D)TLS, since I've already got it started in a separate 
window.

--Brandon

On 12/10/2016 10:06 AM, Brandon Williams wrote:
> +1
>
> On 12/06/2016 11:17 PM, Tirumaleswar Reddy (tireddy) wrote:
>> Karl Wrote:  Also, you said you were NOT interested in mandating D(TLS)
>> for validation, which was the text thrown during  the discuss, and the
>> only thing I have suggested to be removed.
>>
>>
>>
>> [Tiru]
>>
>> I can fix the following text to avoid the confusion that (D)TLS is
>> mandatory but validating the TURN server identity is not mandatory:
>>
>>
>>
>> OLD:
>>
>> 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].
>>
>>
>>
>> NEW:
>>
>> In the absence of STUN long-term credential mechanism [RFC5389] or STUN
>> Extension for Third-Party Authorization [RFC7635], a TURN client MUST
>> use (D)TLS and if (D)TLS authentication to validate the TURN server
>> identity is not possible then the TURN client MUST fallback to
>> encryption-only (D)TLS.
>>
>>
>>
>> -Tiru
>>
>>
>>
>> *From:* Karl Stahl [mailto:[e-mail]]
>> *Sent:* Wednesday, December 7, 2016 7:35 AM
>> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]>; 'tram mailing
>> list' <[e-mail]>; 'Brandon Williams' <[e-mail]>
>> *Cc:* Prashanth Patil (praspati) <[e-mail]>;
>> [e-mail]; 'Dan Wing' <[e-mail]>; 'Spencer Dawkins at
>> IETF' <[e-mail]>
>> *Subject:* SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>>
>>
>>
>> Hi Tiru,
>>
>>
>>
>> Isn’t all of that in the draft since version -7 and no one has suggested
>> to remove it:
>>
>> 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=6aJ1JWFxE2YgbNJfXZnnIngnYbMdeK80XioPfnUwks4&e=>
>>
>> for more details.”
>>
>>
>>
>> “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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7435&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=o-ahnzvSKRMEYO1xIUtpMh0QBXqHdM5jncX_6SLG31k&e=>]
>>
>> 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.”
>>
>>
>>
>> Also, you said you were NOT interested in mandating D(TLS) for
>> validation, which was the text thrown during  the discuss, and the only
>> thing I have suggested to be removed.
>>
>>
>>
>> In addition to “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.” as compensation for the
>> authentication downgrade from MUST, which also no one has suggested to
>> be removed, I suggested that this sentence thrown in during the discuss,
>> is removed:
>>
>>    “A TURN client MUST use (D)TLS in the absence of STUN long-term
>>
>>    credential mechanism [RFC5389
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5389&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=F4YughE0J_rmP7Ulo5T9IJB4Fu3W-JNMyoheE6iyek8&e=>]
>>
>> or STUN Extension for Third-Party
>>
>>    Authorization [RFC7635
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7635&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=MIL4juxvOv918XY6KGHPmqDeE7OJsySEhai5dbBIXMo&e=>].”
>>
>>
>> And  this yellow (that Brandon wanted, but you were not interested in
>> the validation) is still there in all versions from -7 to suggested -11.
>>
>>   “It is RECOMMENDED that the TURN client use
>>
>>    one of the following techniques with (D)TLS to validate the TURN
>>
>>    server:
>>
>>
>>
>>
>>
>> So I think we can keep the *(D)TLS consensus* that has been there since
>> version -7 and remains in my suggested -11.
>>
>>
>>
>> /Karl
>>
>>
>>
>> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>> *Skickat:* den 6 december 2016 06:59
>> *Till:* Karl Stahl; 'tram mailing list'; 'Brandon Williams'
>> *Kopia:* Prashanth Patil (praspati); [e-mail]
>> <mailto:[e-mail]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
>> *Ämne:* RE: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>>
>>
>>
>> Hi Karl,
>>
>>
>>
>> Inside attacks are possible in local networks (e.g. Enterprise network).
>>
>>
>>
>> I will elaborate one of the attacks:
>>
>>
>>
>> a)Inside attacker passively monitors the TURN messages b/w the TURN
>> client and TURN server, and learns the nonce value conveyed by the TURN
>> server in Allocate response.
>>
>>
>>
>> b)Inside attacker spoofs a TURN request to the TURN server to close the
>> allocation (lifetime set to zero). Attacker spoofs the source IP address
>> of the TURN client and uses the nonce learned previously.
>>
>>
>>
>> c)TURN server checks if the nonce value is valid and successfully closes
>> the allocation
>>
>>
>>
>> With opportunistic encryption, attacker will not see the nonce value
>> sent by the TURN server to the TURN client and cannot close the
>> allocation.
>>
>>
>>
>> -Tiru
>>
>>
>>
>> *From:* Karl Stahl [mailto:[e-mail]]
>> *Sent:* Monday, December 5, 2016 9:44 PM
>> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
>> <mailto:[e-mail]>>; 'tram mailing list' <[e-mail]
>> <mailto:[e-mail]>>; 'Brandon Williams' <[e-mail]
>> <mailto:[e-mail]>>
>> *Cc:* 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:* SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>>
>>
>>
>> Hi Tiru,
>>
>>
>>
>> See previous:
>>
>> I think all you bring up, since version -7 of this draft, is already
>> discussed in 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=6aJ1JWFxE2YgbNJfXZnnIngnYbMdeK80XioPfnUwks4&e=>
>>
>> for more details.”
>>
>>
>>
>> /Karl
>>
>>
>>
>> PS: Yet some comments below
>>
>>
>>
>> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>> *Skickat:* den 4 december 2016 07:09
>> *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
>>
>>
>>
>> No, Mandating (D)TLS does not mean forbidding TURN server usage in local
>> (Enterprise) and access networks.
>>
>> --- See previous
>>
>> Opportunistic encryption protects the TURN client from the attacks I had
>> discussed in the previous mail, attacker cannot see the TURN messages
>> exchanged b/w the TURN client and TURN server,
>>
>> --- On local networks, you are among friends (or much worse than TURN
>> server spoof attacks may happen)
>>
>> --- On access networks you are hopefully in cafe mode, not being in
>> contact with the other users (seeing their TURN messages)
>>
>> and cannot spoof TURN messages.
>>
>> --- encryption does not hide source or destination ip addresses as far
>> as I understand
>>
>> /Karl
>>
>> -Tiru
>>
>>
>>
>> *From:* Karl Stahl [mailto:[e-mail]]
>> *Sent:* Friday, December 2, 2016 2:08 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,
>>
>>
>>
>> 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ZZ-_SMjOP8Ki9gZ6wzPjBywDoWtHtOREkDxWQHt0hA4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=-mVAbbScCntQIQqG27WQgiJYDUnDrwrv3TooeaeW9WQ&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…
>>
>>
>>
>> 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..)
>>
>>
>>
>> cid:[e-mail]3EFEC0
>>
>>
>>
>> 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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=RoQksDYwTif8WcC7pu9mSw93lTpGv0PpvAVrBJmOqBE&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=HlFe94mDcpEMQcstYO_MnhU7YzYVgNNLj_zA6fKbQsw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=MDJEF8Fm0L5d86VeSQoKznG8WMvrLGyL37ZlVoK7RbE&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ZZ-_SMjOP8Ki9gZ6wzPjBywDoWtHtOREkDxWQHt0hA4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=UQ8nxZHjChRSQF3sc2tbr82Vo2rwqxib6C1flqSTj0M&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=bEWAC26Xp-ZCCpWasI9Az-CSOA7wvnm9eja0udVuZrk&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=TR1caTM9QwgFaASc71-diTPehw0IpmP3MWC-Kv3ECEA&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=1K6T0yYhF7wHe5ZWa8i_FgptKRnKJPCrjulsFhA7ZiU&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=rAmhwLM0wIIegwZIGibns7sX1UArUnQPAKVg1lac1IM&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=n5wv4T-Romjuscl7TckqrB8HlLTNQQT2hhkbVLdC0nw&e=>l
>>
>>
>>> > >>> and https://www.ietf.org/mail-
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2D&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ngvMj_FO-lqDILKiWc_vhnRwu9uGvez69CcN3WT7tZk&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=RYHSesfqj7o8Z-N2Cf-bzialwIHWlsyrSz0xRmHzY4c&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=KHA3cB1EXSI0iHSKZJ2M35wFeNJlswYbPCeUR0bsAA8&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=_tS_buEDXuCbIC40GFNswK2X9uWoL1Whf5szrHEJDO4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=O11Dc68fLCzyFKwE5uk4gGITttt8x4swXSiI2Rq1t-I&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=Z3119bHFcte36WxImltxLO6FN_1UkgzYWpoPYZDVzt4&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=DVGS9E_SiopOIRk_em6JrGzQfeEIFTKDaFuOyMBN88Y&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&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=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&e=>
>>
>>
>

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