Subject: [tram] Last Call: <draft-ietf-tram-turn-server-discovery-08.txt>; Anycast

From: Karl Stahl <[email-masked]>
Date: Mon, 8 Aug 2016 13:16:52 +0200

Reading this latest version, under:  

3.  Discovery Procedure

I stumble on: “… not all TURN servers may support anycast.”

This draft is somewhat unclear when talking about discovery and usage, but since 

no one suggests that TURN should be used with anycast addressing, this statement 

must indicate that the authors have noticed the proposed anycast discovery method 

doesn’t work with RFC5766  TURN servers. That has to change.

The current draft says:

 “ 6.  Discovery using Anycast

…

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

An RFC5766  TURN server doesn’t answer one thing (300 Try Alternate) when addresses 

by an anycast address and another thing when addresses with its unicast address 

(even if such TURN servers could be developed and possibly standardized…). 

Considering that a TURN server also includes a STUN server (when using the binding request) 

and that the STUN server also can respond with 300 Try alternate, 

I suggest the following modified method:

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

Or simply, a STUN server pointing out it’s own IP address as the alternate server, 

means that it is a network provided TURN server that should be used.

Further, this modified anycast method opens up a better way to deal with the security concern of: 

“9.  Security Considerations

9.3.  Anycast

   In a network without any TURN server that is aware of the TURN

   anycast address, outgoing TURN requests could leak out onto the

   external Internet, possibly revealing information.” 

(or resulting in that a far away turn server not meant to be used is selected)

in a better way than 

“Sensitive clients that do not wish to leak information about their

presence can set an IP TTL on their TURN requests that limits how 

far they can travel into the public Internet.”

For the use case of draft-ietf-rtcweb-return-01 (a TURN server deployed on a LAN 

to remedy firewall traversal and quality problems by taking real-time traffic through 

the server path, rather than through the default gateway of the firewall/router), 

the network configuration should also be sealed (i.e. the real-time traffic should be 

stopped from taking the “STUN path” through the default gateway (see the return draft 

for discussion of “sealed” versus “leaky”)) .  A sealed network configuration is best enforced 

by stopping STUN packets in the router/firewall/default gateway by detecting the STUN cookie.**

In the return use case, the client (the WebRTC browser) could then use this modified 

anycast method, after finding that known or application provided STUN servers give 

no response and one can be sure that the anycast STUN binding request goes to 

a server on the LAN (thus trusted and no leakage of TURN requests). 

Considering that the (modified) anycast method works on all network types, and it allows 

the TURN server network deployment to signal sealed behavior to a otherwise leaky configured 

WebRTC endpoint (by stopping STUN packets),  this should be the preferred discovery method 

for WebRTC endpoints. Web applications that wish to bypass usage of the network provided 

TURN server, can propose a (D)TLS-encrypted STUN address (which will not be stopped 

since the STUN cookie will not be detected).

With the ever more popular and capable WiFi networks, where data and real-time applications 

compete about the bandwidth, this modified discovery method opens up for WiFi routers products 

that include the TURN server and have a sealed behavior as their default network configuration. 

That would be highly desirable for the usage and spread of WebRTC communication. 

Further, under:

9.  Security Considerations

There are discussions of  “man-in-the-middle attacks” and of  “on-path packet injection.”

I think it needs to be clarified that protection against man-in-the-middle-attacks for real-time traffic 

through the TURN server, only is required if the application uses unencrypted media traffic 

(which is not the case with WebRTC).

/Karl

* I suggested similar in February, but Brandon Williams (with another use case in mind than a

network provided TURN server that does not need authentication), had hesitation about 

authenticating the STUN binding request instead of the TURN allocation request (while the 

authors of the draft did not respond at all). However, after a (private) discussion with Brandon, 

it seems like his intended D(TLS) authentication can/should be performed equally well at the 

unicast address to the TURN server (returned in the Try Alternate response), which is the same 

in both methods.

** We have verified that common rule based firewalls (at least Linux netfilter/IPtables based) 

can be configured to route the anycast STUN packet, while still stopping other packets containing 

the STUN cookie. 

Från: Karl Stahl [mailto:[email-masked]] 
Skickat: den 10 februari 2016 10:35
Till: 'Tirumaleswar Reddy (tireddy)'; 'Hutton, Andrew'; 'Benjamin Schwartz'
Kopia: 'Prashanth Patil (praspati)'; [email-masked]'
Ämne: SV: [tram] turn-server-discovery and return

I am also positive to the update below.

Further, 

 

6.  Discovery using Anycast needs improvement. 

It has two flaws that easily can be remedied: 

Current method : 

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

Flaw 1: Turn servers do not respond differently (Try alternate or OK) dependent on how they are addressed (by an anycast address or by a unicast address), do they?

Flaw 2: As already pointed out under  9.  Security Considerations, 9.3.  Anycast

“In a network without any TURN server that is aware of the TURN anycast address, outgoing TURN requests could leak out onto the external Internet, possibly revealing information. (I would also add that a far away bad TURN server might be used)... Sensitive clients that do not wish to leak information about their presence can set an IP TTL on their TURN requests that limits how far they can travel into the public Internet.”

It would be better, not to have to rely on the TTL limitation.

Considering that a TURN server also includes a STUN server (when using the binding request) and that the STUN server also can respond with 300 Try alternate, I suggest the following modified method:

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

Or simply, a STUN server pointing out it’s own IP address as the alternate server, means that server it is a network provided TURN server that should be used.

Flaw 1 does not occur.

Flaw 2 is completely avoided if  the client only tries this method when the enterprise/ISP enforces a sealed configuration (according to [I-D.ietf-rtcweb-return]) by stopping STUN packets in the router/firewall/default gateway by detecting the STUN cookie.

In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain its default leaky behavior, but be signaled by the local TURN server deployment (stopping STUN packets) to behave sealed, and only in such case try the (modified) anycast method for TURN discovery. Thus, TURN requests will never leak out of the local network.

We have verified that common rule based firewalls (at least Linux netfilter/IPtables based) can be configured to route the anycast STUN packet, while still stopping other packets containing the STUN cookie. 

Considering that the anycast method works on all network types, and it allows the TURN server network deployment to automatically signal sealed behavior to a leaky WebRTC endpoint (by stopping STUN packets),  this should be the preferred discovery method for WebRTC endpoints. A web application that wish to bypass usage of the network provided TURN server, can propose a DTLS-encrypted STUN address (which will not be stopped since the STUN cookie will not be detected).

/Karl