Subject: Re: [BEHAVE] TURN: Proposed conf call

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 1 Apr 2008 12:26:26 -0400

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Tuesday, April 01, 2008 11:29 AM
> To: Hadriel Kaplan
> Cc: Rémi Denis-Courmont; [email-masked]
> Subject: Re: [BEHAVE] TURN: Proposed conf call
>
> At Tue, 1 Apr 2008 10:48:24 -0400,
> Hadriel Kaplan wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > Of Rémi Denis-Courmont
> > >
> > > I believe, TWIST would be is very complicated to implement without
> special
> > > privileges.
> >
> > Actually, I think "special privileges" (if by that you mean
> > root/administrative level access) are actually appropriate to
> > require, to make a PC into a TURN/TWIST relay or client, imho.
>
> Why would it make sense to require admin access to be a *client*?

Because a client as currently defined in TURN and TURN-tcp can use TURN to create a long-lived, publicly reachable TURN relay listen port for server-type services to itself.  Although there is some wording in TURN security section saying it cannot be run as such, I don't see any such restriction in the protocol itself - for example the permissions section as defined does not prevent a willing client app and/or TURN server from doing so. (though I could be wrong)

And because I fear the perception this thing will have is of being just another "p2p" type thing that corporate IT types will freak out over and set their firewalls to block.  So I'm thinking letting them have control over their PCs and uses of it will possibly allay their fears. (although I recognize that may be a hopeless cause for some, and that current TURN properties may be sufficiently controllable for others)

I am relating the concept of "special privileges" to mean those only available to the owner of the host system, vs. a user of the system who does not own it.  But maybe my semantic interpretation is wrong?

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 01 Apr 2008 09:43:04 -0700

At Tue, 1 Apr 2008 12:26:26 -0400,
Hadriel Kaplan wrote:
> Because a client as currently defined in TURN and TURN-tcp can use
> TURN to create a long-lived, publicly reachable TURN relay listen
> port for server-type services to itself.  Although there is some
> wording in TURN security section saying it cannot be run as such, I
> don't see any such restriction in the protocol itself - for example
> the permissions section as defined does not prevent a willing client
> app and/or TURN server from doing so. (though I could be wrong)

I'm not sure what you mean by "in the protocol"? It's explicitly
forbidden by the permission mechanism. Obviously, the server could
be noncompliant, but how is this a TURN issue?

> I am relating the concept of "special privileges" to mean those only
> available to the owner of the host system, vs. a user of the system
> who does not own it.  But maybe my semantic interpretation is wrong?

As far as I know, the way that nearly all desktop machines are configured
that person who uses the machine has or can get admin access.

-Ekr

---

From: "Derek MacDonald" <[email-masked]>
Date: Tue, 1 Apr 2008 12:15:10 -0700

2 Points:

Special Privileges

There are many scenarious where getting administrative access on the client
is impossible. One example is a client on a USB stick that a user is running
at an internet cafe or other public computer.  Another common scenario is
corporate computing environments where getting admin access requires
sacrificing a goat.

Running a "Server" on the TURN server

This is forbidden by TURN even though the operation could be accomplished
using the protocol.  I don't see how this is too different from running a
relay server on 443. A non-compliant implementation can't really be
considered a core TURN issue.

-Derek

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 1 Apr 2008 16:07:59 -0400

> be noncompliant, but how is this a TURN issue?

I meant afaict the permission mechanism didn't stop a normal TURN client from allocating a relay address and a normal TURN server from sending it a DATA indication of receiving something for that relay address, if a permission was not in effect.  But I think I was wrong.  After reading it again carefully, I think what it's saying is a UDP permission is only created when a TURN client sends something to that peer first, and a TCP listen request must have a peer address for a permission, and TURN server silently discards any inbound messages on its relay side not matching a permission?  If so, then it's good.

> that person who uses the machine has or can get admin access.

OK then why are we worried about a mechanism needing "special privileges" to work? (ie, why is it bad if one needs to be root/admin?)

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 01 Apr 2008 13:42:24 -0700

At Tue, 1 Apr 2008 16:07:59 -0400,
Hadriel Kaplan wrote:
> OK then why are we worried about a mechanism needing "special
> privileges" to work? (ie, why is it bad if one needs to be
> root/admin?)

Just because something is not an effective security barrier
does not mean that it's not a PITA.

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Wed, 2 Apr 2008 10:13:01 -0400

Folks:

I suggest we confine our discussion to draft-ietf-behave-turn ("TURN- 
UDP"). This draft supports only UDP allocations and does not have any  
head-of-line blocking problems or MSRP-like multiplexing problems (as  
far as I am aware). However, it does allow TCP or TLS over TCP  
connections between the client and the server.

Bringing in TURN-TCP is just confusing the issue. The authors split  
TURN-TCP from TURN because it did have some of these problems, and  
even though we had some ideas how to fix them, we didn't have time to  
work through the details. The TURN-TCP document has not been updated  
since November 2007, is no longer consistent with the current TURN  
draft, and should probably be considered just a placeholder.

- Philip

On Tue, 1-Apr-08, at 09:39 , Rémi Denis-Courmont wrote:
> Le Friday 28 March 2008 20:23:59 ext Philip Matthews, vous avez  
> écrit :
>> There has been some discussion recently on the encapsulations used
>> between the client and the server in TURN. Specifically, Hadriel has
>> questioned the use of TCP transport for a UDP allocation, and has
>> proposed an alternative encapsulation in his TWIST proposal.
>
> privileges. In theory, it is do-able: it would be a slimmed-down  
> userland
> TCP/IP stack. This applies to both TURN client and TURN relay, and is
> somewhat similar to what slirp[1] does. Alternatively, some kind of  
> raw
> packets or tunneling API could be used.
> This seems to be fit fairly well for hardware relays, but not quite  
> anything
> else (client, or soft relays).
>
> [1] http://slirp.sourceforge.net/
>
> Nevertheless, this proposal would address the congestion issues  
> involving
> multiple TCP session over a single TURN allocation. It does not  
> solve the
> TCP-to-UDP problem - it just does not allow this case to happen, as  
> the
> client must use UDP to the relay, independent of the relay-to-peer  
> transport.
>
>
>
> The current TURN proposal does not address head-of-line blocking and  
> MSRP-like
> multiplexing problems. IMHO, this is a serious flaw. TCP-to-UDP  
> however works
> (if UDP packets are allowed to be dropped), though that can be  
> difficult if
> not impossible for hardware relays to implement.
>
> The "obvious" way to fix the congestion issues is the way SSH does  
> (I think):
> have some congestion control protocol on top of TCP. Complicated  
> however.
>
>
>
> The N:N TCP connection proposal solves the congestion issues. It is  
> extremely
> easy to implement in software (both client and relay). In fact,  
> client can
> almost use the TCP sockets as usual - as they do with SOCKS.  
> Software relays
> can terminate the TCP sessions toward both client and peer and  
> forward data
> across. I believe, it would also be easy to implement in hardware or  
> kernel:
> TCP packets can simply be translated much like a double-sided NAT -  
> in this
> case congestion control (and retransmission) are done end-to-end
> (client-to-peer).
>
> For TCP-to-UDP, this would be pretty much the same as the current  
> TURN. In
> fact, in this case using multiple TCP connections is not so  
> interesting.
>
>
> So, as far as I am concerned (you're free to disagree):
>
>                       TWIST   TURN     N:N
> ----------------------------------------------
> TCP-UDP HW relay           No    Hard     Hard
> TCP-UDP SW relay           No    Easy     Easy
> TCP-TCP HW relay         Easy  Medium?    Easy
> TCP-TCP SW relay         Hard  Medium     Easy
> TCP-TCP Normal client    Hard  Medium     Easy
> TCP-TCP "Root" client  Medium  Medium?    Easy
> Number of flows           N+1      N+1    2N+1
>
> -- 
> Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Wed, 2 Apr 2008 10:20:36 -0400

On Tue, 1-Apr-08, at 16:07 , Hadriel Kaplan wrote:
> I meant afaict the permission mechanism didn't stop a normal TURN  
> client from allocating a relay address and a normal TURN server from  
> sending it a DATA indication of receiving something for that relay  
> address, if a permission was not in effect.  But I think I was  
> wrong.  After reading it again carefully, I think what it's saying  
> is a UDP permission is only created when a TURN client sends  
> something to that peer first, and a TCP listen request must have a  
> peer address for a permission, and TURN server silently discards any  
> inbound messages on its relay side not matching a permission?  If  
> so, then it's good.

There is no "TCP listen request" in draft-ietf-behave-turn.  And  
please ignore draft-ietf-behave-turn-tcp for now.

And yes, a permission is created only by an explicit action by the  
client (either sending a packet to the peer, binding a channel, or an  
sending an empty Send indication).

- Philip

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 10:52:02 -0400

> From: Philip Matthews [mailto:[email-masked]]
>

OK, I will ignore TURN-tcp for now.

With regards to draft-ietf-behave-turn, when using a TCP or TLS connection for the client-TURN portion, is there something in draft-ietf-behave-turn that says one TCP connection is used for one UDP peer connection?  I was under the impression it allowed/supported many peer UDP connections to be multiplexed in one TCP or TLS TURN connection.

-hadriel

---

From: Philip Matthews <[email-masked]>
Date: Wed, 2 Apr 2008 12:04:37 -0400

On Wed, 2-Apr-08, at 10:52 , Hadriel Kaplan wrote:
> With regards to draft-ietf-behave-turn, when using a TCP or TLS  
> connection for the client-TURN portion, is there something in draft- 
> ietf-behave-turn that says one TCP connection is used for one UDP  
> peer connection?  I was under the impression it allowed/supported  
> many peer UDP connections to be multiplexed in one TCP or TLS TURN  
> connection.

draft-ietf-behave-turn-07 allows a client to communicate with multiple  
peers using a single (UDP) allocation. This is true regardless of  
whether UDP, TCP, or TLS over TCP is used for the connection between  
the client and the server. This is illustrated in figure 1 in the draft.

There are a number of reasons for allowing this:

1) If the call forks, and multiple endpoints answer the call, then  
this means that ICE just works, and there is no need to provide each  
endpoint with a different relayed transport address.

2) Some people want a client to use a single relayed transport address  
for ALL communication between the client and peers. For example, some  
people implementing NAT traversal for HIP are thinking of doing this.