Comments on TURN from the BEHAVE mailing list.
Compiled by Dan Wing and e-mail out on 11 September 2007.
link
* To: behave at ietf.org
* Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-04.txt
* From: Marc Petit-Huguenin
* Date: Tue, 17 Jul 2007 10:06:15 -0700
* In-reply-to:
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References:
* User-agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070621)
Some comments on this draft:
1. Section 5: "Note that the first octet is always distinguishable from
an unframed STUN request or response (which is always 0x00 or 0x01)."
This is true only if the method is > 0x03F. STUN-07 is section 17.1
explicitly says that methods can be in the range 0x000 to 0x3FF.
[PM] FIXED. The text is gone in -05 (since all messages are framed).
2. Section 6.1.1.1: The reference to the Shared Secret request should be
removed as it was removed in STUN-07. Same thing in section 6.1.1.2.
[PM] FIXED. There is no longer any reference to the Shared Secret request.
However, the document does use the term "shared secret" (meaning username and password)
which it doesn't define.
3. Section 7: CONNECT_STAT should be CONNECT-STAT. Same thing in
sections 7.9 and 13.2.
[PM] FIXED. This attribute was used for TCP allocations.
I have not checked TURN-TCP.
4. Section 7.4: "It is padded with zeros if its length is not divisible
evenly by 4 octets." STUN-7 now says (section 14) that "[t]he padding
bits are ignored, and may be any value."
[PM] FIXED. I replaced the sentence with
"The attribute is padded as necessary to a multiple of 4 bytes."
5. Section 7.6: The names for the bit set in the fourth paragraph (Event
Port is a request...) do not match the list in the third paragraph.
[PM] FIXED. I rewrote this entire section in an attempt to make things clearer.
Nits:
1. Section 6.1.1.2: s/explict/explicit/
2. Section 10.1.2: s/REMOTE_ADDRESS/REMOTE-ADDRESS/
3. Section 12: s/Allcoate/Allocate/
[PM] ALL FIXED.
http://www1.ietf.org/mail-archive/web/behave/current/msg02627.html
* To: behave at ietf.org
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rémi Denis-Courmont
* Date: Tue, 31 Jul 2007 12:16:18 +0300
* Cc: 'Rohan Mahy' , ext Dan Wing
* In-reply-to: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* Organization: Nokia TP-SP-SWD
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com>
* User-agent: KMail/1.9.6
Hey,
Rohan pointed out that congestion handling when there are multiple TCP
sessions to remote peers was an open issue.
As far as I can tell, there is NO WAY to solve this, so long as we use a
single TCP session between the client and the TURN server. It is inherent to
how TCP works, and is the exact same issue that MSRP relays have. Regardless
whether that breaks forking, I really think we simply cannot do that
properly.
Take this scenario:
TURN client <-- TCP_C --> TURN server <-- TCP_A --> Peer A
<-- TCP_B --> Peer B
Now consider that TCP_B session gets congested. At some point, TURN server
output buffer for TCP_B gets full. Now so long as the client only sends data
to peer A, every thing is fine. But if the client sends data to peer B, the
TURN server gets stuck.
At this point, the server really can only do one of three things:
(1) queue an indefinitely big amount of data,
(2) stop dequeing data from the TURN client until TCP_B gets "decongested",
(3) drop data for B, and reset/timeout connection with B.
(1) is basically what MSRP does. Im my humble opinion, it is utterly broken;
and I think we agreed this was not the way to go.
(2) is flawed, as communication between client and peer A will be unduly
disrupted. It is an obvious security issue if A and B do not trust each
others. Even then, it is probably unacceptable: if say, B looses connectivity
for some reason, the flow to A will be totally disrupted until TCP_B
connection times out. There are similar problem if connectivity to B is much
slower or less reliable than that to A.
(3) has similar problems, though mirrored. Say we have a forked MSRP file
transfer from client to peers. If the client knew the "bandwidth quotient"
between A and B, it could send data to each at appropriate speed. But it does
not, so the connection to B will fail, and only A will receive the file.
This is all the same problem as with MSRP: one cannot multiplex multiple TCP
sessions on a single TCP session, not directly. I am not an IETF congestion
control expert, but it all comes down to the need for the TURN client to
maintain separate congestion control for each peers.
And then, there is the separate issue of how do we not turn this multiple
connections "feature" into an open port service, which would allow running
servers from behind a TURN relay.
--
Rémi Denis-Courmont
[PM] This is about the TURN-TCP issue.
http://www1.ietf.org/mail-archive/web/behave/current/msg02634.html
* To: Rémi Denis-Courmont
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: "Alfred E. Heggestad"
* Date: Tue, 31 Jul 2007 21:17:05 +0200
* Cc: 'Rohan Mahy' , behave at ietf.org, ext Dan Wing
* In-reply-to: <200707311216.18858.remi.denis-courmont@nokia.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com>
* User-agent: Icedove 1.5.0.12 (X11/20070606)
Hi
I would agree with Rémi, that multiple peers per TURN client is a complex
scenario and I think the use-case for this must be reviewed.
The "Connection Status Indication" and the CONNECT_STAT attribute can only
indicate status of one (1) connection, and there is no way of mapping which
connection is indicated. This means that TCP connections can only be setup
one at a time.
I do not see a real use-case for multiple TCP/UDP peers per TURN client,
so my apologies if there are already many good use-cases for this, but I
think that TURN can be made much simpler if we only allow one peer per
TURN client. If a User-Agent wants two "channels", he can just start
two different TURN clients on the same host, but listening on different
ports.
/alfred
http://www1.ietf.org/mail-archive/web/behave/current/msg02636.html
* To: "Alfred E. Heggestad"
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: "Evgeniy Khramtsov"
* Date: Wed, 1 Aug 2007 08:51:27 +1000
* Cc: Rohan Mahy , ext Dan Wing , behave at ietf.org
* Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=S9SQxSH1j0usN6Lt5lEC5+25d2KNCjxk+Y5u8M+Ek8qPnMTkchPPOcReotvrDtqT+eRNwenIBcQyH5URHcraXFQlrElSEGbrj31aqjKAQSgMysUQ9B7PWW+qnjw5Z/n+kl3HzuuswXaPat77B2YZHBGOJgRtet0PB/WGlX1LYXk=
* Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lv7KOlM6IF199jisTLYsae7lr+khnTanC8XVQsBNYgisXeo01xSk270iRIxWxb8XyUJn0cmEvDCaUHggdzhyjpwsfY1txzzd1C0hp5CrvDyAgAUCTtqS7uDxwD+W6Q4UY+PNYJvOUdfULe0FKcIsm3wS4aC27LT/mniBCE/FzZ0=
* In-reply-to: <46AF8AB1.5090401@db.org>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> <46AF8AB1.5090401@db.org>
2007/8/1, Alfred E. Heggestad :
I do not see a real use-case for multiple TCP/UDP peers per TURN client,
so my apologies if there are already many good use-cases for this, but I
think that TURN can be made much simpler if we only allow one peer per
TURN client. If a User-Agent wants two "channels", he can just start
two different TURN clients on the same host, but listening on different
ports.
Completely agree with you.
http://www1.ietf.org/mail-archive/web/behave/current/msg02642.html
* To: "Rémi Denis-Courmont"
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: "Bruce Lowekamp"
* Date: Wed, 1 Aug 2007 16:18:13 -0400
* Cc: Rohan Mahy , behave at ietf.org, ext Dan Wing
* Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Ys7TlKxT3TL+ieV8AgchA4p3H6hLDzCp+saSepsZfCDZpGCAMUGxBCKAwdDckbwqlZ/2L7CgivlAioYIoMqEIuA4gnHtbMFngxkZP/+k3AmTiE/B7hQNG8xolrqPR5E/ZDBYX4PmGP7HkGn0Utuci5URLkj5tsVT1t+X3fa8S4k=
* Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=O34DH4wWbt3Odla4QNdQi9DgoREW87o5jAqftsi+bdRYphGctTP0Ovo9VxJ5dJ5ZxjzERolDRYSaJl5uIxdjPDjoIZVR13aYqA9WoCM8F9uv0gj3k6ldlcjKPCkPar1DktxsQYROnZBGiDbknP83NI/SNT41OfF4HmajQgaU+jQ=
* In-reply-to: <200707311216.18858.remi.denis-courmont@nokia.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com>
On 7/31/07, Rémi Denis-Courmont wrote:
> At this point, the server really can only do one of three things:
> (1) queue an indefinitely big amount of data,
> (2) stop dequeing data from the TURN client until TCP_B gets "decongested",
> (3) drop data for B, and reset/timeout connection with B.
> (2) is flawed, as communication between client and peer A will be unduly
> disrupted. It is an obvious security issue if A and B do not trust each
> others. Even then, it is probably unacceptable: if say, B looses connectivity
> for some reason, the flow to A will be totally disrupted until TCP_B
> connection times out. There are similar problem if connectivity to B is much
> slower or less reliable than that to A.
I think that 2 is the only possible "correct" behavior, because 1 is
unimplementable and 3 breaks the basic TCP model merely because one
destination has lower throughput than another. 2's problem is that it
restricts both connections to the poorer of the pair (whether
deliberate attack or poor provisioning), but at least they both behave
like valid TCP connections.
There's another possibility of making the protocol more complex by
signalling queueing on the client connection, but I really don't think
we want that.
But unless there's a compelling reason to support it, I think it would
be better if TURN just says one peer per client connection. I'm not
aware of a compelling reason. If there is a compelling reason to
support it, I think big red flags and possibly even SHOULD NOT
language should be used to discourage its use except when necessary.
Bruce
http://www1.ietf.org/mail-archive/web/behave/current/msg02647.html
* To: ,
* Subject: RE: [BEHAVE] TURN: technical review by September 1
* From:
* Date: Mon, 6 Aug 2007 12:32:06 +0300
* Cc: rohan at ekabal.com
* In-reply-to: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com>
* Thread-index: AcfSzskf9wxeXRhnSA2cSHWPBMz2GwFO6wrg
* Thread-topic: [BEHAVE] TURN: technical review by September 1
>-----Original Message-----
>From: ext Dan Wing [mailto:dwing at cisco.com]
>Sent: 30 July, 2007 20:27
>To: behave at ietf.org
>Cc: 'Rohan Mahy'; huitema at microsoft.com
>Subject: [BEHAVE] TURN: technical review by September 1
>
>In Chicago at IETF-69 we explained the urgency around
>rfc3489bis ("STUNbis") and TURN. ICE needs to be published at
>the same time as rfc3489bis and TURN because ICE normatively
>references those documents. Rfc3489bis underwent substantial
>revision between -06 and -08, and I just WGLC'd rfc3489bis-08
>a few minutes ago. However, TURN is not yet ready to be WGLC'd.
Frankly, I do not understand why ICE normatively depends on TURN.
I could use SOCKS, UPnP, NAT-PMP, you-name-it... to generate
my candidates, yet ICE does not depend on these.
Of course, STUNbis is a dependency due to embracing and extending
the STUN messages format. But TURN... ??? In fact, while I understand
it might be late to "fix" this, I do not understand why ICE
specifically mention TURN all over the place in the details, while it
mentions tons of other potential non-normative ways to obtain
candidates in its introduction, but this is a minor almost-editorial
issue. So why is TURN not an informative reference?
However... I am sorry to say that, but I think it would be wrong to
Declare TURN "ready" before we´ve had the chance to examine its
Interactions with ICE-TCP, and that´s not something I can put within
5 weeks (counting from the end of last IETF). I mean, ICE-TCP is no
easy task in itself, and it would clearly be a pita when TURN turns
out to work fine with UDP and be broken with TCP (I would really like
we do not reproduce the mistakes from MSRP this time).
An alternative is to split TURN into UDP/UDP, first and the other
combinations separately, but I would not like this at all if I were
one of the editor. That´s what´s been done with ICE though, and I
expect that´s what implementors do - Does anyone know of a ICE-TCP
stack out yet at all?
Regards,
--
Rémi Denis-Courmont
Software Engineer
Nokia TP/SP, Helsinki
http://www1.ietf.org/mail-archive/web/behave/current/msg02648.html
* To:
* Subject: RE: [BEHAVE] TURN: technical review by September 1
* From:
* Date: Mon, 6 Aug 2007 12:54:18 +0300
* Cc: rohan at ekabal.com, behave at ietf.org, dwing at cisco.com
* In-reply-to: <20d2bdfb0708011318t1b9d543ct59e3fbca27a31607@mail.gmail.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> <20d2bdfb0708011318t1b9d543ct59e3fbca27a31607@mail.gmail.com>
* Thread-index: AcfUeSIpMf4IkIyARjS/WDApK4TnuwDkKy2w
* Thread-topic: [BEHAVE] TURN: technical review by September 1
>-----Original Message-----
>From: lowekamp at gmail.com [mailto:lowekamp at gmail.com]
>
>> (2) stop dequeing data from the TURN client until TCP_B gets
>> "decongested",
>> (3) drop data for B, and reset/timeout connection with B.
>
>> (2) is flawed, as communication between client and peer A will be
>> unduly disrupted. It is an obvious security issue if A and B do not
>> trust each others. Even then, it is probably unacceptable: if say, B
>> looses connectivity for some reason, the flow to A will be totally
>> disrupted until TCP_B connection times out. There are
>> similar problem if connectivity to B is much slower or less reliable
>> than that to A.
>I think that 2 is the only possible "correct" behavior,
>because 1 is unimplementable and 3 breaks the basic TCP model
>merely because one destination has lower throughput than
>another. 2's problem is that it restricts both connections to
>the poorer of the pair (whether deliberate attack or poor
>provisioning), but at least they both behave like valid TCP
>connections.
(2) is hardly more correct than (3). B could bring its TCP window
to zero for as long as the TCP timeout, then accept a few bytes,
and go back to zero, and so on...
And then, there´s the issue that it allows a single TURN client to
exhaust the server resources more easily.
>There's another possibility of making the protocol more
>complex by signalling queueing on the client connection, but I
>really don't think we want that.
Agreed. That would be the proper solution, but that would also
be overly complicated. At the end, we´d redefine conveying datagrams
on top of TCP, so you can do TCP over TCP :-(
>But unless there's a compelling reason to support it, I think
>it would be better if TURN just says one peer per client
>connection. I'm not aware of a compelling reason. If there
>is a compelling reason to support it, I think big red flags
>and possibly even SHOULD NOT language should be used to
>discourage its use except when necessary.
Personnaly, I tend to agree with Alfred and Evgeniy:
Multiple simultaneously-active connections should not be supported
at all. In fact, the send&data indications format is not quite
Suited for connection-oriented transports.
By the way, does ICE-TCP requires the TURN server to accept
multiple connections? If so, how does this fit with the requirements
to only allow one connection in order not to "bypass security"?
--
Rémi Denis-Courmont
Software Engineer
Nokia TP/SP, Helsinki
http://www1.ietf.org/mail-archive/web/behave/current/msg02649.html
* To:
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rohan Mahy
* Date: Mon, 6 Aug 2007 07:36:46 -0700
* Cc: Rohan Mahy , behave at ietf.org, dwing at cisco.com
* In-reply-to:
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com>
Hi Remi,
I seem to remember that gathering TURN candidates specifically was a SHOULD in a previous version of ICE. Now it just says: "Agents SHOULD obtain relayed candidates..." but doesn't specify a specific method. Even so, it seems that normatively describing how to use at least one method with ICE is quite important.
A related issue is that since SIP calls can fork, ICE needs to work in this environment, so any relay protocol needs to have deterministic behavior in this environment. I personally would not have done TURN if we did not need support for forking. Without forking we could have reused another relay protocol (like SOCKS).
And as much as I would like to wish otherwise, I suspect you are right that we don't know how well TURN TCP really works without an early implementation ICE TCP.
thanks,
-rohan
http://www1.ietf.org/mail-archive/web/behave/current/msg02650.html
* To:
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rohan Mahy
* Date: Mon, 6 Aug 2007 07:38:13 -0700
* Cc: Rohan Mahy , behave at ietf.org, dwing at cisco.com
* In-reply-to:
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200707311216.18858.remi.denis-courmont@nokia.com> <20d2bdfb0708011318t1b9d543ct59e3fbca27a31607@mail.gmail.com>
Hi Remi,
I think (2) is the normal, default handling for TCP to TCP relays. Yes, B could make its window very, very small, but TCP A is still no worse off than a direct connection to the peer would have been. I also don't see how this exhausts server resources. The server does not have to do any work while it is not reading. It just needs to keep connection state for the two connections.
The TURN server could still set some minimum responsiveness or throughput metric after which it employs (3), but (2) is still the best default IMO.
thanks,
-rohan
http://www1.ietf.org/mail-archive/web/behave/current/msg02651.html
* To: "ext Rohan Mahy"
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rémi Denis-Courmont
* Date: Tue, 7 Aug 2007 09:37:42 +0300
* Cc: behave at ietf.org, dwing at cisco.com
* In-reply-to:
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* Organization: Nokia TP-SP-SWD
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com>
* User-agent: KMail/1.9.6
On Monday 06 August 2007 17:36:46 ext Rohan Mahy wrote:
> A related issue is that since SIP calls can fork, ICE needs to work
> in this environment, so any relay protocol needs to have
> deterministic behavior in this environment. I personally would not
> have done TURN if we did not need support for forking. Without
> forking we could have reused another relay protocol (like SOCKS).
After a bit of thinking, I doubt forking really requires multiplexing
TCP-over-TCP. The client can simply reconnect to the TURN server and request
the same port number as was already allocated using REQUESTED-PORT-PROPS,
REQUESTED-IP and REQUESTED-TRANSPORT, and preserve 1:1 TCP connection
relaying.
As such, I see no reasons for allowing 1:N (TCP|TLS)-to-TCP.
--
Rémi Denis-Courmont
http://www1.ietf.org/mail-archive/web/behave/current/msg02652.html
* To: Rémi Denis-Courmont
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rohan Mahy
* Date: Tue, 7 Aug 2007 07:03:02 -0700
* Cc: Rohan Mahy , behave at ietf.org, dwing at cisco.com
* In-reply-to: <200708070937.42455.remi.denis-courmont@nokia.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708070937.42455.remi.denis-courmont@nokia.com>
Hi Rémi,
I have to think about this suggestion a bit more. Today, sending a new Allocate request with an existing allocated address and port causes a move. We would need to add a new attribute at least.
I'm not sure this is really any simpler than supporting and (briefly) using 1:N TCP connections. I don't think it is a practical problem to limit the speed of the client to TURN server connection to the speed of the slowest of the server to peer connections, but this would be good to model.
thanks,
-rohan
http://www1.ietf.org/mail-archive/web/behave/current/msg02663.html
* To: "ext Rohan Mahy" , behave at ietf.org
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rémi Denis-Courmont
* Date: Thu, 9 Aug 2007 14:01:29 +0300
* Cc: dwing at cisco.com
* In-reply-to: <1FA2E0BB-9028-48E0-87E6-01B0D31E3365@ekabal.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* Organization: Nokia TP-SP-SWD
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708070937.42455.remi.denis-courmont@nokia.com> <1FA2E0BB-9028-48E0-87E6-01B0D31E3365@ekabal.com>
* User-agent: KMail/1.9.6
Hello,
On Tuesday 07 August 2007 17:03:02 ext Rohan Mahy wrote:
> I have to think about this suggestion a bit more. Today, sending a
> new Allocate request with an existing allocated address and port
> causes a move. We would need to add a new attribute at least.
While I do understand the point of moving a UDP flow, I doubt moving a TCP
session makes any sense. If the TCP connection breaks, the server and the
server cannot really know up to where the other side has successfully
received data - all they know is that it's somewhere between the highest
received acknowledgement sequence and the highest sent sequence. But within
the window, it's unknown by design.
In theory, both sides could replicate "stream offsets" above the socket layer,
and exchange them when moving a connection, but I think nobody wants to go
into that. And we'd have to replicate the TCP window buffers as well to
support retransmission.
As such, I really think "moving" should be restricted to UDP server-to-peer
flows. For TCP server-to-peer flows, if the client-to-server session breaks,
the server must break the server-to-peer connection.
[PM] I think that this is not a problem for UDP allocations, even if the
client to server connection runs over TCP.
However, there may well be a problem here for TCP allocations.
> I'm not sure this is really any simpler than supporting and (briefly)
> using 1:N TCP connections. I don't think it is a practical problem
> to limit the speed of the client to TURN server connection to the
> speed of the slowest of the server to peer connections, but this
> would be good to model.
Say I want to send a 2gigs movie to a forked MSRP session. Should the fastest
receiver wait for the slowest one? As a user, I definitely expect the fastest
to not to have to wait.
--
Rémi Denis-Courmont
http://www1.ietf.org/mail-archive/web/behave/current/msg02667.html
* To: Rémi Denis-Courmont
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rohan Mahy
* Date: Fri, 10 Aug 2007 07:14:58 -0700
* Cc: Rohan Mahy , behave at ietf.org, dwing at cisco.com
* In-reply-to: <200708091401.29705.remi.denis-courmont@nokia.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708070937.42455.remi.denis-courmont@nokia.com> <1FA2E0BB-9028-48E0-87E6-01B0D31E3365@ekabal.com> <200708091401.29705.remi.denis-courmont@nokia.com>
On Aug 9, 2007, at 4:01 AM, Rémi Denis-Courmont wrote:
I'm not sure this is really any simpler than supporting and (briefly)
using 1:N TCP connections. I don't think it is a practical problem
to limit the speed of the client to TURN server connection to the
speed of the slowest of the server to peer connections, but this
would be good to model.
Say I want to send a 2gigs movie to a forked MSRP session. Should the fastest
receiver wait for the slowest one? As a user, I definitely expect the fastest
to not to have to wait.
Yes, I still think it is reasonable for the fastest receiver to wait for the slowest one. This only happens during the period where you are forking. You probably won't start sending a 2gig movie until you've resolved which instance you are sending it to, and therefore selected a single fork by then.
thanks,
-rohan
http://www1.ietf.org/mail-archive/web/behave/current/msg02671.html
* To: "ext Rohan Mahy"
* Subject: Re: [BEHAVE] TURN: technical review by September 1
* From: Rémi Denis-Courmont
* Date: Mon, 13 Aug 2007 10:15:47 +0300
* Cc: behave at ietf.org, dwing at cisco.com
* In-reply-to: <1A1A8416-C8B0-45CC-ACAE-EDB535551A23@ekabal.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* Organization: Nokia TP-SP-SWD
* References: <018d01c7d2ce$ce9bee50$c5f0200a@amer.cisco.com> <200708091401.29705.remi.denis-courmont@nokia.com> <1A1A8416-C8B0-45CC-ACAE-EDB535551A23@ekabal.com>
* User-agent: KMail/1.9.6
On Friday 10 August 2007 17:14:58 ext Rohan Mahy wrote:
> On Aug 9, 2007, at 4:01 AM, Rémi Denis-Courmont wrote:
> >> I'm not sure this is really any simpler than supporting and (briefly)
> >> using 1:N TCP connections. I don't think it is a practical problem
> >> to limit the speed of the client to TURN server connection to the
> >> speed of the slowest of the server to peer connections, but this
> >> would be good to model.
> >
> > Say I want to send a 2gigs movie to a forked MSRP session. Should
> > the fastest
> > receiver wait for the slowest one? As a user, I definitely expect
> > the fastest
> > to not to have to wait.
>
> Yes, I still think it is reasonable for the fastest receiver to wait
> for the slowest one. This only happens during the period where you
> are forking. You probably won't start sending a 2gig movie until
> you've resolved which instance you are sending it to, and therefore
> selected a single fork by then.
I do not quite agree. To recap, there are lots of issues with 1:N TURN/TCP
sessions.
First, there is no TCP protocol that supports forking as of now. Contrary to
my earlier assumption (my mistake), MSRP does not support forking at all.
Quoting draft-ietf-simple-message-sessions-19 §5.4:
(...) The
node MUST also check to make sure the session is not already in use
on another connection. If the session is already in use, it MUST
reject the request with a 506 response.
If it were legal to have multiple connections associated with the
same session, a security problem would exist. If the initial SEND
request is not protected, an eavesdropper might learn the URI, and
use it to insert messages into the session via a different
connection.
Second, I am still doubtful how practical it would be to "resolve" a fork when
the slowest peer is very slow.
Third, there is no way for the client to request resetting a TCP session. One
simple way would have been to close the TURN connection, but that only works
if we have 1:1 connection, and disallow "moving" TCP connections.
Forth, I may have missed something, but how will support for multiple TCP not
contradict the security requirement NOT to allow running servers?
Fifth, and loosely related, "moving" TCP connections is not generally
possible. It might work for TCP-framed RTP. But it does not work with
any "normally TCP" protocol, such as TLS or MSRP, as these cannot cope with
reordering or packet loss.
--
Rémi Denis-Courmont
http://www1.ietf.org/mail-archive/web/behave/current/msg02672.html
* To: ext Rohan Mahy , jdrosen at cisco.com
* Subject: [BEHAVE] TURN: REQUESTED-IP / RELAY-ADDRESS
* From: Rémi Denis-Courmont
* Date: Mon, 13 Aug 2007 15:29:13 +0300
* Cc: behave at ietf.org
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* Organization: Nokia TP-SP-SWD
* User-agent: KMail/1.9.6
Hello,
It currently seems that REQUESTED-IP is supposed to not be "obfuscated" while
RELAY-ADDRESS is. I expect both options to contain the same IP address... is
there a reason for this apparent inconsistency?
[PM] FIXED. This either was not a problem, or was fixed by Rohan. The draft now
says that it is based on XOR-MAPPED-ADDRESS.
http://www1.ietf.org/mail-archive/web/behave/current/msg02710.html
* To: behave at ietf.org
* Subject: [BEHAVE] TURN Set Active Destination problem (again)
* From: Rémi Denis-Courmont
* Date: Fri, 24 Aug 2007 15:32:38 +0300
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* Organization: Nokia TP-SP-SWD
* User-agent: KMail/1.9.6 (enterprise 0.20070508.662491)
Hello,
About Set Active Destination over UDP, TURN-04 says:
If the active destination is already set and the request was
received over UDP, the Set Active Destination request is rejected
with a 439 Active Destination Already Set error response. This
prevents the race condition described in the previous section.
If however, the successful response to a Set Active Destination request got
lost, the request is retransmitted. But then, following the current rule, the
server returns 439. Well, in theory, it must return a success response again,
as it should see that the transaction ID is the same as a previous request,
and apply the idempotency principle, but that's a impractical.
May I suggest that the server would return a successful response whenever it
receives a Set Active Destination request where the REMOTE-ADDRESS is
identical to the currently active destination?
[PM] FIXED. Set Active Destination has been removed.
http://www1.ietf.org/mail-archive/web/behave/current/msg02711.html
* To: Behave WG , Jonathan Rosenberg , Rohan Mahy
* Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04
* From: Cullen Jennings
* Date: Tue, 28 Aug 2007 17:14:54 -0700
* Authentication-results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
* Cc:
* Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3546; t=1188346585; x=1189210585; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Comments=20on=20draft-ietf-behave-turn-04 |Sender:=20; bh=uy41j1rHWqZ6WgzZYMR77zTc6pSGPKb+Y+gsZk1qHOE=; b=V1qrzFOEm8gfOH1klrM+1DuqKahwbYvY6N+svM0X+SM5aDh9INaI4G8TkXbcYFv+w50oqpXm iMLwwhOjyRxBFh83i9S6YsgN6imbeDO4nmNIILfWJSlJoA1qlTw/70tJ;
* Impp: xmpp:cullenfluffyjennings@jabber.org
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
This document is looking very good - few big items
I don't understand when a server would send a status indication with the state as LISTEN. Can we remove this value?
[PM] Not applicable to UDP allocation draft.
I'm a bit lost on auth stuff - probably need separate thread on that. 3489bis removed a way to get short term secrets but turn seems to assume they are still there. More importantly, we need to have some sort of security on the connection status indication bet since this can not be challenged, we can only use short term credentials. However, it's not clear how to get one. I suspect we may need a conference call some time on STUN/TURN credentials. It's not clear that the right message have enough in them to make replay attacks not be a problem for short term credentials usage.
[PM] PROBLEM. Connection status indications have moved to the TCP allocations draft, but I think Cullen's comments apply to the Channel Confirmation message.
What happens when relay receives more than it can send. My initial thought on this is 1) when receiving UDP packets, discard them. 2) when receiving TCP, stop reading from the incoming TCP buffer until their is space to send. If there are multiple incoming TCP connection, order they get serviced in is not specified and clients can't make any assumptions about it.
[PM] FIXED. I added a short PP saying that if the server cannot send to the peer, it just dropped the received data.
If a client ends up with two remote TCP connection (on the same allocation), it would be nice to have a way to close one of them but not the other.
[PM] One for TURN-TCP draft
The connection status indication probably needs the remote address attribute so that one can figure out what is going on when there are two TCP connection to same allocation.
Section 6.1.2.1 .. the idea that a move can be signaled by using the same credential would work for short term credentials but not long term ones as more than one client can share the same long term. I find this "move" idea fraught with peril to implement - particularly in the TCP case, I wonder if we really need it. I have a hard time imaging an TCP connection with active data flowing not getting out of sync during a move.
[PM] For TURN-TCP draft ...
The redirect to a different server when overloaded seems like a bad idea. Imagine I have two servers A and B that are both overloaded - seems like I could have endless redirects. Having the client know about two servers via DNS then try one and if it is busy try the other makes more sense to me.
[PM] PROBLEM. I think Cullen has a point, and we need to do something. Do put in text saying "check for redirect loops" or do we just remove this concept?
It might make sense to suggest that after a TCP allocation happened, the TURN server using BSD sockets would not want to start listening on it until their was at least one valid permission set on it.
Trivial stuff after this ....
Be nice to have an example showing TCP simultaneous open.
Section 4.1 - 2nd para - you suggest that there are cases where TLS will get thorough a firewall and TCP will not - this is true but so is the converse so don't want to imply one way or other is better for firewall traversal.
[PM] FIXED. I read this para and it doesn't seem to favor TLS over TCP. It just says there are cases where TLS might work that TCP might not.
Figure 1 - would make more sense to me with s/STUN/TURN
[PM] FIXED. Changed "STUN Client" and "STUN Server" to "TURN ...".
Section 6.1.2.1 - It is confusing how the client would know what IP address the server supports for relaying when the client wants to use the REQUEST-IP attribute. If you added some text explaining that this was used when allocating a second port after first port was allocated, it would be easier to understand.
[PM] Personally, I don't see the problem. There is already text that reads:
As a consequence, a client needing a second transport address on the same
interface as a previous one can make that request.
and I think this makes things clear.
In
The server SHOULD only allocate ports in the range 1024-65535. This
is one of several ways to prohibit relayed transport addresses from
being used to attempt to run standard services.
This does not seem to be a good way (or the way used in the draft) to accomplish this so I would just delete the second sentence.
[PM] DISCUSS. I think we should either delete the whole paragraph, or change the first sentence to MAY and delete the rest.
http://www1.ietf.org/mail-archive/web/behave/current/msg02714.html
* To: Cullen Jennings
* Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-04
* From: Marc Petit-Huguenin
* Date: Wed, 29 Aug 2007 08:56:35 -0700
* Cc: Rohan Mahy , Behave WG
* In-reply-to: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com>
* User-agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828)
Cullen Jennings wrote:
>
[snip]
>
> The redirect to a different server when overloaded seems like a bad
> idea. Imagine I have two servers A and B that are both overloaded -
> seems like I could have endless redirects. Having the client know about
> two servers via DNS then try one and if it is busy try the other makes
> more sense to me.
>
I agree that using the redirect in this case will not really help. My
proposal was to send back a domain name instead of an IP address, and to
use it in the client in replacement of the current domain used to find
the SRV records, but by remembering all the IP addresses already tried
and excluding them from the results of the subsequents SRV queries.
--
Marc Petit-Huguenin [ ]
Home: marc at petit-huguenin.org [RFC1855-compliant space for rent ]
Work: marc at 8x8.com [
http://www1.ietf.org/mail-archive/web/behave/current/msg02715.html
* o: Marc Petit-Huguenin
* Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-04
* From: Cullen Jennings
* Date: Wed, 29 Aug 2007 15:15:03 -0700
* Authentication-results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
* Cc: Rohan Mahy , Behave WG
* Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1249; t=1188425795; x=1189289795; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20Comments=20on=20draft-ietf-behave-turn-04 |Sender:=20; bh=335kBAMQz6EROC6xdYOSnk9eYFVVQGFsFjXG8s9GRMg=; b=MeD7crK6Ved/WadKcwnvw5RcUU1I7FePjQDb1kWMKDpz4XGRkbaV65IUUFMKBwTwarQa3I9v Ki+DsMINNRHNnb8vnMN3IqN7rBCQ5emvTTzoDkI5A3D8lun+ADxK6WDWIx72+NmlwVA6U2f9mz E2TumynYzq27D0/3t+CRtxyqE=;
* Impp: xmpp:cullenfluffyjennings@jabber.org
* In-reply-to: <46D59733.8070703@acm.org>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com> <46D59733.8070703@acm.org>
Ah, I see what you are thinking but seems like it would be better to just start out with the SRV record and never need the redirect.
http://www1.ietf.org/mail-archive/web/behave/current/msg02716.html
* To: Cullen Jennings
* Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-04
* From: Marc Petit-Huguenin
* Date: Wed, 29 Aug 2007 16:12:26 -0700
* Cc: Rohan Mahy , Behave WG
* In-reply-to: <3B53CED5-5A4B-488D-8F15-5421E7E5AD8E@cisco.com>
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* References: <43E08DFF-F4FE-4848-B530-6D7F3CB41DE2@cisco.com> <46D59733.8070703@acm.org> <3B53CED5-5A4B-488D-8F15-5421E7E5AD8E@cisco.com>
* User-agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828)
Cullen Jennings wrote:
>
> Ah, I see what you are thinking but seems like it would be better to
> just start out with the SRV record and never need the redirect.
Yes, but the redirect permits to do things a little bit more
dynamically. Here's an example:
Let's say we have 3 data centers, one in London, one in Santa Clara, CA
and another in Hong Kong. The initial SRV lookup for the example.com
domain returns this:
SRV 0 1 3478 redirect.london.example.com.
SRV 0 1 3478 redirect.santa-clara.example.com.
SRV 0 1 3478 redirect.hong-kong.example.com.
All RR have the same priority, so one of them is randomly selected. The
client sends the request to the server, the server uses a geoip lookup
to detect the closer data center to the client, and sends a redirect
with the domain hong-kong.example.com. The client then do a SRV query
for hong-kong.example.com, with the following result:
SRV 0 1 3478 turn1.hong-kong.example.com.
SRV 0 1 3478 turn2.hong-kong.example.com.
SRV 1 1 3478 turn1.santa-clara.example.com.
SRV 1 1 3478 turn2.santa-clara.example.com.
SRV 1 1 3478 turn1.hong-kong.example.com.
SRV 1 1 3478 turn2.hong-kong.example.com.
The TURN servers in the Hong Kong data center will be tried first, then
the TURN servers in the other data centers if they are unreachable.
Note that this is just an example, there is better ways to achieve the
same result.
http://www1.ietf.org/mail-archive/web/behave/current/msg02717.html
* To: Behave WG , jdrosen at cisco.com, rohan at ekabal.com, huitema at microsoft.com
* Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04
* From: "Alfred E. Heggestad"
* Date: Fri, 31 Aug 2007 00:22:24 +0200
* Cc:
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
* User-agent: Icedove 1.5.0.12 (X11/20070607)
Comments on draft-ietf-behave-turn-04
Technical Review
by Alfred E. Heggestad
30. Aug 2007
General:
- Did we consider the scenario where the NAT between the TURN client and the
TURN server reboots? In such a case both TURN client and server will still
send and receive data (such as RTP), and if NAT in between reboots, a new
NAT mapping will be created. The TURN server will not be able to update the
5-tuple for the "flow" and the result is no RTP data send/received. If we
can use some kind of unique "Session ID" for the TURN allocation, it will
still be possible to handle the cases where the NAT reboots. On Allocate
Request the client could choose a unique 64-bit session ID, which will be
used in all future communications with the server (for that session).
Alternatively, the TURN server could keep track of all session IDs, and
allocate it for the client (returned in Allocate Response). All sub-
sequent TURN messages from the client will then contain this 64-bit
session ID, and the TURN server can lookup the allocation (Session) without
looking at the Source IP+port. Now, this will probably also introduce some
new security issues..
[PM] FIXED. I believe our move idea handles this.
- Why is the FINGERPRINT attribute not mentioned at all in TURN ?
[PM] FIXED. There is no need for a client to use the FINGERPRINT attribute,
since all TURN messages are sent on channel 0.
- There are still references to "Shared Secret request", in section 6.1.1.1
and 6.1.1.2. This is removed in rfc3489bis-08 and should also be removed
in TURN
[PM] FIXED. These have been removed.
- The BANDWIDTH parameter is a bit problematic, since the TURN allocation
is normally done before an SDP Offer is sent. If a user-agent is sending
an SDP offer with audio codecs G.711 (64 kbps) and G.729 (8 kbps) it will
use the highest bandwidth (64 kbps) to the TURN server. When the call is
established with G.729, it should be possible to send an update to the
TURN server, telling it that the bandwidth need changed to 8 kbps
[PM] DISCUSS. (See my e-mail on subsequent Allocate requests)
> Section 4
>
> When the TURN client to server communication is over a datagram
> protocol (UDP), any datagram received from the active peer that has
> the STUN magic cookie is wrapped in a Data Indication. Likewise any
> datagram sent by the client that has the STUN magic cookie and is
> intended for the active peer is wrapped in a Send Indication. This
> wrapping prevents the STUN relay server from inappropriately
> interpreting end-to-end data.
Does this mean that the TURN client/server has to scan the whole datagram
looking for the STUN magic cookie? I think not, and I would assume that
it only need to check the 20 first bytes of the datagram.
[PM] FIXED. The problem no longer exists (because of channels) and the
paragraph quoted has been removed.
> Section 6.2
>
> Response with an appropriate error response code, such as a 431
> (Integrity Failure) or 436 (Unknown User).
error codes 431 and 436 are no longer in rfc3489bis-09
[PM] DISCUSS. There are some other problems with the paragraph this sentence
appears in. See my e-mail on the subject.
> 6.5. Connection Status Indication
>
> When the TURN to peer leg is TCP, the TURN client needs to be aware
> of the status of these TCP connections. The TURN extension defines
> application states for a TCP connection as follows: LISTEN,
> ESTABLISHED, CLOSED. Consequently, the TURN server sends a
Probably a new state should be defined, if the TCP connection failed
(host unreachable, port unreachable)
[PM] One for TURN-TCP
> 7.9. CONNECT_STAT
>
> This attribute is used by...
It should be mentioned which TURN Requests/Responses/Indications this
attribute is valid for.
[PM] One for TURN-TCP.
> 17.2. Informative References
>
Should be updated:
[1] draft-ietf-behave-rfc3489bis-06 -> draft-ietf-behave-rfc3489bis-09
[8] draft-ietf-mmusic-ice-16 -> draft-ietf-mmusic-ice-16
[9] draft-ietf-behave-nat-udp-08 -> RFC 4787
[PM] FIXED. For the first two, the xml2rfc program grabs the latest version.
The last one I had to fix by hand, and update all the references in the document.
------------------------------------------------------------------------------
NITS
General:
There is a mix of "Allocate request" and "Allocate Request" in the
document. This term should be consistantly used, and either stick
to one of them.
[PM] FIXED. The spec now uniformly uses Allocate Request. In many places the spec used
Allocate request to mean Allocate method or Allocation transaction, so I changed these
as well.
> Abstract
>
> ..Relays around NAT (TURN), is useful for elements behind NATs whose
> mapping behavior is address and port dependent. The extension..
^^^^^^^^^^^^^^^^^^^^^^^^^^
TURN is also useful for elements behind "Address-Dependent Mapping" NATs,
right? Ideally this should be written "..whose mapping behavior is NOT
Endpoint-Independent Mapping.."
[PM] FIXED.
Terminology from RFC 4787:
- Endpoint-Independent Mapping:
- Address-Dependent Mapping:
- Address and Port-Dependent Mapping:
> 6.1.1.1. Initial Requests
>
> ...
> adajacent pair, even and odd respectively, for compatibility with a
^^^^^^^^^
typo, should be "adjacent"
[PM] FIXED.
http://www1.ietf.org/mail-archive/web/behave/current/msg02718.html
* To: behave at ietf.org
* Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04
* From: Brian Hibbard
* Date: Fri, 31 Aug 2007 17:38:53 -0500
* List-archive:
* List-help:
* List-id: mailing list of BEHAVE IETF WG
* List-post:
* List-subscribe: ,
* List-unsubscribe: ,
TCP
------
I'm unclear on exactly how the TCP Connect request is supposed to work. I noticed that there is nothing in TURN-04 that says how an allocation enters LISTEN, although previous versions stated that an allocation would enter LISTEN at the time of allocation.
If the intent is that simultaneous open is the sole means by which allocations can connect to each other, I have a difficult time believing this is feasible. In order for that to work as true simultaneous open, the SYNs must cross on the wire. Assuming a BSD- ish implementation, if they don't cross on the wire, you have the possibility that a SYN will be received on a socket that is still in the CLOSED pseudo-state. On Mac OSX, the SYN received in CLOSED (socket is bound but not listen()ing ) is silently absorbed and both sides will retransmit until something that looks similar to simultaneous open happens. On Linux, when SYN is received in CLOSED (as before--bound but not listening), an RST is transmitted, and the connection attempt is terminated. Unless there is some means outside of TURN to guarantee that Connect requests are sent such that SYNs literally cross on the wire (so that both receivers are in SYN_SENT and not CLOSED), I don't see how you can expect that mechanism to work well. Of course, there are things one might do to suppress the RST so SYN retransmissions might occur, but an RST to a SYN received in CLOSED doesn't sound wrong to me.
Therefore, it looks better to establish a good way to manage whether an allocation is LISTENing, or that it is actively connecting, and that it is not doing both simultaneously. Previously on the BEHAVE list, a way to do both was brought up, but, while interesting, sounds like an exploit and forces an implementation into the dark nether regions of platform-specific behavior. The fact that the socket API doesn't allow a bind() if a socket is already listen()ing is something TURN should respect. Besides, most clients that get retrofitted with TURN probably want to treat TURN as a shim in their transports to the greatest extent possible, and won't be interested in building a bunch of special behavior around TURN's peculiar LISTEN- while-Connect-request capability even if you did manage to solve that issue. Those implementations would simply grab a new port when they want to make a new connection--just like how everyone does today.
Also, multiplexing traffic across multiple TCP connections within a single allocation has been brought up on the list before. I agree that it would be powerful and desirable to do that...if you could do it properly. It's the "properly" part that scares me. I think there is a class of use cases that this mechanism could support well. Such cases would be where only one of the connections is sending "lots" of traffic, and the other(s) are sending "little". (Ignore, for the time being, how the TURN server would distinguish this subset of possibilities and allow them while suppressing the others a priori.) This presumes that we have a good way to adjudicate BANDWIDTH control.
From the spec, it sounds like BANDWIDTH is meant to cap the traffic on the allocation. Is this for the sum off all permissions, and in both directions? Exactly what the TURN server does to constrain this traffic hasn't been addressed. Discarding chunks of data in TCP could cause a painful loss of framing for higher level protocols, such as SIP. The only other options that are obvious are to throttle reading from the client and all of the allocation's peer connections and let TCP manage the congestion, or tear down with RST. Exactly how you divide the bandwidth between reading each of the connections involved needs a lot of discussion. It would be terrible if the media stream starved the signaling stream, and TURN can't tell the difference.
Therefore, I would be greatly relieved if multiple TCP connections on a single allocation were not supported.
[PM] This is for TURN-TCP
Set Active Destination
----------------------------------
For UDP, it would be reasonable to suggest that the client start using Send indications shortly before (perhaps as long as one second?) sending a Set Active Destination request to clear the current active destination. This would help the case that some of the packets sent prior to the SAD are processed by the server after the SAD is processed, due to packet ordering.
[PM] FIXED. Set Active Destination is now gone.
http://www1.ietf.org/mail-archive/web/behave/current/msg02719.html
* To: behave at ietf.org
* Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-04
* From: Rémi Denis-Courmont