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

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 2 Nov 2016 21:17:35 +0000

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-10#section-9 for more details.

Thanks,
Authors

---

From: Karl Stahl <[email-masked]>
Date: Thu, 10 Nov 2016 23:48:15 +0100

(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:[email-masked]] För Prashanth Patil (praspati)
Skickat: den 2 november 2016 22:18
Till: [email-masked]
Kopia: [email-masked]; Dan Wing; Spencer Dawkins at IETF; Tirumaleswar Reddy (tireddy)
Ämne: [tram] draft-ietf-tram-turn-server-discovery

 

Thanks,
Authors

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Fri, 11 Nov 2016 13:08:15 -0500

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

(2) I disagree with Karl about anycast. A server that properly supports 
anycast 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.

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.

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.

(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. 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". 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.

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

---

From: Karl Stahl <[email-masked]>
Date: Mon, 14 Nov 2016 09:07:41 +0100

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:[email-masked]] 
Skickat: den 11 november 2016 19:08
Till: Karl Stahl; 'Prashanth Patil (praspati)'; [email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF';
'Tirumaleswar Reddy (tireddy)'
Ämne: Re: [tram] draft-ietf-tram-turn-server-discovery

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

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

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

--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?")
> 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:
> 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!
> 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.)
> 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?
> “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
> 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):
> 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:
> 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.
> Excerpt from Security Considerations of
draft-ietf-tram-turn-server-discovery-09:
> Updated text in Security Considerations of
draft-ietf-tram-turn-server-discovery-10:
> Please refer
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section
-9 for more details.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 14 Nov 2016 10:09:46 +0000

Anycast discovery explained in the draft does not update RFC5766, https://tools.ietf.org/html/rfc5766#section-2.9 already discusses about anycast discovery and re-direction of an alternate server (following the guidence given in https://tools.ietf.org/html/rfc7094#section-3.4)). 

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
> Sent: Monday, November 14, 2016 1:38 PM
> To: 'Brandon Williams' <[email-masked]>; Prashanth Patil
> (praspati) <[email-masked]>; [email-masked]
> Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins
> at IETF' <[email-masked]>; Tirumaleswar Reddy (tireddy)
> <[email-masked]>
> Subject: Re: [tram] draft-ietf-tram-turn-server-discovery
> 
> Hi Brandon,
> 
> 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.
> 
> (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.
> 
> 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
> (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.
> 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.
> 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!
> 
> 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.
> (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.
> 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
> 
> 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:
> >
> 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
> > - to meet the auto configuration of RFC 7478 (Web Real-Time
> > Communication
> Use Cases and Requirements) 2.3.5.1.
> > The use of (D)TLS has been discussed intensively in the -04 version of
> > the
> draft
> (whether needed or not) etc., which only leads to responses like I had to bring
> up during the discuss:
> 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)!
> 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.)
> >
> >
> > The anycast method does not work with RFC5766 TURN servers! That has
> > not
> been addressed at all.
> >
> > 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];"
> 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?
> >
> (in several aspects) and doesn't need to update RFC5766:
> >
> 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."
> >
> 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
> 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"
> 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".
> >
> 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.)
> >
> 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.)
> >
> client (without having to review any 300 Try Alternate response as outlined in
> anycast method description) allowing for tolerant and secure deployment.
> >
> 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.
> >
> 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.
> >
> 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.
> >
> >
> [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
> >    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
> >    of the following techniques with (D)TLS to validate the TURN server"
> >
> >
> >    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
> >    Authorization [RFC7635]."
> >
> > Please refer

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 14 Nov 2016 11:36:07 +0000

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

---

From: Brandon Williams <[email-masked]>
Date: Mon, 14 Nov 2016 09:00:39 -0500

+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

---

From: Brandon Williams <[email-masked]>
Date: Mon, 14 Nov 2016 10:28:08 -0500

As the use of the ALTERNATE-SERVER mechanism is currently defined in the 
draft, an RFC5766 TURN _client_ should still work, since it should 
already support 300 Try Alternate on Allocate requests. Even an RFC5766 
TURN _server_ should still work, since the use of the 300 Try Alternate 
response for this purpose is not ruled out by RFC5766 (it's in fact 
specifically identified as a future use for 300 Try Alternate) and so 
one could easily configure an RFC5766 server this way already and still 
be compliant with RFC5766. That said, it's most likely the server would 
need changes to support anycast discovery via Allocate requests, but the 
client would not.

On the other hand, if 300 Try Alternate is added for STUN Binding 
requests, it is a clear change to RFC5389, which states that a STUN 
server "SHOULD NOT utilize the ALTERNATE-SERVER mechanism" for Binding 
requests, because "the work involved in [redirection] is more than the 
work involved in processing the request". This argument against using 
ALTERNATE-SERVER for Binding requests continues to hold true, in my 
opinion, since it requires two requests to satisfy the Binding usage 
instead of just one.

So, for both backward compatibility and efficiency reasons, I think the 
ALTERNATE-SERVER mechanism should continue to be applied to TURN 
Allocate requests. I would not object to changing the "SHOULD NOT" from 
RFC5389 to account for Karl's preferred usage (anycast with statically 
configured redirect), but the draft should continue to support 
ALTERNATE-SERVER with Allocate too.

--Brandon

PS: Karl, I don't understand what made you stress the DISCOVERY vs USAGE 
point in your previous e-mail. We're discussing a discovery draft after 
all. Just to be clear, I am indeed discussing the use of anycast for 
discovery, not for usage (where by "usage" I think you mean data relay).

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 15 Nov 2016 03:52:09 +0000

Agreed.

-Tiru

> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Monday, November 14, 2016 8:58 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; Karl Stahl
> <[email-masked]>; Prashanth Patil (praspati) <[email-masked]>;
> [email-masked]
> at IETF' <[email-masked]>
> draft, an RFC5766 TURN _client_ should still work, since it should already
> support 300 Try Alternate on Allocate requests. Even an RFC5766 TURN
> _server_ should still work, since the use of the 300 Try Alternate response for
> this purpose is not ruled out by RFC5766 (it's in fact specifically identified as a
> future use for 300 Try Alternate) and so one could easily configure an
> RFC5766 server this way already and still be compliant with RFC5766. That
> said, it's most likely the server would need changes to support anycast
> discovery via Allocate requests, but the client would not.
> 
> On the other hand, if 300 Try Alternate is added for STUN Binding requests, it
> is a clear change to RFC5389, which states that a STUN server "SHOULD NOT
> utilize the ALTERNATE-SERVER mechanism" for Binding requests, because "the
> work involved in [redirection] is more than the work involved in processing
> the request". This argument against using ALTERNATE-SERVER for Binding
> requests continues to hold true, in my opinion, since it requires two requests
> to satisfy the Binding usage instead of just one.
> 
> configured redirect), but the draft should continue to support ALTERNATE-
> SERVER with Allocate too.
> 
> --Brandon
> 
> point in your previous e-mail. We're discussing a discovery draft after all. Just
> to be clear, I am indeed discussing the use of anycast for discovery, not for
> usage (where by "usage" I think you mean data relay).
> 
> > Anycast discovery explained in the draft does not update RFC5766,
> https://tools.ietf.org/html/rfc5766#section-2.9 already discusses about
> anycast discovery and re-direction of an alternate server (following the
> guidence given in https://tools.ietf.org/html/rfc7094#section-3.4)).
> >
> > -Tiru
> >
> >
> >> Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer
> >> Dawkins at IETF' <[email-masked]>; Tirumaleswar Reddy
> >> (tireddy) <[email-masked]>
> >> 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.
> >>
> >> "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.)
> >>
> >> 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] 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.
> >>
> >> [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.
> >>
> >> 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.
> >>
> >> 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
> >>
> >> in [RFC5766] was "rightly" (to use the term from below) introduced
> >> and made OPTIONAL for TURN servers provided by the local or access
> network.
> >>>
> >> 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?")
> >>>
> >> 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)?
> >>>
> >> 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
> >> 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:
> >> 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?
> >> 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.)
> >>>
> >>>
> >>> https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm l
> >>> and https://www.ietf.org/mail-
> archive/web/tram/current/msg01976.html
> >>>
> >>> "A TURN anycast server performs checks 1 to 7 discussed in Section
> >>> 6.2 of
> >> 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?
> >>>
> >> 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 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."
> >>>
> >> 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".
> >>>
> >> 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.
> >>>
> >> 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"
> >> 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.
> >>>
> >> 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".
> >>>
> >> 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.)
> >>>
> >> Requirements) 2.3.5.1. and draft-ietf-rtcweb-return-01 is defining
> >> the TURN client behavior for WebRTC browsers.
> >>>
> >> 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.
> >>>
> >> 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.)
> >>>
> >> 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.
> >>>
> >> 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.
> >>>
> >> 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.
> >>>
> >> 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.
> >>>
> >> allow for an easy and robust deployment of network provided TURN
> >> servers, fitting all types of local and access networks.
> >>>
> >> 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.
> >>>
> >>>
> >> suggested additional text), has been brought forward on the TRAM WG
> >> list before, but not brought into the current -10 draft, see:
> >> 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.
> >> 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.
> >>>
> >> 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.
> >>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 15 Nov 2016 04:00:51 +0000

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

> Sent: Monday, November 14, 2016 7:31 PM
> 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.
> 
> 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
> 
> > 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.
> >

---

From: Karl Stahl <[email-masked]>
Date: Thu, 17 Nov 2016 21:26:35 +0100

I'm branching off the subject here because the following emails, goes into
the MUST/SHOULD/RECOMMEND discussion regarding D(TLS) for the USAGE of the
discovered TURN server, which is (should be) totally independent of the
method used for discovery. (Just like with DHCP, the anycast discovey it
typically only done when you connect to a network. The later usage, is of
course always by Allocate and independent of what method (DHCP, DNS or
anycast) the TURN server was discovered by.)

Tiru pointed out > "...https://tools.ietf.org/html/rfc5766#section-2.9
already discusses about anycast discovery..." 
--- Yes it does and that may explain why the anycast discovery method was
written the way it is. 
HOWEVER, if you read closely, the pointed out text assumes that there are
TWO TURN servers: "a TURN server can reject an allocate request with the
suggestion that the client try an alternate server." But in the anycast
method in the draft, you assume that there is only ONE TURN server and that
it can respond with its own IP address, don't you? 
In cannot! That is why I suggest the IP address to the TURN server (the
unicast address) is given in the response to a binding request instead.
(Then you can do it ONE and the same TURN server.)

I think the anycast method text should be modified/clarified more where is
says "requires TURN services" and "subsequent"):
"For subsequent communication with the TURN server..." so it cannot be
interpreted as *first* allocate and following allocates (which might have
the interpretation at the time the statement "not all TURN servers may
support anycast" came into the draft (which I have pointed out must go
away).

To clarify, I now suggest the second paragraph under "6.  Discovery using
Anycast" is changed to:

"When a TURN client wants to discover a TURN server, it sends a STUN binding
request to the assigned anycast address.  The server responds with a 300
(Try Alternate) error as described in [RFC5389];  The response contains an
address in the ALTERNATE-SERVER attribute, which the TURN 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 unicast address, which is
thereby discovered. Any usage of the TURN server for relaying traffic, must
use the discovered TURN server's unicast address. This has to be done
because two packets addressed to an anycast address may reach two different
servers." [STOP here to avoid further confusion and whether there are TWO
TURN servers involved or not.] 

The above may also relate to Brandon's question> "Karl, I don't understand
what made you stress the DISCOVERY vs USAGE..."
--- As I pointed out above. The (later) USAGE (for relying traffic) is
separate from the discover procedure (by DHCP, DNS or anycast). There are
neither allocations nor bindings done by the discovery procedure - We just
get the unicast address in the 300 response - which I believe is/was not
your view in the discussion below.  

With any interpretation of the anycast text in version -10 of the draft - it
does NOT WORK with TURN servers as we know them. Please change to only
define discovery (not usage) and simply take the IP address from the 300
response to a binding (which a TURN server can be configured to supply
without any conflicts).

/Karl

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[email-masked]] 
Skickat: den 14 november 2016 16:28
Till: Tirumaleswar Reddy (tireddy); Karl Stahl; Prashanth Patil (praspati);
[email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: [tram] draft-ietf-tram-turn-server-discovery

--Brandon

the
anycast
>> [Karl] What is "a server that properly supports anycast"? It is certainly
NOT A
>> distribution is broader than is reasonable for anycast address
management,
>> [Karl] You just add a static route in you access router for the anycast
address
>> language for that, but it would add burden to client implementations
because
>> (3)/(4) I disagree with Karl's assessment of the deployment
considerations,
>> implementer, but not for the the client, because I think it's
particularly difficult
>> least) for the client to verify. Also, I think that the DNS and DHCP
methods are
>> [Karl] So you agree that for a TURN server in a local network, its
address shall
>> authentication or third-party authorization is not used." thrown-in
during the
>> (whether needed or not) etc., which only leads to responses like I had to
bring
>> the payload (real-time traffic) are for the endpoints to do - like with
WebRTC,
>> standardization work to deal with traversal and quality problems of
real-time
>> local or access network, must be automatically discovered and used,
without
>> specific configuration or having credentials for authentication or
certificates
>> network provider and there is no change in the trust or security level
(which
>> access network shall use unencrypted STUN/TURN (over UDP for best
quality)
>> the TURN server path (in spite of a sealed network configuration) can
suggest
>> to deploy and one of them depends on DHCP that is not available on all
access
>> relaxed and made OPTIONAL for TURN servers provided by the local or
access

---

From: Karl Stahl <[email-masked]>
Date: Thu, 17 Nov 2016 21:41:01 +0100

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?)
> >> "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.  

> >>> (4) "Deployment Considerations for TURN Servers Provided by the

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:[email-masked]] 
Skickat: den 15 november 2016 05:01
Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati);
[email-masked]
Kopia: [email-masked]; '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

> > The above attack is possible when TURN servers are provided by either
local
> or access networks.

---

From: Brandon Williams <[email-masked]>
Date: Thu, 17 Nov 2016 16:25:08 -0500

Hi Karl,

There is no reason why a TURN server cannot have both an anycast address 
and a unicast address. If we assume that it does, the anycast method as 
currently specified in the draft works just fine. The text you quote can 
be interpreted as "a TURN server can reject an allocate request with a 
Try Alternate response." There is no reason why the address in the Try 
Alternate response can't be a different address on the same machine. If 
an existing implementation has made the assumption that a TURN server 
cannot have multiple addresses, it can be corrected without any changes 
to the protocol.

If the concern is about whether an existing implementation supports the 
mechanism, the change that you propose is in conflict with a SHOULD in 
RFC5389 and therefore less likely to be supported by an existing client 
or server. What you propose requires changes to the STUN server usage, 
the STUN client usage, and the TURN client usage (or at least the 
interconnect between STUN and TURN usage). What is currently proposed in 
the draft requires none of those things. It _may_ require a TURN server 
code change, but even that would be implementation specific since some 
TURN servers likely support this capability already today. It doesn't 
require changes to the specified TURN usage.

TL;DR
I agree that there are some clarifications that might help understanding 
of the current draft text, but I disagree with your assertion that the 
current draft text is in conflict with RFC5766 and I don't agree with 
your proposed change.

--Brandon

PS: Let's see if anyone else chimes in before we continue a mostly 
one-on-one back-and-forth on the matter. If no one else does, let's see 
if we can get a suggestion from the chairs or AD on how to resolve the 
apparent impasse.

---

From: Karl Stahl <[email-masked]>
Date: Fri, 18 Nov 2016 02:43:26 +0100

> There is no reason why a TURN server cannot have both an anycast address 
and a unicast address.
--- That is not even the question

Please understand that we want an anycast method to discover a network
provided TURN server where the STUN part (bindings actually done) never will
be used. Therefore, the binding requests can be configured to always give it
the 300 Error response containing its unicast IP address.

That is why the method I propose is simple and works.

We do NOT need any more confusion around this, with even more ways to guess
what is needed and actually suggested and why.  

Some comments below.

Thanks,
Karl

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[email-masked]] 
Skickat: den 17 november 2016 22:25
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Prashanth Patil
(praspati)'; [email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: [tram] Anycast discovery, was:
draft-ietf-tram-turn-server-discovery

Hi Karl,

If the concern is about whether an existing implementation supports the 
mechanism, the change that you propose is in conflict with a SHOULD in 
RFC5389 and therefore less likely to be supported by an existing client 
or server. What you propose requires changes to the STUN server usage,
[Karl] NO 
In the TURN server we want to discover, the STUN server part (binding
requests) WILL NOT BE USED! 

the STUN client usage, 
[Karl] there is no such for this TURN server

and the TURN client usage (or at least the 

TL;DR
I agree that there are some clarifications that might help understanding 
of the current draft text, but I disagree with your assertion that the 
current draft text is in conflict with RFC5766 and I don't agree with 
your proposed change.
[Karl] If the draft is talking about ONE TURN server, that is not an RFC5766
TURN SERVER
[Karl] If the draft is playing with TWO TURN servers, they can each be
RFC5766 compatible

--Brandon

>>> Further, DISCOVERY and USAGE are not the same in this discussion. You
mix
>>> (1) I agree with Karl that the MUST for (D)TLS or STUN auth should
revert
> to a
some
>>> arrive on the anycast address or the unicast address. I strongly
disagree
> with
local
not
> for
network
>>> network - others should not be able to use such TURN server, and it
would
>>> environments with restrictive NAT/firewalls closed for UDP traffic
and/or
> to
non-
>>> cookie recognition at the default gateway. It is then up to
application's
> TURN
>>> TURN server will be discovered and used and there will be no need for
the
> TTL
servers,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 18 Nov 2016 02:59:11 +0000

+1, don't see a need for alternate mechanism.

-Tiru

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Friday, November 18, 2016 2:55 AM
> To: Karl Stahl <[email-masked]>; Tirumaleswar Reddy (tireddy)
> <[email-masked]>; Prashanth Patil (praspati) <[email-masked]>;
> [email-masked]
> Subject: Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-
> discovery
> 
> Hi Karl,
> 
> currently specified in the draft works just fine. The text you quote can be
> interpreted as "a TURN server can reject an allocate request with a Try
> Alternate response." There is no reason why the address in the Try Alternate
> response can't be a different address on the same machine. If an existing
> implementation has made the assumption that a TURN server cannot have
> multiple addresses, it can be corrected without any changes to the protocol.
> 
> RFC5389 and therefore less likely to be supported by an existing client or
> server. What you propose requires changes to the STUN server usage, the
> STUN client usage, and the TURN client usage (or at least the interconnect
> between STUN and TURN usage). What is currently proposed in the draft
> requires none of those things. It _may_ require a TURN server code change,
> but even that would be implementation specific since some TURN servers
> likely support this capability already today. It doesn't require changes to the
> specified TURN usage.
> 
> TL;DR
> I agree that there are some clarifications that might help understanding of the
> current draft text, but I disagree with your assertion that the current draft text
> is in conflict with RFC5766 and I don't agree with your proposed change.
> 
> --Brandon
> 
> PS: Let's see if anyone else chimes in before we continue a mostly one-on-one
> back-and-forth on the matter. If no one else does, let's see if we can get a
> suggestion from the chairs or AD on how to resolve the apparent impasse.
> 
> > I'm branching off the subject here because the following emails, goes
> > into the MUST/SHOULD/RECOMMEND discussion regarding D(TLS) for the
> > USAGE of the discovered TURN server, which is (should be) totally
> > independent of the method used for discovery. (Just like with DHCP,
> > the anycast discovey it typically only done when you connect to a
> > network. The later usage, is of course always by Allocate and
> > independent of what method (DHCP, DNS or
> > --- Yes it does and that may explain why the anycast discovery method
> > was written the way it is.
> > HOWEVER, if you read closely, the pointed out text assumes that there
> > are TWO TURN servers: "a TURN server can reject an allocate request
> > with the suggestion that the client try an alternate server." But in
> > the anycast method in the draft, you assume that there is only ONE
> > TURN server and that it can respond with its own IP address, don't you?
> > In cannot! That is why I suggest the IP address to the TURN server
> > (the unicast address) is given in the response to a binding request instead.
> > I think the anycast method text should be modified/clarified more
> > where is says "requires TURN services" and "subsequent"):
> > interpreted as *first* allocate and following allocates (which might
> > have the interpretation at the time the statement "not all TURN
> > servers may support anycast" came into the draft (which I have pointed
> > out must go away).
> >
> > To clarify, I now suggest the second paragraph under "6.  Discovery
> > using Anycast" is changed to:
> >
> > "When a TURN client wants to discover a TURN server, it sends a STUN
> > binding request to the assigned anycast address.  The server responds
> > with a 300 (Try Alternate) error as described in [RFC5389];  The
> > response contains an address in the ALTERNATE-SERVER attribute, which
> > the TURN 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 unicast address, which is thereby discovered. Any usage
> > of the TURN server for relaying traffic, must use the discovered TURN
> > server's unicast address. This has to be done because two packets
> > addressed to an anycast address may reach two different servers."
> > [STOP here to avoid further confusion and whether there are TWO TURN
> > servers involved or not.]
> >
> >
> > The above may also relate to Brandon's question> "Karl, I don't
> > understand what made you stress the DISCOVERY vs USAGE..."
> > separate from the discover procedure (by DHCP, DNS or anycast). There
> > are neither allocations nor bindings done by the discovery procedure -
> > We just get the unicast address in the 300 response - which I believe
> > is/was not your view in the discussion below.
> >
> >
> > With any interpretation of the anycast text in version -10 of the
> > draft - it does NOT WORK with TURN servers as we know them. Please
> > change to only define discovery (not usage) and simply take the IP
> > address from the 300 response to a binding (which a TURN server can be
> > configured to supply without any conflicts).
> >
> > /Karl
> >
> >
> > Till: Tirumaleswar Reddy (tireddy); Karl Stahl; Prashanth Patil
> > (praspati); [email-masked]
> > As the use of the ALTERNATE-SERVER mechanism is currently defined in
> > the draft, an RFC5766 TURN _client_ should still work, since it should
> > already support 300 Try Alternate on Allocate requests. Even an
> > RFC5766 TURN _server_ should still work, since the use of the 300 Try
> > Alternate response for this purpose is not ruled out by RFC5766 (it's
> > in fact specifically identified as a future use for 300 Try Alternate)
> > and so one could easily configure an RFC5766 server this way already
> > and still be compliant with RFC5766. That said, it's most likely the
> > server would need changes to support anycast discovery via Allocate
> > requests, but the client would not.
> >
> > So, for both backward compatibility and efficiency reasons, I think
> > the ALTERNATE-SERVER mechanism should continue to be applied to TURN
> > PS: Karl, I don't understand what made you stress the DISCOVERY vs
> > USAGE point in your previous e-mail. We're discussing a discovery
> > draft after all. Just to be clear, I am indeed discussing the use of
> > anycast for discovery, not for usage (where by "usage" I think you mean data
> relay).
> >
> > https://tools.ietf.org/html/rfc5766#section-2.9 already discusses
> > about anycast discovery and re-direction of an alternate server
> > (following the guidence given in https://tools.ietf.org/html/rfc7094#section-
> 3.4)).
> >>
> >> -Tiru
> >>
> >>
> >>> discovered
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> go
> > away,
> >>> but for the use case of "TURN servers *provided by* the local
> >>> network or
> > by
> > "Certification
> >>> with their certificates in* that you expect to be discovered and
> >>> where
> > the
> >>> certificates. That is NOT FOR "the TURN servers *provided by* the
> >>> local network or by the access network" that is being discussed here.
> >>>
> >>>
> >>> supports
> >>> from
> >>> whether
> > they
> >>> 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.
> >>> 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
> >>> The
> > STUN
> >>> server portion of the TURN server paralleling the default gateway
> >>> router
> > is
> >>> 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
> >>> implementations
> >>> they would be required to support both even though the server could
> >>> use either. On the other hand, the currently defined method
> >>> and
> > no one is
> >>> is
> > the way
> >>> to "network wise" seal the local network (and only allow the
> >>> parallel
> > TURN
> >>> The client has to trust that the network is properly sealed, since
> >>> it's
> > difficult (at
> >>> 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.
> >>>
> >>> relays meant
> >>> function in that mode, so I will not have strong objections to
> >>> including
> > that
> >>> and
> > made
> >>> 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?")
> >>>>
> >>> configured,
> > ready
> >>> to use, TURN server path paralleling its default gateway path (i.e.
> >>> the NAT/firewall/access router/default gateway)?
> >>>>
> >>> TURN servers to allow real-time communication, in situations where
> >>> it otherwise is not possible or bad:
> >>> for this general usage, nor can we impose that certificates should
> >>> be
> > used.
> >>> some higher level of trust or security when the real-time media
> >>> flows through
> > the
> >>> book (whether needed or not) etc., which only leads to responses
> >>> like I had to
> > bring
> >>> up during the discuss:
> >>> 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
> >>> mandating DTLS-SRTP media - it should not be expected to be done by
> >>> a
> > TURN
> >>>> and
> >>>> The anycast method does not work with RFC5766 TURN servers! That
> >>>> has not
> >>> been addressed at all.
> >>>>
> >>> unicast server" at the same interface accepting the Allocate
> >>> request? What are
> > these
> >>> things?
> >>>>
> >>> response and if
> >>> (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
> >>> all
> >>> 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
> >>> traversal
> > and
> >>> for validation, to be useful for e.g. a WebRTC browsers to allow
> >>> quality
> > media
> >>> level
> >>> 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
> >>> that a
> > sealed
> >>> default configuration in the browser itself, would result in that
> >>> media
> > between
> >>> as
> > outlined in
> >>> encrypted (D)TLS STUN and TURN candidates that will not be blocked
> >>> by
> > STUN
> >>> 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
> >>> all
> >>> 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
> >>> possess long term credentials for STUN authentication) in the
> >>> network to discover and use TURN services offered by the network.
> >>> 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
> >>> protection against a variety of attacks; the draft now makes it a
> >>> MUST
> > that
> >>> you
> > have
> >>> an opinion about this change, please let the working group know on
> >>> the mailing list before the end of IETF 97.
> >>>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 18 Nov 2016 02:59:52 +0000

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

> From: Karl Stahl [mailto:[email-masked]]
> Sent: Friday, November 18, 2016 2:11 AM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams'
> <[email-masked]>; Prashanth Patil (praspati)
> <[email-masked]>; [email-masked]
> 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
> 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:
> 
> messages ??  We should discuss all such possible attacks, before we decide to
> go with MUST or SHOULD.
> 
> Where are we know?
> 
> > >> 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"
> (outside the local or access network), it must be the application that instructs
> the TURN client how to use.
> 
> Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati); [email-masked]
> 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,
> > <[email-masked]>; Prashanth Patil (praspati)
> > <[email-masked]>; [email-masked]
> > Dawkins at IETF' <[email-masked]>
> > are
> on-path
> > adversaries, and using some type of authentication (either (D)TLS or
> > STUN) helps to protect against them.
> >
> > out
> for some
> > 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.
> > >
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >>
> > >> anycast"? It is certainly NOT A [RFC5766] TURN server that is
> > >> supposed
> to
> > >> 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.
> > >> DISCOVERY, that a network provided TURN server is there and should
> > >> be used at its unicast address revealed in the
> > >> 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.
> > >> though the server could use either. On the other hand, the
> > >> currently defined method shouldn't require changes to clients at all.
> > >> 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.
> > >>
> > >> particularly difficult for a client to determine whether it's
> > >> network
> is
> > "sealed".
> > >> 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.
> > >>
> > >> address shall only be deployed in local DNS - I think the draft
> > >> should
> say
> > that also.
> > >>
> > >> objections to including that language if there is broad support
> > >> within
> the
> > WG for Karl's framing.
> > >>
> > >> --Brandon
> > >>
> > >> comment on my DISCUSS email thread from Karl Stahl, stating that
> > >> DTLS could not be mandated. Has that input been
> > >> considered?")
> > >>>
> > >>>       configured list of TURN servers can contain the Subject
> > >>> Public
> Key
> > >> 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
> > >>> Any arguments against have been of type: We need security in
> > >>> itself
> > >>> -
> > >> like I had to bring up during the discuss:
> > >> 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?
> > >> with WebRTC, mandating DTLS-SRTP media - it should not be expected
> > >> to be done by a TURN server, especially when not always used.)
> > >>>
> > >>>
> > >> would then be preferred that it is only advertized and discovered
> > >> at that local network - which is badly described by "maximize
> > >> opportunity
> for
> > discovery".
> > >>>
> > >> (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
> > >> 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):
> > >>>
> > >>>
> > >> traversal and quality problems of real-time traffic, is new and
> > >> came up during the WebRTC standardization work.
> > >>>
> > >> 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.)
> > >>>
> > >> configuration can be enforced and signaled to the TURN client by
> > >> the network provider blocking STUN packets at the default gateway.
> > >>>
> > >> TURN client (without having to review any 300 Try Alternate
> > >> response as outlined in anycast method description) allowing for
> > >> tolerant and
> secure
> > deployment.
> > >>>
> > >> 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.
> > >>>
> > >> 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.
> > >>>
> > >> 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.
> > >>>
> > >>>    network or by the access network.  A network provided TURN
> > >>> server
> > MAY
> > >>>    network or by the access network.  A network provided TURN
> > >>> server
> > MAY
> > >>>    intention, in such deployments, being to provide TURN services
> > >>> to
> all
> > >> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1
> > >> 0#
> > >> section
> > >> -9 for more details.
> > >>>
> > >>> Thanks,
> > >>> Authors
> > >>>

---

From: Karl Stahl <[email-masked]>
Date: Sun, 20 Nov 2016 21:24:54 +0100

Re: Tiru's, Brandon's> "+1, don't see a need for alternate mechanism."

Please understand that we need a working and clearly specified anycast
method/mechanism for discovery of a TURN server (not some “alternate
mechanism”): 

The text in version -10 of draft (unclear portions is highlighted gray):

“   When a client requires TURN services, it sends a TURN allocate

   request to the assigned anycast address.  The TURN anycast server

   responds with a 300 (Try Alternate) error as described in [RFC5766];

   The response contains the TURN unicast address in the ALTERNATE-

   SERVER attribute.  For subsequent communication with the TURN server,

   the client uses the responding server's unicast address...

” 

Seems to outline this mechanism (that we do not want, since it does not
fulfill what we need):

d

OR this mechanism, that we need, but does not work with a RFC5766 TURN
server (that must be USED by the allocate request, so it cannot be
configured to also return its unicast address in response by the allocate
request): 

We need this mechanism (only involving the TURN server we are trying to
discover) which simply can be done by configuring the TURN server to return
its own unicast address in the 300 response to a binding request): 

This text would replace modify/clarify the highlighted gray in version -10
of draft.

"When a TURN client wants to discover a TURN server, it sends a STUN binding
request to the assigned TURN anycast address.  The server responds with a
300 (Try Alternate) error as described in [RFC5389].  The response contains
an address in the ALTERNATE-SERVER attribute, which the TURN 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. The TURN server
is thereby discovered. Any usage of the TURN server for relaying traffic,
must use the discovered TURN server's unicast address, since two packets
addressed to an anycast address may reach two different servers." [STOP
section 6 here to avoid further confusion and whether there are TWO TURN
servers involved or other things.] 

This of course has to be corrected in the draft!

You may informatively add (only to clarify further) that:

“(A TURN server configured to be able to be discovered by this method,
cannot be USED to create STUN bindings, but that is not what a network
provided TURN server is used for.)”

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.

/Karl

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

----- Original Message ----- (in parallel with below, brought-in)

Från: tram [mailto:[email-masked]] För Karl Stahl

Skickat: den 18 november 2016 02:43

Till: 'Brandon Williams'; 'Tirumaleswar Reddy (tireddy)'; 'Prashanth Patil
(praspati)'; [email-masked]

and a unicast address.

Some comments below.

Thanks,

Karl

----- Original Message -----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 18 november 2016 03:59
Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati);
[email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] Anycast discovery, was:
draft-ietf-tram-turn-server-discovery

-Tiru

> From: Brandon Williams [ <mailto:[email-masked]>
mailto:[email-masked]]

> To: Karl Stahl < <mailto:[email-masked]> [email-masked]>;
Tirumaleswar Reddy (tireddy)

> < <mailto:[email-masked]> [email-masked]>; Prashanth Patil
(praspati) < <mailto:[email-masked]> [email-masked]>;

>  <mailto:[email-masked]> [email-masked]

> Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' <
<mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins

> at IETF' < <mailto:[email-masked]>
[email-masked]>

be

of the

> PS: Let's see if anyone else chimes in before we continue a mostly
one-on-one

> > Från: Brandon Williams [ <mailto:[email-masked]>
mailto:[email-masked]]

> > (praspati);  <mailto:[email-masked]> [email-masked]

> > Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing';
'Spencer Dawkins at IETF'

> > server "SHOULD NOT utilize the ALTERNATE-SERVER mechanism" for

> Binding

> > Allocate requests. I would not object to changing the "SHOULD NOT"

> >  <https://tools.ietf.org/html/rfc5766#section-2.9>

> > (following the guidence given in
<https://tools.ietf.org/html/rfc7094#section->
https://tools.ietf.org/html/rfc7094#section-

> >>> From: tram [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Karl Stahl

> >>> To: 'Brandon Williams' < <mailto:[email-masked]>
[email-masked]>; Prashanth

> >>> Patil

> >>> (praspati) < <mailto:[email-masked]> [email-masked]>;
<mailto:[email-masked]> [email-masked]

> >>> Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' <
<mailto:[email-masked]> [email-masked]>; 'Spencer

> >>> Dawkins at IETF' < <mailto:[email-masked]>
[email-masked]>; Tirumaleswar Reddy

> >>> (tireddy) < <mailto:[email-masked]> [email-masked]>

> >>> server by using DTLS. The use case for that has not been spelled

> >>> out, but

> >>> use case of "TURN servers *provided by* the local network or by the

> >>> Från: Brandon Williams [ <mailto:[email-masked]>
mailto:[email-masked]]

> >>> Till: Karl Stahl; 'Prashanth Patil (praspati)';
<mailto:[email-masked]> [email-masked]

> >>> Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan
Wing'; 'Spencer Dawkins at IETF';

> >>> authorities that issue TURN server certificates" that *provide TURN

> > servers

> >>> [Karl] What is "a server that properly supports anycast"? It is

> >>> certainly

> >>> server is there and should be used at its unicast address revealed

> >>> in the

> >>> especially the conclusion that anycast is the better path for

> > local/access

> >>> likely to be easier for enterprise and access networks to implement,

> > since they

> >>>> (1) The downgrade of the MUST level requirement for authentication

> >>>> defined

> >>>> What does the Authors have in mind - a regulated network of TURN

> >>>> This specification shall (at least) specify discovery of network

> >>>> provided

> >>>> - providing a discovery method suitable for

> >>>> draft-ietf-rtcweb-return-01

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

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

> >>>> and was NOT mandated for the TURN server provided by the local or

> >>>> Any arguments against have been of type: We need security in itself

> >>>> [Karl] Do you think we need to discover TURN servers for the

> >>>> pleasure of

> >>> that is why a network provider will deploy such TURN server for his

> > users?

> >>>> (Also, encryption and protection against man-in-the-middle attacks,

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

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

> >>>> A TURN server doesn't react one way (answering 300 Try Alternate)

> >>>> when

> >>> addressed by an anycast address and another way (accepting the

> >>> Allocate

> >>> RFC5766. If all checks pass, the TURN anycast server MUST respond

> >>> with a

> >>>> does not help and I responded: [Karl] That must be an update of

> RFC5766.

> >>>> I have proposed this modification of the anycast method, which is

> >>>> better

> >>>> "When a client requires TURN services, it sends a STUN binding

> >>>> request to

> >>>> responds with a 300 (Try Alternate) error as described in

> >>>> [RFC5389]; The

> >>>> The sentence in the -10 draft under "3 Discovery Procedure": "not

> >>>> all TURN

> >>>> (3) I cannot see this -10 draft telling which discovery method that

> >>>> is fit

> >>>> A network provided TURN server is only meant for the users on the

> >>>> specific

> >>> that local network - which is badly described by "maximize

> >>> opportunity for

> >>> networks. That makes (a working) anycast discovery method the clear

> > choice

> >>>> The concept of paralleling a NAT/firewall/access-router/default

> >>>> gateway at

> >>> quality problems of real-time traffic, is new and came up during the

> > WebRTC

> >>>> Such network provided TURN servers, only accessible by the users on

> >>>> Just as for the Internet access itself, the TURN server is offered

> >>>> by the

> >>> allow better quality through the often data congested router at the

> >>>> The discovery of the network provided TURN server should meet the

> >>>> auto

> >>>> For quality reasons, a sealed network configuration - i.e. the

> >>>> media has

> >>>> A network configuration enforcing sealed behavior, has the good

> >>>> effect of

> >>>> The above assumes that the TURN client using a TURN server in the

> >>>> local or

> >>> anycast method description) allowing for tolerant and secure

> >>>> A web application that wants to try the default gateway path

> >>>> instead of

> >>> can

> >>>> A further advantage of detecting a sealed network configuration, is

> >>>> The anycast discovery method, combined with the above

> >>>> recommendations,

> >>>> The DNS based methods of this specification are more complex and

> >>>> expensive

> >>> networks. If any of the DNS based methods is used to advertize and

> > discover a

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

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

> >>>> Från: tram [ <mailto:[email-masked]>
mailto:[email-masked]] För Prashanth Patil

> >>>> (praspati)

> >>>> Till:  <mailto:[email-masked]> [email-masked]

> >>>> Kopia:  <mailto:[email-masked]> [email-masked]; Dan Wing;
Spencer Dawkins at IETF;

> >>> Tirumaleswar Reddy (tireddy)

> >>>> The TURN discovery draft originally suggested that STUN

> >>>> authentication be

> >>> network. The intention was to allow new/guest users (who do not

> > necessarily

> >>>> Ben Campbell raised an objection during IESG evaluation that we

> >>>> clearly

> >>>> To put it simply, the draft mandates that TURN servers in a local

> >>>>    network or by the access network.  A network provided TURN server

> >>>>    STUN authentication, it is RECOMMENDED that the TURN client use

> one

> >>>>    network or by the access network.  A network provided TURN server

> >>>>    Making STUN authentication OPTIONAL is a downgrade of a MUST

> >>>>    requirement defined in [RFC5766].  The downgrade allows TURN

> servers

<https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#s>
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#s

> > ection

> >>>>  <mailto:[email-masked]> [email-masked]

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

> >>>>  <mailto:[email-masked]> [email-masked]

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

> >>>  <mailto:[email-masked]> [email-masked]

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

---

From: Karl Stahl <[email-masked]>
Date: Sun, 20 Nov 2016 21:40:10 +0100

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

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

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

 

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
[email-masked]

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

> From: Karl Stahl [ <mailto:[email-masked]>
mailto:[email-masked]]

> To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]>
[email-masked]>; 'Brandon Williams'

> < <mailto:[email-masked]> [email-masked]>;
Prashanth Patil (praspati)

> < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]>
[email-masked]

whether

> (outside the local or access network), it must be the application that
instructs

> Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]>
mailto:[email-masked]]

> one discussed in  <https://tools.ietf.org/html/rfc5766#section-17.2.1>
https://tools.ietf.org/html/rfc5766#section-17.2.1,

> > From: tram [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Brandon

> > Williams

> > To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]>
[email-masked]>; Karl Stahl

> > < <mailto:[email-masked]> [email-masked]>; Prashanth Patil
(praspati)

> > < <mailto:[email-masked]> [email-masked]>;

> > > The draft mandates (D)TLS but does not mandate TURN server validation.

> In

> > > The above attack is possible when TURN servers are provided by

> > > either

> > >> Dawkins at IETF' < <mailto:[email-masked]>
[email-masked]>; Tirumaleswar

> > >> Reddy

> > >> local network or by the access network." there should not even be

> SHOULD

> > >>>    o  For certificate-based authentication, a pre-populated trust

> anchor

> > >>>    o  For TURN servers that don't have a certificate trust chain

> (e.g.,

> > >>> (Also, encryption and protection against man-in-the-middle

> > >>> attacks, for

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

> > >>> (3) I cannot see this -10 draft telling which discovery method

> > >>> that is fit

> > >>> If a DNS method would be used to discover the network provided

> > >>> Such network provided TURN servers, only accessible by the users

> > >>> on the

> > >> a WebRTC browsers to allow quality media traffic "everywhere you

> > >> configuration of RFC 7478 (Web Real-Time Communication Use Cases

> > >> allowing the TURN client (e.g. a WebRTC browser) in itself to have

> > >> quality) so the STUN cookie can be detected and stopped in the

> > >> intercepts and responds to an allocate request, should   be treated
as

> > >>> A further advantage of detecting a sealed network configuration,

> > >>> is that a

> > >> and not be published publicly, which adds further to the complexity

> > >>> Kopia:  <mailto:[email-masked]> [email-masked]; Dan
Wing; Spencer Dawkins at IETF;

> > >> authentication) in the network to discover and use TURN services

> offered

> > >>>    the-middle attacks when accepting a TURN allocation response

> > >>>    of the following techniques with (D)TLS to validate the TURN

> server"

> > >>>    users in the local or access network.  However, this opens up a

> > >>>    server to a variety of attacks described in Section 17 of

> [RFC5766].

> > >>>    requests from the trusted local network or subscribers of the

> > >>>    access control by means of access-lists, firewalls, subscriber

> quota

<https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1>
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Nov 2016 08:27:37 -0500

Hi Karl,

I admit I am having difficulty following this thread. But this part
caught my attention because it seems to be core to the issues you are
raising...

Le 2016-11-20 à 15:24, Karl Stahl a écrit :
> ORthis mechanism, that we need, but does not work with a RFC5766 TURN
> configured to also return its unicast address in response by the
> *allocate *request):

Can you please explain why a TURN server cannot return a 300 response to
an Allocate request? It appears to be explicitly covered in RFC 5766
section "6.4. Receiving an Allocate Error Response":

   o  300 (Try Alternate): The server would like the client to use the
      server specified in the ALTERNATE-SERVER attribute instead.  The
      client considers the current transaction as having failed, but
      SHOULD try the Allocate request with the alternate server before
      trying any other servers (e.g., other servers discovered using the
      SRV procedures).  When trying the Allocate request with the
      alternate server, the client follows the ALTERNATE-SERVER
      procedures specified in [RFC5389].

Thanks,
-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 22 Nov 2016 02:45:21 +0000

Hi Karl,

I don't understand why the mechanism where TURN server has both anycast and unicast address for re-direction won't work ?

Cheers,
-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Monday, November 21, 2016 1:55 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams' <[email-masked]>; Prashanth Patil (praspati) <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at IETF' <[email-masked]>
Subject: Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery

Please understand that we need a working and clearly specified anycast method/mechanism for discovery of a TURN server (not some "alternate mechanism"):

"   When a client requires TURN services, it sends a TURN allocate

"

Seems to outline this mechanism (that we do not want, since it does not fulfill what we need):

d

OR this mechanism, that we need, but does not work with a RFC5766 TURN server (that must be USED by the allocate request, so it cannot be configured to also return its unicast address in response by the allocate request):

We need this mechanism (only involving the TURN server we are trying to discover) which simply can be done by configuring the TURN server to return its own unicast address in the 300 response to a binding request):

This text would replace modify/clarify the highlighted gray in version -10 of draft.

"When a TURN client wants to discover a TURN server, it sends a STUN binding request to the assigned TURN anycast address.  The server responds with a 300 (Try Alternate) error as described in [RFC5389].  The response contains an address in the ALTERNATE-SERVER attribute, which the TURN 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. The TURN server is thereby discovered. Any usage of the TURN server for relaying traffic, must use the discovered TURN server's unicast address, since two packets addressed to an anycast address may reach two different servers." [STOP section 6 here to avoid further confusion and whether there are TWO TURN servers involved or other things.]

"(A TURN server configured to be able to be discovered by this method, cannot be USED to create STUN bindings, but that is not what a network provided TURN server is used for.)"

FURTHER JUST TO REMIND AUTHORS of what is needed to be addresses in this draft; it is found in

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.

/Karl

Till: 'Brandon Williams'; 'Tirumaleswar Reddy (tireddy)'; 'Prashanth Patil (praspati)'; [email-masked]<mailto:[email-masked]>

Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'

Ämne: Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery

and a unicast address.

Some comments below.

Thanks,

Karl

----- Original Message -----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 03:59
Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery

-Tiru

> To: Karl Stahl <[email-masked]<mailto:[email-masked]>>; Tirumaleswar Reddy (tireddy)

> <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>;

> [email-masked]<mailto:[email-masked]>

> Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins

> at IETF' <[email-masked]<mailto:[email-masked]>>

> > (praspati); [email-masked]<mailto:[email-masked]>

> > Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'

> >>> To: 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>; Prashanth

> >>> (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> >>> Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer

> >>> Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>; Tirumaleswar Reddy

> >>> (tireddy) <[email-masked]<mailto:[email-masked]>>

> >>> Till: Karl Stahl; 'Prashanth Patil (praspati)'; [email-masked]<mailto:[email-masked]>

> >>> Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF';

> >>>> Från: tram [mailto:[email-masked]] För Prashanth Patil

> >>>> Till: [email-masked]<mailto:[email-masked]>

> >>>> Kopia: [email-masked]<mailto:[email-masked]>; Dan Wing; Spencer Dawkins at IETF;

> >>>> [email-masked]<mailto:[email-masked]>

> >>>> [email-masked]<mailto:[email-masked]>

> >>> [email-masked]<mailto:[email-masked]>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 22 Nov 2016 03:31:04 +0000

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

-Tiru

Sent: Monday, November 21, 2016 2:10 AM

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

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

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

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

> To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams'

> <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati)

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > From: tram [mailto:[email-masked]] On Behalf Of Brandon

> > To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; Karl Stahl

> > <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati)

> > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>

> > >> Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>; Tirumaleswar

> > >> intercepts and responds to an allocate request, should   be treated as

---

From: Karl Stahl <[email-masked]>
Date: Tue, 22 Nov 2016 18:39:52 +0100

Hi Simon,

I've taken real efforts discussing with Ingate's better knowing developers,
what the confusion around "anycast magics" may be and whether I am correct
in my "obvious view" that the discovery/usage anycast text in the -10 draft
does not work. I have not changed view ;-) but maybe gotten more insight in
possible confusions. So...

Simon> Can you please explain why a TURN server cannot return a 300 response
to an Allocate request?

Of course the TURN server can respond with error 300, but isn't the problem
that it then does NOT make any allocation that we can use for relaying
traffic?
 
If the TURN server to be discovered is configured to return its own IP
address in the 300 response, how can we then later use it (by sending the
same Allocate request for relaying traffic)? The TURN server will respond
with the 300 error response again, instead of actually making the allocation
needed, won't it?

(I think Brandon assumes a TURN server listening to TWO IP addresses that
can respond error 300 or make an allocation, distinguished by whether the
request was received on its anycast address or its unicast address, and I
think Prashanth using the term "TURN anycast server" means we really have
TWO TURN servers to play with, and I think others interpret the draft -10
text as if the FIRST Allocate is responded to with error 300 and SUBSEQUENT
Allocates actually are making allocations. The text under 3. in draft -10
"not all TURN servers may support anycast" indicates that some Author has
noticed the problem (or is maybe here assuming that the TURN server should
support some BGP routing setup* to get packets to the TURN server) - but
that text is not a remedy. I can NOT SEE ANY of the above behavior being
specified in RFC5766, can you?)

Is there any confusion around that my suggestion to use the Binding request
(instead of the Allocate request) to get the 300 response with the IP
address of the TURN server to use? That should work for TURN servers as
already defined and (the client's checking that the response comes from the
server being addressed, indicating to USE the TURN server there (not the
STUN server)) is also intuitive.

(Notice that a TURN server is an extension of a STUN server at the same IP
address = just one and the same normal TURN server. Also remember usage may
be later than discovery and may be used several times (applies to any
discovery)).

/Karl

* PS: For discovering a TURN server in the local or access network, I assume
a manual configuration in the default gateway/firewall/NAT/access router
that the TURN server is paralleling, not any BGP anycast setup, to get the
anycast addressed (UDP! https://tools.ietf.org/html/rfc5766#section-2.9)
packets to the TURN server.

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[email-masked]] 
Skickat: den 21 november 2016 14:28
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Brandon Williams';
'Prashanth Patil (praspati)'; [email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: [tram] Anycast discovery, was:
draft-ietf-tram-turn-server-discovery

Hi Karl,

Thanks,

---

From: Karl Stahl <[email-masked]>
Date: Tue, 22 Nov 2016 18:41:33 +0100

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.

Skickat: den 22 november 2016 04:31

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:[email-masked]] 
Sent: Monday, November 21, 2016 2:10 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams'
<[email-masked]>; Prashanth Patil (praspati)
<[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at
IETF' <[email-masked]>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

 

 

/Karl

 

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
[email-masked]

Hi Karl,

-Tiru

[email-masked]

whether

instructs

(praspati)

as

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Nov 2016 13:55:46 -0500

> that it then does NOT make any allocation that we can use for relaying

No because the client will retry its Allocate request to the unicast
address contained in the 300 response, which should then make an allocation.

> with the 300 error response again, instead of actually making the allocation

No, the TURN server will reply differently to requests received on its
anycast address vs its unicast address. Requests received on its anycast
address will get a 300 response, while those received on its unicast
address will get an Allocate success response.

> request was received on its anycast address or its unicast address,

Correct.

> TWO TURN servers to play with,

That would be an equally valid deployment scenario.

> and I think others interpret the draft -10
> Allocates actually are making allocations.

No, that would be wrong.

> The text under 3. in draft -10
> noticed the problem

No, it means that anycast may be difficult to implement depending on
specifics of the environment.

> (or is maybe here assuming that the TURN server should
> address of the TURN server to use?

There is no confusion, we just don't see the point of specifying another
mechanism when we already have one that works.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Nov 2016 03:14:44 +0000

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

Sent: Tuesday, November 22, 2016 11:12 PM

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.

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:[email-masked]]
Sent: Monday, November 21, 2016 2:10 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: Karl Stahl <[email-masked]>
Date: Wed, 23 Nov 2016 09:44:25 +0100

Hi again,

Focusing on TWO TURN servers or a TURN server listening to TWO IP addresses
that "will reply differently to requests received on its anycast address vs
its unicast address" (agreeing so far that it may work):

(i) >"I can NOT SEE" that the latter "behavior being specified in RFC5766,
can you?"

(ii) Isn't the aim of this specification to discover an ordinary (specified)
TURN server? (In analogy: We don't invent a "DHCP TURN server" just to
discover it by DHCP, do we?)

(iii) If we would specify such TURN server, can both these IP addresses be
on the same subnet (as they would be on the local network)? Deployed by a
*firewall configuration* (see extract from the return draft under my
signature), the anycast addressed packet can simply be directed to the TURN
server by a firewall rule in the default gateway, but it will then be no
anycast destination IP address in the packet (correct me if I am wrong) to
guide it into that extra IP address - the TURN server would just get the
anycast Allocate request on its unicast IP address, would it not (so there
is no way to reply differently)?

(iv) And for a TURN server in the local or access network, we certainly
don't want: "No, it means that anycast may be difficult to implement
depending on specifics of the environment."

Deployed* by the anycast addressed packet simply being directed to the TURN
server with a firewall rule in the default gateway and the TURN server
responding with its unicast address in the 300 response to a Binding request
(instead of to an Allocate request) should fix all of this (and avoid all
ambiguity), should it not?

And if the network provider want the network to be sealed at the default
gateway (by another firewall rule blocking UDP packets with a STUN cookie)
it will assure no other than the local TURN network provided server will be
used (and thus no leakage of anything).

Isn't all of this better?

/Karl

* Considering deployment, from draft-ietf-rtcweb-return-00 under
Introduction:
"...enterprise
   network operators may operate a TURN server for their network, which
   can be discovered by clients using TURN Auto-Discovery
   [I-D.ietf-tram-turn-server-discovery], or through a proprietary
   mechanism.  This TURN server may be placed inside the network, with a
   *firewall configuration* allowing it to communicate with the public
   internet, or it may be operated by a third party outside the network,
   with a *firewall configuration* that allows hosts inside the network to
   communicate with it."

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[email-masked]] 
Skickat: den 22 november 2016 19:56
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Brandon Williams';
'Prashanth Patil (praspati)'; [email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: SV: [tram] Anycast discovery, was:
draft-ietf-tram-turn-server-discovery

Correct.

No, that would be wrong.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Nov 2016 09:02:36 -0500

> (i) >"I can NOT SEE" that the latter "behavior being specified in RFC5766,

It's not, and it doesn't need to be, because that would be an
operational consideration with no bearing on the actual protocol (what
goes on the wire).

Sometimes operational considerations are published in informational
RFCs, most often after operational experience has been gained, but this
is not required. Most IETF protocols do not have such companion documents.

> discover it by DHCP, do we?)

Correct, there is no such concept of "ordinary" or "DHCP" TURN server.
There are only "TURN servers", but the way they are operated, and
consequently discovered, may differ vastly. Unless this has bearing on
the actual protocol, this is of no consequence, hence why only
informational text is supplied about this.

> on the same subnet (as they would be on the local network)?

Yes, depending on how routing is configured. But that would be highly
unusual.

> Deployed by a

That would be a highly unusual configuration, and if you allow me to
give my honest opinion, you'd be shooting yourself in the foot. Why not
NAT to a different UDP port, so that you are able to differentiate
unicast and anycast traffic?

> depending on specifics of the environment."

You may not want it, but this is fact, not opinion. Anycast *is*
difficult to implement in many real-world scenarios, and that does not
even imply TURN.

> Isn't all of this better?

I will not respond to those paragraphs because they ask questions that
are premature. With my chair hat on, problems with the current mechanism
need to be demonstrated before a solution can be proposed. This has not
yet happened.

---

From: Karl Stahl <[email-masked]>
Date: Sun, 27 Nov 2016 21:00:35 +0100

I just looked into the GUI of a Cisco 14890/Linksys EA2700 WiFi Router
having a single subnet for wireless and its 4 LAN ports. In a data crowded
environment it is in need of a paralleled TURN server for a path to the high
quality voip pipe in my triple play network access, especially with WebRTC
voice+video wanting 2.5 mbps through the access for one session.

Finding "Single Port Forwarding" in the router GUI, it should be able to
forward all STUN and TURN packets to a TURN server at the LAN, but I could
not find the routing table for adding a static anycast route, nor could I
find a way to create an extra subnet on the LAN side (or at all). The
Binding anycast discovery method should work, but not the discussed
separating between TWO TURN addresses. 

And under PS below, I highlight how a TURN server installed as described in
the RETURN draft (which this draft is supposed to service) cannot be
discovered by the anycast method when Allocate is used, but it can when
Binding is used.

And thinking further, will we not just delay this highly needed RFC further
by more demonstrations?...

Simon,

The more I look into this, and even if I would agree to all your
comments/answers below, we cannot accept a discovery draft that is highly
unclear, on what it is we are able to discover (TWO TURN servers or combined
into ONE, listening to TWO IP addresses, not described here or in RFC5766
(TURN protocol not being changed is no excuse)) and with a method
description that even qualified members of this WG have discussed in terms
of using DTLS for the anycast-addressed Allocate or Binding request packets
(anycast packets *are over UPD*) and similarly confused by the lack of
distinction between discovery and usage in the draft.

I understand and share the opinion that it is urgent to now finally get this
draft into place, but accepting the anycast method as it is in this version,
may add another decade to finally resolve the NAT/Firewall traversal problem
that has plagued real-time communication since SIP was introduced in early
2000, when we now are about to complete the ICE/STUN/TURN suit into
something deployable (as we know, instead of ICE, SBCs are still what is
used for NAT/Firewall traversal - we make them :-) - but SBCs are not usable
with WebRTC. 

The magic of exchanging the anycast addressed Allocate request to a Binding
request for getting the IP address of *the TURN server* is a resolution, and
the text for that update is already suggested. This method was proposed
already in October 2013 after detailed discussion on the RTCWEB list after
which the TRAM WG was formed
https://www.ietf.org/mail-archive/web/tram/current/msg00132.html
You Simon, already then, pointed out the two relevant issues/problems, 
https://www.ietf.org/mail-archive/web/tram/current/msg00138.html 
which I also in the suggested "Deployment Considerations for TURN Servers
Provided by the Local or Access Network" to be added, now have spelled out
the full solutions to (including the "leakage-problem" that is related to
your second issue raised at that time).

So, I think we safely and quickly can fix up this draft for becoming the
long awaited RFC that gets us an anycast method that at least works for
detecting "a TURN server" (OK, not "ordinary TURN server" and absolutely not
un-described "anycast TURN server"). And without having to bother about how
the then anycast addressed Binding arrives at *the TURN server*, we can
remove the "not all TURN servers may support anycast" under section 3 and
have no worries over that ">Anycast *is* difficult to implement in many
real-world scenarios,".

/Karl

PS: I don't agree to the "you'd be shooting yourself in the foot" comment,
which you made on a quote from draft-ietf-rtcweb-return-00, which this
specification should service with a working and deployable discovery method
(which I believe will be done by the changes suggested). Then there will be
no need to ">NAT to a different UDP port, so that you are able to
differentiate unicast and anycast traffic". I said something about "robust"
in my suggested deployment considerations to add to this draft - Robustness
must also be a goal for successful deployment and for this draft.

And, since the configuration described in draft-ietf-rtcweb-return-00, is
for USAGE of the TURN server paralleling the default gateway, those authors
could/should not foresee that we come up with a DISCOVERY method that will
complicate deployment configuration by requiring an extra subnet on the LAN
side (that may not be supported by the default gateway router). Using DHCP
for discovery, one would not have thought of this as a
shoot-yourself-in-the-foot deployment.

But DHCP is unfortunately not commonly available on many of the access
networks we use today (LTE.., IPv6) (and the DHCP discovery is also
unnecessarily complicated by going via domain name + DNS rather than
defining a new IANA DHCP option (but I not going to request such change :-)
since we cannot use DHCP discovery on all networks a WebRTC browser is
commonly used from anyway). We simply need the anycast discovery method for
WebRTC browsers' general usage.

The anycast discovery method must be clear, well defined and understood by
readers of the draft, and with the aim to work in all deployment scenarios
(for USAGE of such TURN server) and to be as robust and tolerant as
possible.

Let's do it! That is also faster and simpler than just making current method
clearly defined and understood.
(We are just making a small change to the method: Allocate -> Binding in the
DISCOVERY package to get all these advantages.)

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[email-masked]] 
Skickat: den 23 november 2016 15:03
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Brandon Williams';
'Prashanth Patil (praspati)'; [email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: SV: SV: [tram] Anycast discovery, was:
draft-ietf-tram-turn-server-discovery

---

From: Karl Stahl <[email-masked]>
Date: Sun, 27 Nov 2016 21:08:47 +0100

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

Skickat: den 23 november 2016 04:15

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

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

 

 

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

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

/Karl

*  <https://www.ietf.org/mail-archive/web/tram/current/msg02217.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02217.html 

-----Ursprungligt meddelande-----

Hi Karl,

-Tiru

[email-masked]

whether

instructs

(praspati)

as

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 28 Nov 2016 03:01:36 +0000

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

Sent: Monday, November 28, 2016 1:39 AM

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

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: Karl Stahl <[email-masked]>
Date: Mon, 28 Nov 2016 10:18:30 +0100

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

Skickat: den 28 november 2016 04:02

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

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

Hi Tiru,

 

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

 

 

/Karl

 

-----Ursprungligt meddelande-----

Hi Karl,

-Tiru

[email-masked]

whether

instructs

(praspati)

as

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 28 Nov 2016 09:53:19 +0000

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

Sent: Monday, November 28, 2016 2:49 PM

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

Hi Karl,

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

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

Hi Tiru,

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Nov 2016 08:30:58 -0500

Le 2016-11-27 à 15:00, Karl Stahl a écrit :
> forward all STUN and TURN packets to a TURN server at the LAN,

I'm not following, sorry. Why would you want to use port forwarding and
have to deal with NAT issues, while there are much simpler mechanisms
available to you?

> but I could
> find a way to create an extra subnet on the LAN side (or at all).

http://www.linksys.com/us/support-article?articleNum=135048

Step 5 shows how to configure static routing table entries.

This is a super common feature on home routers. As another example, I'm
currently using an Asus RT-AC66U and it also has that feature:

http://www.asus.com/us/support/FAQ/1011706/

Note however that the preferred deployment scenario here would be to
have the TURN server be embedded on the home router so as to have one
leg on the LAN and another on the WAN and thus avoid NAT. No need for
manual routing setup in this case, and the current anycast discovery
method would work perfectly.

> separating between TWO TURN addresses.

See above. In addition, your proposed alternative would require NAT,
which is a non-starter.

> by more demonstrations?...

(This discussion is not delaying anything. The DTLS one is.)

I will not respond to the paragraphs below because they ask questions
that are premature. Again with my chair hat on, problems with the
current mechanism need to be demonstrated before a solution can be
proposed. This has not yet happened.

Simon