Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-03.txt

From: [email-masked]
Date: Mon, 4 May 2009 06:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
	Author(s)       : S. Perreault, J. Rosenberg
	Filename        : draft-ietf-behave-turn-tcp-03.txt
	Pages           : 13
	Date            : 2009-05-04

This specification defines an extension of Traversal Using Relays
around NAT (TURN), a relay protocol for NAT traversal, to allows a
TURN client to request TCP allocations, and defines new requests and
indications for the TURN server to open and accept TCP connections
with the client's peers.  TURN and this extension both purposefully
restrict the ways in which the relayed address can be used.  In
particular, it prevents users from running general purpose servers
from ports obtained from the STUN server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-tcp-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 May 2009 09:52:16 -0400

> 	Filename        : draft-ietf-behave-turn-tcp-03.txt

Here's the change log:

- Removed Listen and Connect limits.
- Removed the Listen method since an allocation now listens by default.
- Added a note to the effect that TURN-TCP does not keep data connections alive.
- Added a small Security Considerations section (adapted from TURN-IPv6).
- Updated references.
- Picked numbers for attributes and responses.

The diff is here:
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-behave-turn-tcp-03.txt

All outstanding issues have been fixed.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 04 May 2009 09:08:09 -0700

Some comments and nits on turn-tcp-03:

- Section 4.1, 4th paragraph: "are identical to those for TCP.":

s/TCP/UDP/

- Section 4.3:

There is nothing in the text about the authentication of the data
connection.  The data connection should be authenticated with the
same username that was used for authenticating the control connection.

- Section 4.3, 4th paragraph: "...and the response code was XXX...":

s/XXX/447/

- Section 5.2, 2nd paragraph: "If the request is received on a
control connection for which no allocation exists...":

According to section 4.1, 5th paragraph, a TCP connection is called
a control connection only after a success response for an allocation
is received, so it is not possible to have a control connection for
which no allocation exists.

- Section 5.2, 5th paragraph: "If the connection attempts fails or
times out, the server MUST return a XXX...":

s/XXX/447/

- Section 5.2, 7th paragraph:

I think that there should be some text advising against using the
file descriptor from a Posix system directly in the CONNECTION-ID
attribute, as they would be easily guessable.

- Section 6.1:

The method codepoints are already allocated to TURN UDP (Data,
CreatePermission and ChannelBind).  That make it impossible to write
an interoperable implementation of this draft.

Nits:

- Section 2, 3rd paragraph: "It then returns the allocated port to
the client in the resposne...":

s/resposne/response/

- Section 4.3, 2nd paragraph: "When a response to the ConnectionBind
request is recevied...":

s/recevied/received/

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 May 2009 12:25:36 -0400

> - Section 4.1, 4th paragraph: "are identical to those for TCP.":

Thanks, fixed.

> same username that was used for authenticating the control connection.

Right. How about the following text:

"Authentication of the client by the server MUST use the same method and
credentials as for the control connection."

I also added it to section 4.4.

> - Section 4.3, 4th paragraph: "...and the response code was XXX...":

Thanks, fixed.

> which no allocation exists.

Right. In this case I think it's better to be explicit so I'll s/control
connection/TCP connection/.

> times out, the server MUST return a XXX...":

Thanks, fixed.

> attribute, as they would be easily guessable.

Why is this a problem if we're authenticating the data connection?

> an interoperable implementation of this draft.

Too much copy-paste... I replaced that with 0xA, B, C. Ok?

> Nits:

Thanks, fixed.

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 04 May 2009 09:46:46 -0700

> Marc Petit-Huguenin wrote, on 04/05/09 12:08 PM:
[...]
> I also added it to section 4.4.

OK.

[...]
> Why is this a problem if we're authenticating the data connection?

If the data connection is authenticated then there is no problem
(but IANASE - I am not a security expert).

I put this in here because it was not clear yet that the data
connection was to be authenticated.

> Too much copy-paste... I replaced that with 0xA, B, C. Ok?

AFAIK, they are not allocated yet.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 May 2009 17:25:46 -0600

One of the important design principals of TURN was that it could not  
be used to run a general server and you needed to know who the IP/port  
of who was going to connect to you before a turn server could form a  
connection to them. It seems like the  changes to remove Listen  
removed this property - am I mis reading this? I would not want to  
loose this property.

On May 4, 2009, at 7:52 AM, Simon Perreault wrote:

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 20 May 2009 09:15:33 +0900

Cullen Jennings wrote:
> One of the important design principals of TURN was that it could not be
> used to run a general server and you needed to know who the IP/port of
> who was going to connect to you before a turn server could form a
> connection to them. It seems like the  changes to remove Listen removed
> this property - am I mis reading this? I would not want to loose this
> property.

Cullen,

Thanks for your comments.

This important property is still present. What the server does is accept
(in the TCP sense) any incoming connection on the relayed address.

One the connection is accepted, the server checks the TURN permissions
and then either drops the connection or relays it to the client. So the
client still has to install a TURN permission to receive anything from a
peer.

This is necessary because TURN servers implemented using the BSD API
cannot know the address of the peer, and hence check permissions, until
they accept() the connection.

Thanks,
Simon

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 May 2009 18:46:35 -0600

On May 19, 2009, at 6:15 PM, Simon Perreault wrote:

> removed

Thanks for the explination. Works for me.