Subject: [BEHAVE] TURN and Anycast

From: Philip Matthews <[email-masked]>
Date: Sun, 27 Jul 2008 20:03:28 -0400

At the last BEHAVE meeting, there was a brief discussion of the idea  
of doing anycast discovery of TURN servers. This idea was subsequently  
discussed in more detail during the TURN conference call on April 8th.  
Though the idea sounds attractive, there are a number of issues to  
overcome. This e-mail is an attempt to summarize the current state of  
play, and to make a proposal for how to move forward.

Let's start by considering UDP transport between the client and the  
server. The ALTERNATE-SERVER attribute seems to provide an easy way to  
do anycast redirection, but there are a few issues to overcome. The  
first issue is that draft-ietf-behave-rfc3489bis-17 requires that any  
response containing an ALTERNATE-SERVER attribute be authenticated. To  
authenticate the response requires 2 round trips, and the official  
position of the IESG today is that we cannot depend on having both  
round trips interact with the same server. To overcome this problem,  
we can remove the requirement that the response containing ALTERNATE- 
SERVER be authenticate, which reduces the exchange to a single round  
trip. Thus we have an outgoing Allocate request which is sent to an  
anycast address, to which the TURN server responses with an Allocate  
response containing an ALTERNATE-SERVER attribute redirecting the  
client to the server's unicast address.

At this point, the question is: How does the client know it is still  
talking to the same server? In particular, what about an attack where  
an attacker sends an Allocate response redirecting the client to some  
rogue server? It was originally argued (by yours truly) that the rogue  
server would not know the password assigned to the client, and thus  
could not authenticate its replies, but Cullen pointed out that rogue  
server could do a Man-in-the-Middle attack and thus avoid the need to  
know the password.

I see two possible options for avoiding this Man-in-the-Middle attack.  
The first option is to use certificates to authenticate the server,  
like TLS does. The second option is to change how STUN does  
authentication so that the message integrity value includes a pseudo- 
header containing the address of the server and the mapped address of  
the client. I haven't worked out the details of this second option,  
but it seems like it might prevent the MitM attack.

[As an aside, one might ask: Why would one want to operate a rogue  
TURN server? If the actual data packets are encrypted, which they  
should be, then the main attack I see now is the ability to launch  
various denial-of-service attacks against the client.]

Let's look now at TCP or TLS transport between the client and the  
server. Given the official IESG position that 2 round trips will not  
necessarily interact with the same server, it is clear that a TCP- 
based anycast mechanism is not possible without changes to TCP itself.  
So the only option is to use a UDP exchange to determine the unicast  
address, followed by the establishment of a TCP or TLS connection for  
the rest of the messages. The drawback with this option is that it  
doesn't work when the client is behind a firewall that blocks UDP, but  
there does not seem to be another IESG-acceptable option.

In my view, there are a number of issues that need to be worked out  
before a full anycast proposal is fully baked. Given these issues, my  
proposal is leave the details of anycast discovery to some subsequent  
document. However, to allow anycast to be more easily added later, I  
propose that the requirement that the ALTERNATE-SERVER attribute  
appear only in an authenticated response be removed (this is a draft- 
ietf-behave-rfc3489bis change). Furthermore, TURN would allow  
ALTERNATE-SERVER in Allocate responses (with the restriction that it  
not be used as an alternate to SRV handling, but is intended for  
anycast and the like). With these changes, a TURN client could either:
a) accept the redirection without question if it was not concerned  
about a possible MitM attack, OR
b) attempt to connect to the alternate address using TLS and thus  
verify the credentials if it was concerned.

With this proposal, I am attempting to advance TURN as quickly as  
possible, while remaining consistent with the consensus of the April  
8th conf call on TURN, as shown by the following quote from the  
minutes of that call (see the e-mail from me on April 8th entitled  
"Minutes of TURN conf call on 8 April 2008"):

> 4. Anycast and ALTERNATE-SERVER
> There was another long discussion about anycast and ALTERNATE-SERVER.
> It was agreed that TURN would not specify all the details about how
> anycast discovery of a server would work, but just specify some
> necessary pieces. A full anycast discovery procedure could then be
> advanced as a separate document (though note that BEHAVE does not have
> a milestone for such a document).
>

Comments?

- Philip

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

---

From: Philip Matthews <[email-masked]>
Date: Sun, 27 Jul 2008 20:38:59 -0400

Shortly after I sent the e-mail below, I realized that the proposal I  
made is not very attractive to client implementors. Thinking about  
things some more, I have the following alternative proposal:

For now, we keep the requirement that Allocate responses containing  
ALTERNATE-SERVER be authenticated. Though this means that 2 round  
trips are required, I will note that:
(a) in some situations, it is highly likely that both round trips will  
take place with the same server, AND
(b) in other situations, it can be arranged that the REALM and NONCE  
values issued by one server are acceptable to another server of the  
same server group.

With authenticated redirections, the concern over redirecting to a  
rogue server goes away.

Finally, I propose not to solve anycast for TCP and TLS in the base  
TURN document.

Though this is not a perfect solution, it seems to allow some ability  
for servers and clients to do anycast discovery of servers.

Comments (on either the first or second proposal)?

- Philip

On Sun, 27-Jul-08, at 20:03 , Philip Matthews wrote:
> of doing anycast discovery of TURN servers. This idea was  
> subsequently discussed in more detail during the TURN conference  
> call on April 8th. Though the idea sounds attractive, there are a  
> number of issues to overcome. This e-mail is an attempt to summarize  
> the current state of play, and to make a proposal for how to move  
> forward.
>
> server. The ALTERNATE-SERVER attribute seems to provide an easy way  
> to do anycast redirection, but there are a few issues to overcome.  
> The first issue is that draft-ietf-behave-rfc3489bis-17 requires  
> that any response containing an ALTERNATE-SERVER attribute be  
> authenticated. To authenticate the response requires 2 round trips,  
> and the official position of the IESG today is that we cannot depend  
> on having both round trips interact with the same server. To  
> overcome this problem, we can remove the requirement that the  
> response containing ALTERNATE-SERVER be authenticate, which reduces  
> the exchange to a single round trip. Thus we have an outgoing  
> Allocate request which is sent to an anycast address, to which the  
> TURN server responses with an Allocate response containing an  
> ALTERNATE-SERVER attribute redirecting the client to the server's  
> unicast address.
>
> talking to the same server? In particular, what about an attack  
> where an attacker sends an Allocate response redirecting the client  
> to some rogue server? It was originally argued (by yours truly) that  
> the rogue server would not know the password assigned to the client,  
> and thus could not authenticate its replies, but Cullen pointed out  
> that rogue server could do a Man-in-the-Middle attack and thus avoid  
> the need to know the password.
>
> I see two possible options for avoiding this Man-in-the-Middle  
> attack. The first option is to use certificates to authenticate the  
> server, like TLS does. The second option is to change how STUN does  
> header containing the address of the server and the mapped address  
> of the client. I haven't worked out the details of this second  
> option, but it seems like it might prevent the MitM attack.
>
> based anycast mechanism is not possible without changes to TCP  
> itself. So the only option is to use a UDP exchange to determine the  
> unicast address, followed by the establishment of a TCP or TLS  
> connection for the rest of the messages. The drawback with this  
> option is that it doesn't work when the client is behind a firewall  
> that blocks UDP, but there does not seem to be another IESG- 
> acceptable option.
>
>
> before a full anycast proposal is fully baked. Given these issues,  
> my proposal is leave the details of anycast discovery to some  
> subsequent document. However, to allow anycast to be more easily  
> added later, I propose that the requirement that the ALTERNATE- 
> SERVER attribute appear only in an authenticated response be removed  
> (this is a draft-ietf-behave-rfc3489bis change). Furthermore, TURN  
> would allow ALTERNATE-SERVER in Allocate responses (with the  
> restriction that it not be used as an alternate to SRV handling, but  
> is intended for anycast and the like). With these changes, a TURN  
> client could either: