Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
draft-ietf-behave-turn-tcp-07

[Ballot comment]
The TCP connection used for control is sometimes called "control
connection" and sometimes "control channel".  It would help
readability to use one name consistently.

For consistency with text in section 4.1 and readability, I suggest
changing this text in section 3:

OLD:

  To obtain a TCP-based allocation, a client must have a TCP or TLS
  connection to its TURN server.  Using that connection, it sends an
  Allocate request.

NEW:

  To obtain a TCP-based allocation, a client first opens a TCP or TLS
  connection to its TURN server.  The client then sends an Allocate
  request over that control connection.

In the following paragraph in section 3, s/address/port/ ??

  If a client wishes to establish a TCP connection to a peer from that
  allocated address, it issues a Connect request to the TURN server
  over the control connection.

At the end of section 3:

  The TURN server will relay the data between the client and peer data
  connections, utilizing an internal buffer.  However, back pressure is
  used in order to achieve end-to-end flow control.  If the buffer from
  client to peer fills up, the TURN server ceases to read off the
  client data connection, which causes TCP backpressure through the OS
  towards the client.

This text describes an implementation detail, in my opinion.  I can
imagine an implementation that simply copies directly between the two
data connections as data is available on each.  I suppose you could
argue that the implementation uses a small, one segment buffer.  In
any event, adding another buffer to the send and receive buffers in
the TCBs for the two data connections may affect scalability.

From section 4.3 (also in section 4.4):

  Once
  established, the client MUST send a ConnectionBind request.

I assume the ConnectionBind request is sent over the newly established
TCP connection (which will become the data connection).  In my
opinion, the connection to be used should be clarified here.

In section 5.5:

  When a client data connection is closed or times out, the server MUST
  close the corresponding peer data connection.

what does "times out" mean?

[Ballot discuss]
Updated 2010-07-01 after e-mail exchange with authors.

From section 3:

  Once established, it issues a ConnectionBind
  request to the server.

Is this message sent over the control connection or the data connection?


In section 5, the term "relayed transport" is used without
definition:

  4.  A TCP relayed transport address

Is just an address allocated or is it an address/port pair?  The
question is important, I think, in this text:

5.3.  Receiving a TCP Connection on an Allocated Port

  When a server receives an incoming TCP connection on a relayed
  transport, it processes as follows.

because, if I'm understanding the specification correctly, the client
has a specific allocated address/port pair to which inbound connection
requests from peers are made.

(added 2010-07-01) The document uses the phrases "IP address and port", "address" and "relayed transport address".  I think - although I'm not sure - that the phrases are interchangeable in at least some cases.  For clarity,it would be good to define "relayed transport address" early on (as discussed in e-mail) and use that term wherever applicable.

[Ballot comment]
I stubmled a bit over "TCP allocation".
I think this is shorthand for "TURN allocation for a TCP session".
If I'm right, it is probably worth dropping this into the Introduction so that it is clear. If I am wrong, there is even more need to add an explanation.

[Ballot comment]
Nits
----

Abstract

    around NAT (TURN), a relay protocol for NAT traversal, to allow a

Expand NAT.


3. Overview of Operation

    client to peer fills up, the TURN server ceases to read off the
    client data connection, which causes TCP backpressure through the OS
    towards the client.

Expand OS.


4.3. Initiating a Connection


    If the result of the Connect request was a Error Response, and the
    response code was 447,

It would be good to add the name of the code as in the other cases.


Sections "Security Considerations" (6.4) and "Acknowledgements" (6.5)
are subsections of "IANA Considerations". This is probably unintentional.

[Ballot discuss]
From a review by Ari Keränen:

Section 5.1 says:

  1.  If the REQUESTED-TRANSPORT attribute is included and specifies a
      protocol other than UDP or TCP, the server MUST reject the
      request with a 442 (Unsupported Transport Protocol) error.  (If
      the value is UDP, the server MUST continue with the procedures of
      [I-D.ietf-behave-turn] instead of this document.)

What if the server has an TCP-only policy? It seems that the last
sentence forbids such a policy, as it is required that the UDP process
continues from this point onwards.

In section 5.2:

    Otherwise, and if the new connection is permitted by local policy,
    the server MUST initiate an outgoing TCP connection.

What to do if the connection is not permitted by local policy? Perhaps
send back 403 (Forbidden) error? The draft explains the error treatment
for all the other error cases, but not this.

    The server MUST buffer any data received from the
    client.  Data MUST NOT be lost unless the buffer exceeds a limit
    defined by local policy, in which case the data connection MUST be
    closed.  The server adjusts its advertised TCP receive window to
    reflect the amount of empty buffer space.

If the connection MUST be close before the receiving buffer is full, the
advertised window would never reach zero, right? Wouldn't this break something, like a well-intentioned client sending TCP traffic according
to the advertised window sizes?

[Ballot comment]
The TCP connection used for control is sometimes called "control
connection" and sometimes "control channel".  It would help
readability to use one name consistently.

For consistency with text in section 4.1 and readability, I suggest
changing this text in section 3:

OLD:

  To obtain a TCP-based allocation, a client must have a TCP or TLS
  connection to its TURN server.  Using that connection, it sends an
  Allocate request.

NEW:

  To obtain a TCP-based allocation, a client first opens a TCP or TLS
  connection to its TURN server.  The client then sends an Allocate
  request over that control connection.

In the following paragraph in section 3, s/address/port/ ??

  If a client wishes to establish a TCP connection to a peer from that
  allocated address, it issues a Connect request to the TURN server
  over the control connection.

At the end of section 3:

  The TURN server will relay the data between the client and peer data
  connections, utilizing an internal buffer.  However, back pressure is
  used in order to achieve end-to-end flow control.  If the buffer from
  client to peer fills up, the TURN server ceases to read off the
  client data connection, which causes TCP backpressure through the OS
  towards the client.

This text describes an implementation detail, in my opinion.  I can
imagine an implementation that simply copies directly between the two
data connections as data is available on each.  I suppose you could
argue that the implementation uses a small, one segment buffer.  In
any event, adding another buffer to the send and receive buffers in
the TCBs for the two data connections may affect scalability.

From section 4.3 (also in section 4.4):

  Once
  established, the client MUST send a ConnectionBind request.

I assume the ConnectionBind request is sent over the newly established
TCP connection (which will become the data connection).  In my
opinion, the connection to be used should be clarified here.

In section 5.5:

  When a client data connection is closed or times out, the server MUST
  close the corresponding peer data connection.

what does "times out" mean?

[Ballot discuss]
What happens in the case of simultaneous client- and peer-initiated
connection opens through an allocated port?  Of course, one or the
other event will be received by the TURN server first (hm, suppose the
TURN server implementation is multi-threaded?); I think there should
be some words to the effect of "As soon as the TURN server receives a
connection request from the client, all inbound requests to the
allocated port from other peers are rejected; similarly, as soon as
the TURN server receives a connection request from a peer, all other
requests from peers to the allocated port are rejected.  If the TURN
server has received a connection request to the allocated port from a
peer, a connection request from the client is rejected and the TURN
server responds on the control connection with ."

From section 3:

  Once established, it issues a ConnectionBind
  request to the server.

Is this message sent over the control connection or the data connection?

From section 4.1:

  As with any other request, multiple Connect requests MAY be sent
  simultaneously.  However, Connect requests with the same XOR-PEER-
  ADDRESS parameter MUST NOT be sent simultaneously.

Does this text imply that multiple Connect requests can be sent over a
single control connection?  I find this a little confusing because my
understanding is that each control connection is associated with a
single data conncetion.  What are the semantics?  First connection
wins?  Are the others explicitly rejected or silently dropped?

In section 5, the term "relayed transport" is used without
definition:

  4.  A TCP relayed transport address

Is just an address allocated or is it an address/port pair?  The
question is important, I think, in this text:

5.3.  Receiving a TCP Connection on an Allocated Port

  When a server receives an incoming TCP connection on a relayed
  transport, it processes as follows.

because, if I'm understanding the specification correctly, the client
has a specific allocated address/port pair to which inbound connection
requests from peers are made.

[Ballot comment]
I found the restriction on only having a single outgoing TCP connection to a particular address/port combination to be a bit too restrictive. Although I suspect why you've done that. However some discussion of the topic in the document would have been helpful.

IANA questions/comments:

QUESTION: section 6.3 requests "New STUN response codes" assignments.
No such registry exists. Please confirm that the "STUN Error Codes"
registry is the intended registry.

ACTION 1:

make the following assignment in the "STUN Methods" registry at
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml

Value Name Reference
------ ----------------- -------------------
0x000A Connect [RFC-behave-turn-tcp-06]
0x000B ConnectionBind [RFC-behave-turn-tcp-06]
0x000C ConnectionAttempt [RFC-behave-turn-tcp-06]


ACTION 2:

make the following assignment in the "STUN Attributes" registry at
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml

Value Name Reference
------ ------------- --------------
0x002A CONNECTION-ID [RFC-behave-turn-tcp-06]


ACTION 3:

make the following assignments in the "STUN Error Codes" registry at
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml

Value Name Reference
----- ----------------------------- --------------
446 Connection Already Exists [RFC-behave-turn-tcp-06]
447 Connection Timeout or Failure [RFC-behave-turn-tcp-06]

  (1.a)  Who is the Document Shepherd for this document?

draft-ietf-behave-turn-tcp-05
Dan Wing, dwing@cisco.com

          Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Yes.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document has received significant review from the community.


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No concerns.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.

No concerns.


          Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

None.


  (1.e)  How solid is the WG consensus behind this document?

Very solid.

          Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The WG has a good understanding of, and agreement with, this document.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No such threats or appeals.


  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)


Yes.

          Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews? 

The document does not specify a MIB, media type, or URI, and thus
does not need to meet those review criteria.

          If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Intended Status:  Standards Track


  (1.h)  Has the document split its references into normative and
          informative?

Yes.

          Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

All normative references are upward references, and all are RFCs.


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?

Yes.

          If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?

Yes.

          Are the IANA registries clearly identified?

Yes.

          If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?

The document does not create a new IANA registry.

          Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The document contains no such formal language.


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.


This specification defines a protocol that allows the host to control the
operation of a relay and to exchange packets with its peers using
the relay.  TURN differs from some other relay control protocols in
that it allows a client to communicate with multiple peers using a
single relay address.

The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal,
though it can be also used without ICE.



          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?


No.

          Document Quality
            Are there existing implementations of the protocol?

Yes.

            Have a
            significant number of vendors indicated their plan to
            implement the specification?

Yes.

            Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?

They are listed in the document's acknowledgement section


            If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

No such reviews were necessary.


          Personnel
            Who is the Document Shepherd for this document?

Dan Wing, dwing@cisco.com

            Who is the
            Responsible Area Director?

Magnus Westerlund, magnus.westerlund@ericsson.com


            If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'


The document doesn't require IANA experts.



  The Document Shepherd MUST send the Document Shepherd Write-Up to the
  Responsible Area Director and iesg-secretary@ietf.org together with
  the request to publish the document.  The Document Shepherd SHOULD
  also send the entire Document Shepherd Write-Up to the working group
  mailing list.  If the Document Shepherd feels that information which
  may prove to be sensitive, may lead to possible appeals, or is
  personal needs to be written up, it SHOULD be sent in direct email to
  the Responsible Area Director, because the Document Shepherd Write-Up
  is published openly in the ID Tracker.  Question (1.f) of the
  Write-Up covers any material of this nature and specifies this more
  confidential handling.