Re: [tram] draft-ietf-tram-turn-server-discovery

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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, where attacker sends faked permissions to the TURN server to launch attack (DOS or DDOS) on the victim (TURN client).
b) https://tools.ietf.org/html/rfc5766#section-17.3.3, attacker sends spoofed TURN requests to the TURN server to close allocations.

-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]>; 'Brandon Williams' <[e-mail]>; Prashanth Patil (praspati) <[e-mail]>; [e-mail]
Cc: [e-mail]; 'Dan Wing' <[e-mail]>; 'Spencer Dawkins at IETF' <[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...
[cid:image005.jpg@01D2494C.F917BBB0]

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

and the contradiction in section 7.2 as said in

https://www.ietf.org/mail-archive/web/tram/current/msg02226.html

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





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

> 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://www.ietf.org/mail-archive/web/tram/current/msg01742.html

> > >>> https://www.ietf.org/mail-archive/web/tram/current/msg02191.html

> > >>>

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

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

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

> > >>> and https://www.ietf.org/mail-

> > 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://www.ietf.org/mail-archive/web/tram/current/msg00138.html

> > >>> https://www.ietf.org/mail-archive/web/tram/current/msg01721.html

> > >>> https://www.ietf.org/mail-archive/web/tram/current/msg01745.html

> > >>> The links given under (1) and (2) above

> > >>> https://www.ietf.org/mail-archive/web/tram/current/msg02155.html

> > >>>

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

> > >> 0#

> > >> section

> > >> -9 for more details.

> > >>>

> > >>> Thanks,

> > >>> Authors

> > >>>

> > >>> _______________________________________________

> > >>> tram mailing list

> > >>> [e-mail]<mailto:[e-mail]>

> > >>> https://www.ietf.org/mailman/listinfo/tram

> > >>>

> > >>> _______________________________________________

> > >>> tram mailing list

> > >>> [e-mail]<mailto:[e-mail]>

> > >>> https://www.ietf.org/mailman/listinfo/tram

> > >>>

> > >>

> > >> _______________________________________________

> > >> tram mailing list

> > >> [e-mail]<mailto:[e-mail]>

> > >> https://www.ietf.org/mailman/listinfo/tram

> >

> > _______________________________________________

> > tram mailing list

> > [e-mail]<mailto:[e-mail]>

> > https://www.ietf.org/mailman/listinfo/tram