Subject: [BEHAVE] Proposed Resolutions to COMMENTs and DISCUSSes on TURN

From: Philip Matthews <[email-masked]>
Date: Sat, 11 Apr 2009 20:59:19 -0400

Here are my proposed resolutions to various DISCUSSes and COMMENTs from the IESG evaluation of TURN-13 (draft-ietf-behave-turn-13)
See https://datatracker.ietf.org/idtracker/draft-ietf-behave-turn/

Responses to the other DISCUSSes and COMMENTs are already being discussed elsewhere.

- Philip

From Alexey Melnikov:

Comment:

In Section 6.2: 5. The server checks if the request contains an EVEN-PORT attribute. If yes, then the server checks that it satisfy the request.

Missing word: ... that it *can* satisfy ...

Fixed.

---

From Tim Polk:

Comment:section 2, next-to-last paragraph:

s/to application data/to send application data/

Fixed.

section 2.4, para 3:

s/an XOR-PEER-ADDRESS attribute specify/an XOR-PEER-ADDRESS attribute specifying/

Fixed.

---

From Cullen Jennings:

Comment:

Seems weird that we can negotiate lifetimes of allocations but not permissions or channels bindings. Why?

Myself, I don't see right now any reason to negotiate permission lifetimes or channel binding lifetimes. I don't currently see any reason an application would want to make these lifetimes smaller, and I feel the default values (5 minutes and 10 minutes, respectively) are sufficiently long enough so as not to be a burden on applications.

If I was doing TURN over again, I would argue for removing the ability to negotiate allocation lifetimes, as 10 minutes seems to be fine for this purpose, and the ability to negotiate the lifetime just adds complexity.

I suggest we wait until we get more deployment experience with TURN and see if there is a solid need to make these negotiable.

Comment:

Padding up the Channel Data messages over TCP is a waste of bandwidth - why is it needed?

This was done to be consistent with STUN-formatted messages of TURN. All the STUN-formatted messages are a multiple of 4 bytes. Padding Channel Data messages means that all TURN messages on the TCP stream (both the Channel Data messages and the STUN-formatted messages) are multiples of four bytes and will thus always start on a 4-byte boundary. This may help with the parsing of incoming messages. Not padding Channel Data messages would break the alignment for the STUN-formatted messages.

I agree that there are protocols that take a different approach (for example, BGP attributes are not padded that thus a parser can not make alignment assumptions).

This was briefly discussed on the BEHAVE mailing list a couple of months ago, and there was no support at the time for changing this.

Discuss:

Refresh's, allocations, permission, and channel bindings request MUST be authenticated to meet the security requirements.

I view this as a repeat of Tim Polk's DISCUSS, which is currently being discussed on the BEHAVE mailing list.

Discuss:

The lack of authentication on the redirect response makes it trivial to DDOS any set of clients trying to use a STUN server by just redirecting them to a server that does not work.

This is a feature of STUN, which is simply inherited by TURN. You will recall that redirect responses in STUN used to be authenticated, and was removed at your request so you could do anycast discovery of TURN servers. Anyway, see RFC 5389 (the STUN specification) for the security discussion of this feature. For TURN, you can indeed DDOS a set of clients in this way, but you have to have an attacker at just the right point to do this. Such an attacker can DDOS the clients in many other ways (e.g., by quickly sending a 400 Bad Request reply to the initial Allocate request before the server can reply). I am not an expert here, but I believe that even a TLS session is not immune to such an attacker, as the attacker can send a TCP RST in response to the initial TCP SYN.

Discuss:

Section 10.3 needs to say the server MUST discard the packet if there is no permission to meet the security requirements.

Actually, it is right there in the last sentence of the first paragraph:

When the server receives a UDP datagram at a currently allocated
relayed transport address, the server looks up the allocation
associated with the relayed transport address.  It then checks to see
if relaying is permitted, as described in Section 8.
Section 8 is the section that discusses permissions.

---

From Adrian Farrel:

Comment:
I understand that other-then-UDP mechanisms for server-peer communications will follow, but I find it confusing that the Introduction discusses client-server TCP and TLS services since the client is presumably actually interested in client-peer delivery. Also that Figure 1 shows a peer behind a NAT and the text comments that some firewalls block UDP entirely.

Would it be helpful to draw out more clearly what deployments and service functions are not possible with the UDP-only variety of TURN? (There is some discussion in section 2.4 of the security of the server-peer data being the protected through encryption or similar.)

I confess to being unsure what more I could say, probably because I am so close to this work that everything seems obvious. There were some paragraphs about this in TURN-13, but I have reworked them a bit so they now say:

Since this version of TURN only supports UDP between the server and

the peer, it is expected that most clients will prefer to also use

UDP between the client and the server. That being the case, some

readers may wonder: Why also support TCP and TLS over TCP?

TURN supports TCP transport between the client and the server because

some firewalls are configured to block UDP entirely.  These firewalls

block UDP but not TCP in part because TCP has properties that make

the intention of the nodes being protected by the firewall more

obvious to the firewall.  For example, TCP has a three-way handshake

that makes in clearer that the protected node really wishes to have

that particular connection established, while for UDP the best the

firewall can do is guess which flows are desired by using filtering

rules.  Also, TCP has explicit connection teardown, while for UDP the

firewall has to use timers to guess when the flow is finished.

TURN supports TLS over TCP transport between the client and the

server because TLS provides additional security properties not

provided by TURN's default digest authentication; properties which

some clients may wish to take advantage of.  In particular, TLS

provides a way for the client to ascertain that it is talking to the

server that it intended to, and also provides for confidentiality of

TURN control messages.  TURN does not require TLS because the

overhead of using TLS is higher than that of digest authentication;

for example, using TLS likely means that most application data will

be doubly encrypted (once by TLS and once to ensure it is still

encrypted in the UDP datagram).

Is this better?

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 15 Apr 2009 22:25:55 +0100

Hi Philip,

> From Adrian Farrel:
>>  Comment:
>> I understand that other-then-UDP mechanisms for server-peer 
>> communications
>> will follow, but I find it confusing that the Introduction discusses 
>> client-server
>> TCP and TLS services since the client is presumably actually interested 
>> in
>> client-peer delivery. Also that Figure 1 shows a peer behind a NAT and 
>> the
>> text comments that some firewalls block UDP entirely.
>>
>> Would it be helpful to draw out more clearly what deployments and service
>> functions are not possible with the UDP-only variety of TURN? (There is
>> some discussion in section 2.4 of the security of the server-peer data 
>> being
>> the protected through encryption or similar.)
>
> I confess to being unsure what more I could say, probably because I am so
> close to this work that everything seems obvious. There were some 
> paragraphs
> about this in TURN-13, but I have reworked them a bit so they now say:
>
>

Well, I only raised a Comment, and you have made some attempt to address it. 
So thank you, and move on.

Adrian