Subject: [BEHAVE] Proposed resolutions for TURN open issues

From: Philip Matthews <[email-masked]>
Date: Wed, 30 Jul 2008 22:03:13 -0400

There was an ad-hoc meeting on TURN  on Wednesday, July 31. During  
this meeting, all the open issues affecting TURN were discussed and  
proposals for how to resolve them reached. Jonathan and I then held a  
phone call to discuss and in a couple of cases made minor tweaks. This  
e-mail documents the proposed resolutions. Please comment if you are  
not happy with any of these.

    1.  Detecting in-use channels.  Do we need a way for a client to
        determine if a channel is currently bound?  Right now, the only
        way is to try to bind it to an address.

This issue was prompted by concerns that the client and server might  
get out-of-sync over which channels were bound. A concrete example of  
this concern was when a client retransmitted a ChannelBind msg over  
UDP. If the first transmission generated a failure response, but the  
second generated a success response, then the client would believe  
that the channel was not bound, but the server would believe the  
channel is bound.

The proposed resolution to this issue is to not add any way for the  
client to determine which channels are bound, but to add text  
explicitly saying that a client should abandon an allocation if it  
receives an error response to a ChannelBind command. The idea is that  
any mismatch between the client and the server in this area is very  
serious, and starting over is the best way to recover.

--

    2.  Public TURN servers.  The spec currently hints (but does not say
        anything solid) that the way to run a publicly-accessable TURN
        server is to not require authentication.  But perhaps a better
        way is to require authentication but have some unspecified  
method
        to allow any user to create an account on the server.

After discussion in the ad-hoc, we propose to say nothing about this.  
The current text, which does really say anything about this, would  
remain unchanged. The rationale is that this is a protocol document,  
not an operational guidance document.

--

    3.  IPv6.  Currently, TURN supports IPv4-to-IPv4 relaying, and IPv6-
        to-IPv6 relaying, but does not support IPv4-to-IPv6 relaying.   
To
        ensure this, a server requires that the family of the relayed
        address match that of the 5-tuple as seen by the server.
        However, some people would like to see a different rule.

The proposed resolution is to move the specification of IPv6-to-IPv6,  
IPv4-to-IPv6, and IPv6-to-IPv4 relaying to draft-ietf-behave-turn- 
ipv6. The base TURN specification would handle only IPv4-to-IPv4  
relaying. The base spec would say that the server address and all  
relayed addresses must be IPv4 addresses.

This proposal ensures that client can know in advance what family (v4  
or v6) the relayed-transport-address returned by the server will  
always be of. Some people had objected to the scheme in TURN-09  
because the client might send the Allocate request over IPv6, but  
unbeknownst to the client, the request might pass through a NAT64 and  
arrive at the server at an IPv4 address. If this happened, the client  
would get back an IPv4 relayed-transport-address when it really wanted  
an IPv6 relayed-transport-address. This proposal addresses their  
concern, while also moving all the complexity around IPv6 and IPv4 <->  
IPv6 to draft-ietf-behave-turn-ipv6, where we have more time to study  
it and get it right.

--

    4.  ALTERNATE-SERVER and Anycast.  The details of ALTERNATE-SERVER
        support are still under discussion.  In particular, some people
        would like to use ALTERNATE-SERVER to support anycast discovery
        of a TURN server.

The proposed resolution is as follows:
a) The TURN spec would allow the use of ALTERNATE-SERVER in replies to  
Allocate requests. Furthermore, the text would override the STUN spec  
and allow the use of ALTERNATE-SERVER in unauthenticated Allocate  
error responses. If the client receives such a response, then the  
client SHOULD retry the Allocate transaction with the new address.  
However, the client MUST check that the realm value received back from  
the new server is as expected and must use the same username and  
password as it would have with the original server. In practice, this  
means that the client must have known in advance what realm, username  
and password to use with the original server, and uses these same  
values with the alternate server. With this check, the client can  
ensure that the original and alternate server are part of the same  
authentication group.
b) The spec would NOT go into detail on how this mechanism can be used  
to do anycast discovery. This would be left to another document.

In summary, the spec would provide the basic pieces required, but  
would not go into details on how to use those pieces.

--

    5.  Authenticated Permission Refresh.  Currently, permissions can be
        refreshed by unauthenticated Send indications and ChannelData
        messages.  Some have suggested that this is a security issue.

The discussion of this issue at the BEHAVE meeting on Tuesday was  
inconclusive. At the ad-hoc, there was further discussion and it was  
realized that the attack described in the slides presented at the  
BEHAVE meeting was easier to perform that we realized earlier. Given  
this realization, the people at the ad-hoc meeting agreed on the  
following (options 3 and 4 combined from the slides):
a) In addition to a Send indication, TURN will support a Send request/ 
response transaction.
b) Permissions will no longer be installed or refreshed by Send  
indications or ChannelData msgs. Instead, permissions will be  
installed or refreshed by ChannelBind transactions (as in turn-09) and  
by the new Send request/response transaction. Since both of these are  
request/response, they can be authenticated.
c) The semantics of the new Send request/response is very similar to  
the existing Send indication: it would take the same attributes, etc.  
Specifically, it would have two forms: one with and one without the  
DATA attribute; the 'without' form would only install or refresh  
permissions, while the 'with' form would also send data.
d) In addition, the client would check that Data messages are being  
received from peer with which it thinks it has a permission. If the  
client believes there is no permission, the client would discard the  
data.

--

    6.  PMTUD for non-preserving allocations.  Some people would like a
        way to do PMTUD even if the allocation is non-preserving, and
        have suggested that a way for the client to indicate to the
        server (in a Send indication) that the DF bit should be set when
        sending to the peer might allow this.

There was hot discussion of this issue at the ad-hoc. Finally, it was  
agreed that the mechanism suggested by Cullen would be added to the  
TURN specification, to whit:
a) A new attribute would be defined for use in a Send indication. If  
this attribute is present, then the server would set the DF bit when  
sending the UDP datagram to the peer.

--

    7.  Security.  The security consideration section is out-of-date  
with
        the changes to the rest of the draft, and it has been suggested
        that TURN might require TLS to provide proper security.   
Updating
        the security consideration section will answer this question.

The above changes fix all known security holes. Never-the-less, the  
authors plan to rewrite the security considerations section ASAP,  
which would involve taking another hard look at TURN security.

Comments?

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 Jul 2008 05:59:37 -0400

Couple of minor clarifications to Philip's excellent summary:

Philip Matthews wrote:

>        to-IPv6 relaying, but does not support IPv4-to-IPv6 relaying.  To
> IPv4-to-IPv6, and IPv6-to-IPv4 relaying to draft-ietf-behave-turn-ipv6. 
> The base TURN specification would handle only IPv4-to-IPv4 relaying. The 
> base spec would say that the server address and all relayed addresses 
> must be IPv4 addresses.

A consequence of this is that the REQUESTED-TRANSPORT attribute will be 
removed from TURN and moved to draft-ietf-behave-turn-ipv6.

> and allow the use of ALTERNATE-SERVER in unauthenticated Allocate error 
> responses.

The override is specifically for the case where a request is received on 
an anycast address. This would require the server to know that one of 
its addresses is an anycast address (presumably through configuration). 
Of course, per text below, the redirection can only be to another server 
with access to the same credentials as the server performing the 
redirection.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 31 Jul 2008 11:08:51 +0100

Jonathan Rosenberg wrote:
>> IPv4-to-IPv6, and IPv6-to-IPv4 relaying to 
>> draft-ietf-behave-turn-ipv6. The base TURN specification would handle 
>> only IPv4-to-IPv4 relaying. The base spec would say that the server 
>> address and all relayed addresses must be IPv4 addresses.
> 

REQUESTED-TRANSPORT specifies the protocol to use (UDP or TCP)

REQUESTED-ADDRESS-TYPE attribute is defined in turn-ipv6 and specifies
the address family of the relayed address

did you mean REQUESTED-ADDRESS-TYPE ? I think we should keep
REQUESTED-TRANSPORT in the base turn spec. If you really want to move
it, the turn-tcp spec is a better candidate.

/alfred

[...]

---

From: Simon Perreault <[email-masked]>
Date: Thu, 31 Jul 2008 11:12:23 +0100

Philip Matthews wrote:
> client believes there is no permission, the client would discard the data.

Make it clear that this does *not* imply that clients should track 
permissions accurately (i.e. with timers and such).

e.g.

    When the client receives a Data indication, it checks that the Data
    indication contains both a PEER-ADDRESS and a DATA attribute, and
    discards the indication if it does not. ++The client MUST discard the
    indication if the PEER-ADDRESS attribute value is unexpected.++

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Thu, 31 Jul 2008 08:53:52 -0400

On Thu, 31-Jul-08, at 06:08 , Alfred E. Heggestad wrote:
>>> The proposed resolution is to move the specification of IPv6-to- 
>>> IPv6, IPv4-to-IPv6, and IPv6-to-IPv4 relaying to draft-ietf-behave- 
>>> turn-ipv6. The base TURN specification would handle only IPv4-to- 
>>> IPv4 relaying. The base spec would say that the server address and  
>>> all relayed addresses must be IPv4 addresses.
>> A consequence of this is that the REQUESTED-TRANSPORT attribute  
>> will be removed from TURN and moved to draft-ietf-behave-turn-ipv6.
>

Alfred:

You are right. I had confused REQUESTED-TRANSPORT and REQUESTED- 
ADDRESS-TYPE at the ad-hoc meeting (and only later realized my  
mistake), which is probably why Jonathan mentioned it.

Unless folks have a strong desire for us to change things, we will  
leave the REQUESTED-TRANSPORT mechanism as is: namely, the attribute  
must be included by the client, but the base specification only  
supports a requested transport of UDP.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 Jul 2008 08:59:16 -0400

My bad - I somehow thought that attribute had moved into TURN but its 
not there. REQUESTED-TRANSPORT stays in TURN as is, of course.

-Jonathan R.

Alfred E. Heggestad wrote:
>> A consequence of this is that the REQUESTED-TRANSPORT attribute will 
>> be removed from TURN and moved to draft-ietf-behave-turn-ipv6.
>>
>>
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 31 Jul 2008 11:42:34 -0400

>   indication if the PEER-ADDRESS attribute value is unexpected.++

Ok, I have taken Simon's suggestion and updated the text in TURN as  
shown below. Since this issue does not affect interoperability, I have  
reduced the MUST to a SHOULD.

9.4.  Receiving a Data Indication

    When the client receives a Data indication, it checks that the Data
    indication contains both a PEER-ADDRESS and a DATA attribute, and
    discards the indication if it does not.  The client SHOULD also  
check
    that the PEER-ADDRESS attribute value contains an IP address with
    which the client believes there is an active permission, and discard
    the Data indication otherwise.

       NOTE: The latter check protects the client against an attacker  
who
       somehow manages to trick the server into installing permissions
       not desired by the client.

    If the Data indication passes the above checks, the client delivers
    the data octets inside the DATA attribute to the application, along
    with an indication that they were received from the peer whose
    transport address is given by the PEER-ADDRESS attribute.

- Philip

---

From: "Benny Prijono" <[email-masked]>
Date: Thu, 31 Jul 2008 22:38:51 +0100

On Thu, Jul 31, 2008 at 3:03 AM, Philip Matthews
<[email-masked]>wrote:

> There was an ad-hoc meeting on TURN  on Wednesday, July 31. During this
> meeting, all the open issues affecting TURN were discussed and proposals for
> how to resolve them reached. Jonathan and I then held a phone call to
> discuss and in a couple of cases made minor tweaks. This e-mail documents
> the proposed resolutions. Please comment if you are not happy with any of
> these.
>
> This issue was prompted by concerns that the client and server might get
> out-of-sync over which channels were bound. A concrete example of this
> concern was when a client retransmitted a ChannelBind msg over UDP. If the
> first transmission generated a failure response, but the second generated a
> success response, then the client would believe that the channel was not
> bound, but the server would believe the channel is bound.
>
>
I thought that (as per the last discussion on this list), any STUN servers
(TURN included) MUST retransmit the last error response upon receiving
request retransmissions, so this shouldn't be an issue, should it?

> The proposed resolution to this issue is to not add any way for the client
> to determine which channels are bound, but to add text explicitly saying
> that a client should abandon an allocation if it receives an error response
> to a ChannelBind command. The idea is that any mismatch between the client
> and the server in this area is very serious, and starting over is the best
> way to recover.
>
>
I don't think I would like the text. First of all, not all error responses
means out of sync (for example, 438/Stale Nonce). Second, I feel that it
should be left to client to decide what to do when such mismatch happens
(which shouldn't happen in the first place because of error retransmission
requirement above).

So the solution does not solve the question. And personally I don't think
this is a question that needs to be solved either, since client totally
controls the channel numbers, and out-of-sync can't happen if server
retransmits error responses.

Cheers
 Benny