I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-behave-turn-12.txt
Reviewer: Brian Carpenter
Review Date: 2008-01-20
IETF LC End Date: 2009-01-27.
IESG Telechat date: (if known)

Summary: In good shape, a few issues raised.
--------

Comments:
---------

I don't normally post my Gen-ART reviews to the main IETF list, but will do so
in this case since there are some issues of principle mentioned below.
In general it is a well written and clear draft and I trust the WG consensus 
that the TURN protocol exchanges are technically sound. I have not reviewed
the protocol details in sections 6 through 16.

Major issues:
-------------

> 19.  IAB Considerations
>
>    The IAB has studied the problem of "Unilateral Self Address Fixing",

I don't know whether the IAB has considered this draft, but IMHO they 
should probably do so. It is extremely hard** to qualify TURN as a
short-term fix for a specific problem (IAB criterion #1) or to agree
that a realistic exit strategy is: "will no longer be needed once there 
are no longer any NATs" (IAB criterion #2). I'm not saying that TURN
shouldn't be standardised - obviously, we need a solution in this space,
and TURN is the one that has gathered consensus. But it's a bit hypocritical
to publish it without saying honestly that its lifetime is indefinite and
the first two IAB criteria cannot realistically be satisfied in this case.

** For example, the Introduction says:
>    TURN was originally invented to support multimedia sessions signaled
>    using SIP. 
>    ...However, care has been taken to
>    make sure that TURN is suitable for other types of applications.



> 2.6.  Other Features
...
>    Note that, because the
>    server does not relay ICMP messages, the client will have to use a
>    Path MTU discovery algorithm based on the one in [RFC4821].

This seems like a major point, not just a note. Doesn't it impose a rather
large and novel requirement on client implementations? Is it in fact a hidden
normative requirement for a TURN client?

> 17.1.5.  Impersonating a Server
...
>    This attack is prevented through the digest authentication mechanism,
>    which provides message integrity for responses in addition to
>    verifying that they came from the server.  

I'm no expert, but is this subject to the sort of vulnerability
discussed in RFC4169, if an attacker has observed previous traffic
and is capable of spoofing the server's IP address?

> 18.  IANA Considerations

I'm surprised there is no registry for the channel numbers, especially since:

> 0x8000 through 0xFFFF: These values are reserved for future use.


Minor issues:
-------------

> 1.  Introduction
...
>    The client does this by allocating an IP address and port on the
>    server, called the relayed-transport-address.

This reads rather strangely, as if the client was able to pick any
address and port that it likes, which is clearly impossible. (The
description in section 2.2 is fine.)
Maybe s/allocating/obtaining/

> 2.  Overview of Operation
...
>    The client learns the server's transport
>    address through some unspecified means (e.g., configuration), 

Other protocols involving relays, for example 6to4, have got into operational
trouble in this area, especially when using anycast addresses. While this
probably shouldn't be a topic for the base spec, I'd appreciate a pointer
to work on this topic, or at least a warning that it conceals serious operational
issues. (The TURN authentication and permissions mechanisms don't address this 
issue, since they apply after a client has decided which relay to use.)

> 2.1.  Transports
>
>    TURN as defined in this specification always uses UDP between the
>    server and the peer.  However, this specification allows the use of
>    any one of UDP, TCP, or TLS over TCP to carry the TURN messages

Is there a reason that SCTP is not mentioned? Of course SCTP has its own
issues with NATs, but it would be a useful clarification to say either
that it is definitely not supported or that it is left for future work.