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

From: [email-masked]
Date: Wed, 4 Mar 2009 11:45:02 -0800 (PST)

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-02.txt
	Pages           : 14
	Date            : 2009-03-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-02.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: Wed, 04 Mar 2009 14:55:12 -0500

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

Changelog:

- Defined the mechanisms in detail.

Open issues:

- Are the use cases compelling? (Will be discussed in SFO.)

- How to maintain the NAT bindings for the data connections. Some ideas:
  - TCP keep-alive
  - Application protocol must do it.

- Do we need a Connect request? ICE wouldn't use it. If we remove Connect, we
can also remove Listen because it would be implicit. That would save one round
trip. It would also work better with the rest of ICE, which only mentions
allocations.

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: Wed, 04 Mar 2009 12:38:28 -0800

> trip. It would also work better with the rest of ICE, which only mentions

One missing open issue is multiple connections vs shared connection
(ala SSH).  As far as I can read in the minutes of the Minneapolis
meeting and the subsequent discussions in the mailing-list, nothing
was decided.

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Mar 2009 13:57:48 -0800

> meeting and the subsequent discussions in the mailing-list, nothing

For everyone else's reference, here are pointers to the mailing list
discussion of your proposal, 
draft-petithuguenin-turn-tcp-variant-00.txt:

your announcement of the I-D:
http://www.ietf.org/mail-archive/web/behave/current/msg04938.html

Rémi Denis-Courmont's comments:
http://www.ietf.org/mail-archive/web/behave/current/msg04942.html

Simon Perreault's comments:
http://www.ietf.org/mail-archive/web/behave/current/msg04939.html

your followup:
http://www.ietf.org/mail-archive/web/behave/current/msg04952.html
where you wrote:

 >
 > Some of your arguments are absolutely true (HOLB), some are 
 > debatable, and the others I have to think about them.
 >
 > But there is also some advantages to the single connection 
 > solution, for example establishing a new peer TCP connection is 
 > faster.  Please also have a look to section 3.3.2 in the excellent 
 > draft-iab-ip-model-evolution.
 >

Please followup to Remi's comments in this thread.

-d

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 04 Mar 2009 14:24:50 -0800

> Please followup to Remi's comments in this thread.

Thanks.

I will answer the remaining points in Remi's comments and publish a
new version of the I-D before the deadline.

---

From: "Craig, Dave" <[email-masked]>
Date: Thu, 5 Mar 2009 09:50:53 -0800

>   - Application protocol must do it.

How about requiring a means for the application to query the 
keep-alive interval and then disabling TCP keep alive?  Applications 
running on energy-efficient devices can couple their keep alive 
messages with the required refresh.  When they need to conserve more 
energy they can scale back the refresh frequency at the risk of 
breaking and having to reestablish the connection.

Otherwise, applications scaling back their keep alive messages will 
not result in an energy consumption savings.  Their first hop link 
will periodically have to turn on to send the RFC 1122 TCP keep-alive 
or the keep-alive specified draft-ietf-mmusic-ice-19#section-10 when 
there is no data send.

Thanks,
	Dave

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2009 12:56:06 -0500

Craig, Dave wrote:
> keep-alive interval and then disabling TCP keep alive?

By asking the NAT device? If so, I fear this is out of scope for TURN-TCP.

By measuring it? I may be long (5 days by default on Linux) so measuring it will
also be long. Not practical.

Not sure we're on the same wavelength...

Simon

---

From: "Craig, Dave" <[email-masked]>
Date: Thu, 5 Mar 2009 10:05:41 -0800

> By asking the NAT device? If so, I fear this is out of scope for TURN-TCP.

Yes, that and measurement are not tractable solutions.  I was referring to querying the configured refresh interval inside the client.  That way there are not a lot of application-specific refresh intervals to configure when you find out that a particular NAT you traverse removes bindings quickly.

It also gives the application the control reduce traffic when needing to conserve energy.

	Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Thursday, March 05, 2009 9:56 AM
To: Craig, Dave
Cc: [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-02.txt

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 07 Mar 2009 19:45:45 -0800

> from ports obtained from the STUN server.

Some comments and questions:

- Section 4.3, 4th paragraph: "Once a Listen success response has
been received, further Connect or Listen requests for the same
allocation MUST NOT be sent."

If I understand correctly, an allocation can either receive multiple
connections from peers or (xor) initiate *one* connection to a peer.
 Is my understanding right?

- Section 4.4, 2nd paragraph: "If a success response is received,
the client will start receiving a ConnectionAttempt indication each
time a peer attemps a new connection to the allocated address."

This sentence seems to mean that multiple ConnectionAttempt
indications can be received, each one with a different
XOR-PEER-ADDRESS and CONNECTION-ID.  Does it mean that the client
can create a new TCP connection to the server and send a
ConnectionBind for each for them, effectively creating one data
connection for each peer connection?  I ask this because it seems
that only one data connection (see above) seems possible when
initiated from the client.  If it is the case, why the asymmetry?

- Section 4.6, 1st paragraph: "The client MUST refresh the
allocation corresponding to a data connection, using the Refresh
request as defined in [I-D.ietf-behave-turn], for as long as it
wants to keep the data connection alive."

The Refresh must be sent additionally on the data connection or only
the control connection?  If the Refresh is sent on the data
connection, so I suppose that the ConnectionBind request and
response should use the Lifetime attribute.  If the Refresh is sent
only sent on the control connection, then I think that this sentence
is redundant with section 4.2.

- Section 4.6, 2nd paragraph:

Here also why no subsequent connections can be established by the
client, but subsequent connections can be received?

- Section 5.1, 7th paragraph: "Until a Listen request for this
allocation is successfully processed, the server MUST deny any
connection attempts received on the relayed transport address."

Duplicated with section 5.4, 2nd paragraph.

- Section 5.2 and 5.3:

A Connect or Listen received on a data connection (i.e. after a
ConnectionBind) should be rejected.

- Section 5.2, 5th paragraph: "If the connection attempt fails or
times out, the server MUST return a XXX (Connection Timeout or
Failure) error."

The default TCP timeout is 180 seconds, but the STUN transaction
timeout is 39.5 seconds (See RFC 5489 Section 7.2.2 paragraph 5).
What happen to the stuck connection when the STUN transaction times out?

- Section 5.5:

What happen if a ConnectionBind is received for a peer data
connection closed after the 30 seconds timeout?

- Section 5.6, 1st paragraph: "If the allocation associated with a
data connection expires, the data connection MUST be closed."

If I understood correctly that there can be multiple connections
from a Listen, then "...the data connectionS MUST be closed."

- Section 5.6:

What happen if the peer connection is closed?

Nits:

Section 4.3, 2nd paragraph: "...request is recevied, if it is a
success, the TCP connection on which..."

recevied -> received

---

From: Simon Perreault <[email-masked]>
Date: Sun, 08 Mar 2009 10:13:33 -0400

>  Is my understanding right?

Right.

> initiated from the client.  If it is the case, why the asymmetry?

Above restricts the number of client data connections for a Connect 
request to one. For Listen requests, one client data connection per peer 
is still possible.

> is redundant with section 4.2.

Only on the control connection. No STUN messages are sent after the 
initial ConnectionBind request/response exchange on the data connection.

The additional, non-redundant information is that you cannot keep a data 
connection open if you let the allocation expire.

> client, but subsequent connections can be received?

This is restricted by the BSD sockets API. Once it has connect()'ed, a 
socket cannot be deconnected and reconnected elsewhere. It also cannot 
start listen()'ing. It's good for nothing and must be closed.

The situation is a bit different for sockets once they have listen()'ed. 
They can receive any number of connections. But they cannot be used for 
connect()'ing anymore.

> Duplicated with section 5.4, 2nd paragraph.

I'll remove the 7th paragraph in section 5.1.

> ConnectionBind) should be rejected.

This would be contrary to section 5.5, 6th paragraph:

    Data received on a client or peer data connection MUST NOT be
    interpreted as a STUN message.

Instead of being rejected, they should be forwarded to the peer as-is.

> What happen to the stuck connection when the STUN transaction times out?

The 39.5 seconds timeout only applies to the initial TCP connection 
establishment. It does not apply when waiting for STUN responses.

    However, for a request/response transaction, if the client has not
    received a response by Ti seconds after it sent the SYN to establish
    the connection, it considers the transaction to have timed out.  Ti
    SHOULD be configurable and SHOULD have a default of 39.5s.

> connection closed after the 30 seconds timeout?

An error must be returned. This will be added to the next revision.

> from a Listen, then "...the data connectionS MUST be closed."

Right.

> What happen if the peer connection is closed?

Well, I intended the second paragraph to apply to the client and peer 
cases by clever usage of the "resp." construct. I shouldn't try to be 
clever. I'll split the paragraph in two in the next revision.

Many thanks for this review!

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 08 Mar 2009 09:27:02 -0700

> Marc Petit-Huguenin wrote:

[...]

> connection open if you let the allocation expire.

Hmm, I do not read this in 4.6 but anyway, the client does not know
that an allocation expired - or at least not until the next Refresh
fails, so it cannot close the data connection immediately.  On the
other hand if the allocation expires the data connections are closed
by the server (5.6 paragraph 1) so that would be unnecessary.

Also that there should be some text explaining what happen if the
client closes the control connection (i.e. same than allocation expires)

> They can receive any number of connections. But they cannot be used for

It it possible to create multiple sockets with SO_REUSEADDR that are
all bound to the same IP address and port.  The TURN TCP protocol
can hide this and simply allow multiple incoming or outgoing
connections, simultaneously or sequentially.

---

From: Simon Perreault <[email-masked]>
Date: Sun, 08 Mar 2009 16:33:30 -0400

> connections, simultaneously or sequentially.

Indeed. Hmmm... This means we could do away with the Listen request 
completely. Unless somebody objects, I'll remove the Listen request in 
the next revision, as well as all restrictions related to the above.

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 09 Mar 2009 11:58:37 -0700

> Please followup to Remi's comments in this thread.

I submitted a new version of the turn-tcp-variant draft:

http://www.ietf.org/internet-drafts/draft-petithuguenin-turn-tcp-variant-01.txt

I put Remi's arguments inside the document as reasons not to adopt
this variant in TURN TCP.  I also added arguments in favors of
adopting it :-)

Comments are welcome.

Thanks.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Mar 2009 16:13:03 -0400

I support that change.

Couple of other comments:

* ICE-tcp has the concept of active relayed candidates. For those, the 
client needs to have the TURN server initiate a TCP connection, but use 
a *different* port on the same IP address. There needs to be some way to 
do that here. I'm wondering if one idea is to allow clients to initiate 
a Connect request without having previously done an Allocate.

* THe current text requires the TURN server to accept incoming 
connections and THEN inform the client of this. However, the client 
might refuse it, or timeout. I think it would be better to have the TURN 
server inform the client, and only once the client sends a 
ConnectionBind, THEN the TURN server accepts the connection.

* As with UDP TURN, there needs to be keepalives on the allocation and 
on the data connection. The data connection, out of necessity, is 
refreshed by data, whereas the allocation is refreshed by a new Allocate

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Mar 2009 16:42:51 -0400

> a Connect request without having previously done an Allocate.

Can you explain the purpose of active relayed candidates? I searched in the
archives but couldn't find anything.

> ConnectionBind, THEN the TURN server accepts the connection.

This would be ideal, however using the BSD sockets API there is no way to check
permissions before accepting the connection, because we don't know the address
of the peer yet. We could have the server only check permissions after the
client has accepted the connection, but I think this would be even dirtier than
what we have now.

> refreshed by data, whereas the allocation is refreshed by a new Allocate

Absolutely. The question is how? Right now it is specified that the TURN server
never interprets data on a data connection, it just forwards it as-is. So we
cannot have a "no-op" at the TURN level, only at the application protocol level.

We could use TCP keepalives but there are the usual implementation problems.

Or we could break the "do not interpret data" rule, introduce a special "no-op",
and introduce escaping rules for ordinary data that matches the "no-op" pattern.

Then there's the lazy alternative where we specify that any application protocol
related through TURN-TCP must do its own keepalive.

Any ideas? Suggestions?

Thanks,
Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 12 Mar 2009 10:50:12 -0700

> this variant in TURN TCP.  I also added arguments in favors of

The Kindle version:

http://ietf.implementers.org/draft-petithuguenin-turn-tcp-variant-01.mobi