Subject: [BEHAVE] Review of draft-ietf-behave-turn-07

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Mar 2008 08:18:29 -0800

$Id: draft-ietf-behave-turn-07-rev.txt,v 1.1 2008/02/26 20:24:47 ekr Exp $

This version is much improved. Comments follow

GENERAL
This document has a large number of timers with arbitrary
appearing values:

- 1 minute backoff transaction timers
- 2 minute port holddown timers
- 10 minute lifetime timers
- 5 minute permission timers

It's particularly confusing that some of the error conditions
have 1 minute timers whereas others have 2 minutes. 

Each timer should come with a justification for its size.

It appears that the 2 minute timer comes from MSL. Although
RFC 793 specifies 2 minutes, according to Stevens,
MSL varies quite a bit (from 30s in Net/3 to 2 min in
RFC 793). I also wonder whether MSL or 2MSL is appropriate
in some of these cases.

TECHNICAL
S 5.

   5-tuple are re-used in other allocations until 2 minutes after the
   allocation expires; this ensures that any messages that are in
   transit when the allocation expires are gone before either of these
   transport addresses are re-used.

I think this needs to be 2MSL because Alice might have just
sent a packet which prompts a response from the peer

Consider the following sequence (numbers are in seconds)

Alice      Bob           Server               Peer 
--------------------------------------------------
0: Send Indication -------->
1:                       UDP packet ------------>  (arrives at MSL+1)
2: Allocate(0) ------------>                  
MSL+1:     Allocate -------> <---------- UDP packet (arrives at MSL+2)
MSL+2:      <--- Data indic.

Actually, we have no real idea what the peer's think time is so
2MSL is too short, but it's more justifiable than MSL.

S 6.1.
   The client first needs to pick a host transport address that the
   server does not think is currently in use, or was recently in use.
   The client SHOULD pick a currently-unused transport address on the
   client's host (typically by allowing its OS to pick a currently-
   unused port for a new socket).

Is there some reason the ordinary rules don't work here?

   between the server and the peers, it is RECOMMENDED that the client
   pick UDP unless it has a reason to use a different transport.  One

What's the reason for this recommendation?

   The client must also pick a server transport address.  Typically,
   this is done by the client learning (perhaps through configuration)
   one or more domain names for TURN servers.  In this case, the client
   uses the DNS procedures described in [I-D.ietf-behave-rfc3489bis],
   but using an SRV service name of "turn" (or "turns" for TURN over
   TLS) instead of "stun" (or "stuns").  For example, to find servers in
   the example.com domain, the client performs a lookup for
   '_turn._udp.example.com', '_turn._tcp.example.com', and
   '_turns._tcp.example.com' if the client wants to communicate with the
   server using UDP, TCP, or TLS over TCP, respectively.

Is this normative?

S 6.2.
I still think ALTERNATE-SERVER is a bad idea.

S 6.3.
   o  437 (Allocation Mismatch): This indicates that the client has
      picked a 5-tuple which the server sees as already in use or which
      was recently in use.  One way this could happen is if an
      intervening NAT assigned a mapped transport address that was
      recently used by another allocation.  The client SHOULD pick
      another client transport address and retry the Allocate request
      (using a different transaction id).  The client SHOULD try three
      different client transport addresses before giving up on this
      server.  Once the client gives up on the server, it SHOULD NOT try
      to create another allocation on the server for 2 minutes.

This three times and two minutes seems awful arbitrary.

S 10.
   A channel binding last for 10 minutes unless refreshed.  Refreshing
   the binding (by the server receiving either a ChannelBind request
   rebinding the channel to the same peer, or by the server receiving a
   ChannelData message on that channel) resets the time-to-expire timer
   back to 10 minutes.  When the channel binding expires, the channel
   becomes unbound and available for binding to a different transport
   address.

This isn't quite the way I remember things from our call. This was
pitched as a form of memory cleanup, not channel reclamation.
I had assumed that the channel would be forbidden for future
use except for the same remote address. That seems far safer.
(And yes, I realize that the server cannot necessarily enforce
it, which is arguably even more of a reason why it's a good idea).

S 10.2.
   o  The channel number is not currently bound to a different transport
      address (same transport address is OK);

Why is this actually a problem if it is?

S 10.7.
   that sent the UDP datagram.  If there is, then it SHOULD form and
   send a ChannelData message as described in Section 10.5.  If no
   channel is bound to the peer, then it MUST form and send a Data
   indication as described in Section 9.3.

Why is this SHOULD and then MUST? Especially because it looks like 10.5 makes
it a MUST.

S 11.4.
      Applications that instead restrict their packet size to 576 or
      1280 may suffer from the fact that TURN adds some overhead between
      the client and the server.  Thus in some situations, these
      applications will see their maximum-sized packets dropped.
      However, this overhead is only 4 bytes when channels are used, so
      the chances of this happening are small.

I don't think this analysis is correct. Neither the distribution of
packet sizes nor of MTUs is uniform. If the UDP application on top
restricts its packet size to 576 and there's an element with that
MTU in the way, then the chance of this happening is unity.

S 15.
   however.  To prevent a single malicious user from allocating all of
   the resources on the server, it is RECOMMENDED that a server
   implement a modest per user limit on the amount of bandwidth that can
   be allocated.  Such a mechanism does not prevent a large number of
   malicious users from each requesting a small number of allocations.
   Attacks such as these are possible using botnets, and are difficult
   to detect and prevent.  Implementors of TURN should keep up with best
   practices around detection of anomalous botnet attacks.

This is certainly one implementation, but another would be to have
short allocation lifetimes and progressively dial back the bandwidth
given each user as demand grows. Why recommend one technique?

It seems like a section on the security of RESERVATION-TOKEN is
appropriate. ISTR Cullen's initial proposal had something here.

EDITORIAL
Abstract:
   The TURN protocol can be used in isolation, but is more properly used
   as part of the ICE (Interactive Connectivity Establishment) approach
   to NAT traversal.

See complaints about this in my previous review.

S 2.1.
   For TURN clients, using TLS over TCP to communicate with the TURN
   server provides two benefits.  First, the client can be assured that
   the addresses of its peers are not visible to any attackers between
   it and the server.  Second, the client may be able to communicate
   with TURN servers using TLS when it would not be able to communicate
   with the same server using TCP or UDP, due to the policy of a
   firewall between the TURN client and its server.  In this second
   case, TLS between the client and TURN server facilitates traversal.

I'm surprised you don't list integrity as a virtue here. If (for
instance) you're on a vulnerable local link like Wi-Fi, this might
be of significant value.

S 3.
      communicate between the client and the server .  The 5-tuple

/server ./server./

S 4.
   to STUN-formatted messages.  This means that all the message-forming
   and -processing descriptions in this document are implicitly prefixed
   with the rules of [I-D.ietf-behave-rfc3489bis].

s/-processing/message-processing/

   use the backwards-compatibility mechanism described in

s/backwards/backward/

S 6.2.
I'm always uncomfortable about requiring (or implying) that checks be done in
a certain order. why, for instance, can't #4 be before #3? I would recommend
treating this as an unordered list of the operations. In particular,
it's very natural to try to do some of the request rather than checking
everything up front, and then throw errors if the request fails.

The ordering of #5 and then the paragraph describing allocations 
implies a TOCTOU bug. The only way to know a port is available
at time of allocation is to actually allocate it.

S 6.3.
   prepared to deal with, then the client MUST delete the allocation
   (Section 7) and MUST NOT attempt to create another allocation on that
   server until it believes the mismatch has been fixed.

This might benefit from more clearly stating that this means
Allocate with lifetime=0.

S 8.
   For each allocation, the server keeps a list of zero or more
   permissions.  Each permission consists an IP address which uniquely

I would say "remote IP address" here.

I don't understand this bit about "default permission lifetime".
How can it be anything other than 5 minutes? If it can't be,
then it's not a default. Ity's just fixed.

      rate.  Applications using ICE should follow the keep-alive
s/should/SHOULD/?

S 9.3.
   that sent the UDP datagram (see ISection 10), then the server forms
s/ISection/Section/

S 11.1.
   If the client-server connection uses UDP, then the server SHOULD read
   the DSCP from the IP header of the received Data indication or

s/Data/Send/, right?

-Ekr

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