headers
Jonathan Rosenberg | 5 Dec 2005 16:16
Picon
Favicon

Fora for TURN discussion: BEHAVE list

Sorry for the broad distribution here, but I wanted to let folks know 
that I'm going to be moving discussions on TURN over to the behave list 
(http://www.ietf.org/html.charters/behave-charter.html).   I'll be 
posting some issues shortly which require discussion, so if you are 
interested, please subscribe there.

Thanks,
Jonathan R.
--

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 16:56
Picon
Favicon

TURN issue #1: MAPPED-ADDRESS reunification

As I mentioned during the IETF meeting, I am working on a revision of 
STUN that structures the protocol into a "framework" layer (though we 
agreed not to call it that per se), and various "usages" that can define 
extensions, define what messages and attributes get used, and define 
various security considerations. The plan is for TURN to become a STUn 
usage rather than a separate protocol. I think this is a good thing, 
since TURN repeats a lot of stun, and its relationship with it is unclear.

One of the things I mentioned as a side benefit of this unification is 
that the TURN Allocate request could perform a stun check as a side 
effect. The Allocate response can include the source IP/port of the 
Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding 
Response). This way, an ICE endpoint, for example, can issue just a 
single Allocate request to a turn server, and get back its stun-derived 
AND turn-derived addresses in one operation. This will reduce the 
overhead of ICE and simplify things. There seemed to be good support for 
doing this when I proposed it in the meeting last month.

So, whats the issue? Syntax, unfortunately.

The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute 
always indicate the source IP/port as seen by the server in the request, 
and that it be usable with the existing STUN Binding Response and the 
TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, 
and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the 
address allocated by the TURN server itself.

So, there are several options:

1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 17:18
Picon
Favicon

TURN Issue #2: Digest for Allocate directly

Currently, TURN security relies on a one-time-password approach. The 
client connects to the TURN server over TLS, and asks for a one time 
username and password. This request is itself authenticated using digest 
-over-TLS (using the same username/password structures as SIP). Then, 
the actual allocate request itself is authenticated using this 
one-time-password. This approach is reasonably secure, and is not 
susceptible to the dictionary attacks that regular digest authentication 
is susceptible too.

The cost, however, is that TURN security is very complicated and 
expensive, processing wise. It will require many TCP/TLS connections to 
be established, and for them to see significant churn over time. I've 
also gotten some feedback that it makes TURN load balancing more 
complicated, since you would need to share these one time passwords 
between a load balancing element and the TURN server that does the 
actual allocations.

I'm increasingly worried these days that complicated security, even when 
good, won't be deployed if the costs are too high. And that will mean 
TURN without any security at all, which is really bad.

So, it has been suggested to me to allow the Allocate request itself to 
be authenticated using a Digest mechanism. The initial Allocate request 
is sent without credentials. Its rejected with a 401 that provides a 
nonce, and the request is retried with message-integrity that has an 
HMAC that includes the NONCE. (I'd likely do this by bringing in the 
digest authentication into the core stun protocol, and then allowing the 
TURN allocate to use it).

This would vastly simplify TURN security, and make it on par with most
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 17:24
Picon
Favicon

TURN Issue #3: TCP to UDP allocations

TURN currently provides TCP allocations and UDP allocations. You can 
open a TCP connection to the sevrer and get a TCP port, and you can open 
a "UDP connection" to the server and get a UDP port. However, you cannot 
open a TCP connection to the server and get a UDP port allocated. Such a 
capability would require the TURN server to apply framing (such as the 
AVT contrans spec) to push UDP contents over a TCP connection.

The benefit to this kind of approach is that it allows for partial UDP 
transport in situations where one side is behind a nasty symmetric nat 
or direwall (and thus must have tcp), whereas the other side has UDP 
connectivity. I've spoken to several people who have deployed voip 
configurations with this split UDP/TCP RTP transport, and claim it is 
better than all TCP.

I think this is a good idea and we should do it. There are three options 
here:

1. No, don't allow this.

2. Yes, allow this, but do it via an extension to TURN, rather than in 
the core spec.

3. Yes, allow it by adding some attributes to the core spec.

My proposal is option 2.

Comments?

-Jonathan R.
--

--
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 17:29
Picon
Favicon

TURN Issue #4: TLS TURN requests

TURN allows TLS connectivity for the Shared Secret request, but not for 
the Allocate request itself. I have gotten a request to allow the 
Allocate request to run over TLS. Once you've swallowed the RTP-over-TCP 
pill, I don't think this one is a big jump from there.

I'll note that there is currently no way in SDP that I know of to signal 
RTP over TLS; I seem to recall from meeting minutes last month in AVT 
this was discussed and rejected. That means that this mechanism would be 
useful with SIP only in conjunction with the TCP to UDP conversion I 
posted about in Issue #3. In essence, the proposal here is to allow TLS 
to UDP conversion as well.

I'd propose that the general transport of STUN requests (include those 
defined by usages) over TLS be defined in the core STUN spec. TLS is 
already there, but just for Shared Secret. One of the things I want to 
do in the stun revision (like what we did in sip) is separate the 
transport out so that TCP or TLS transport can be used for any request type.

Comments?

Thanks,
Jonathan R.
--

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
(Continue reading)

Permalink | Reply | 4 comments |
headers
Senthil Sivakumar (ssenthil | 5 Dec 2005 17:53
Picon
Favicon

Meeting minutes please..

Can someone please post the meeting minutes of the Vancouver meeting and
what was decided regarding the TCP draft, for the sake of people who
could not attend the meeting?

Senthil
Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 21:23
Picon
Favicon

TURN Issue #5: the STARTTLS problem

Right now, there is a single TCP port associated with TURN. 
Unfortunately, there are two distinct uses for TCP:

1. for issuing a Shared Secret request, in which case the message sent 
by the client after opening the connection will be a TLS ClientHello.

2. for obtaining TCP bindings, in which case the message sent by the 
client after opening the connection will be a STUN Binding Request.

If we allow binding requests over TCP/TLS, that adds another case.

This is not a new problem; many protocols have faced the challenge of 
muxing an application protocol and its TLS version together. There are 
only a finite set of solutions to it:

1. Different well-known ports for TCP/TLS and just TCP. This is in 
common usage today with HTTP (443 for HTTP over TCP/TLS and 80 for HTTP 
over TCP). This approach has the drawback of halving the number of ports 
that can be registered, and for this reason there has historically been 
pushback on it.

2. DNS NAPTR records to discover dynamic ports for the protocol versions 
over TLS/TCP and just TCP. SIP does this (RFC3263), though it also 
defines a pair of well-known ports (approach 1).

3. STARTTLS procedures. SMTP and HTTP both have procedures that define 
application layer messages that coordinate an upgrade to TLS.

4. Have the server figure out whether the first message is STUN or TLS, 
and direct it appropriately.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 21:33
Picon
Favicon

TURN Issue #6: port numbers

Right now, TURN has no default port. Its marked as XXXX in the spec. 
With the view that TURN would be a stun usage, its not clear that it 
needs a separate port from the STUN port. The only reason to have that 
is if folks think there is a desire from firewall admins to block TURN 
by disabling its port, but allow STUN. There are a few options here:

1. TURN will reuse the STUN default port. DNS procedures also exist to 
detect the udp, tcp, etc. ports for STUN/TURN, but they are always shared.

2. TURN has a separate default port. DNS procedures also exist to detect 
the udp, tcp, etc. ports for STUN, and there is also a procedure to 
detect them for TURN. This would be done by defining a separate NAPTR 
service for Allocate requests.

3. TURN will reuse the STUN default port. DNS procedures also exist to 
detect the udp, tcp, etc. ports for STUN, and there is also a procedure 
to detect them for TURN. This would be done by defining a separate NAPTR 
service for Allocate requests.

4. TURN has a separate default port, and there are no DNS procedures 
defined at all for STUN or TURN. This would imply a specific solution to 
the TLS problem in Issue #5 (in particular, would imply no DNS-based 
solutions). Why do this? The only reason is to force usage of TURN over 
a specific port since no discovery mechanism would exist. This would 
facilitate firewall port-blocking. Of course, its easily circumvented 
through configuration of the TURN port (which is what is done today), 
but its an option.

I tend to prefer #1 for simplicity. Unless there is a compelling 
argument brought about why the TURN and STUN requests NEED to run on
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 21:41
Picon
Favicon

TURN Issue #7: Forking interactions

The way TURN works right now, you can only have a single correspondent 
for media streams if you want to avoid the TURN encapsulations. This is 
because there can only be one active destination.

This has interesting interactions with forking. If a SIP INVITE forks, 
and you get back multiple 200 OK, each with a single media stream, the 
caller has to handle that. To avoid encapsulation, it would have to do 
an additional TURN allocation for each forked branch after the first, 
and issue a re-invite to modify the media destination to use that new 
allocated address. Also, after the first 200 OK, it cannot immediately 
issue a set active destination; it needs to wait a little bit to see if 
there are any more 200 OK coming.

There are a few options here:

1. change nothing; just document this use case in a section that talks 
specifically about SIP interactions

2. allow for multiple active destinations. This would be a sizeable 
change in the protocol, requiring that encapsulation always be used, and 
probably requiring a different encapsulation technique

Given how common multiple 200 OK is in practice right now (not much), 
this strikes me as a corner case for which a non-optimal solution is OK. 
As such, I would propose #1.

Thanks,
Jonathan R.
--

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 5 Dec 2005 21:50
Picon
Favicon

TURN Issue #8: Send Reliable or not?

Right now, the Send request is a reliable transaction. This is actually 
somewhat odd; the corresponding request from server to client, Data 
Indication, is not reliable. There is actually no reason why Send has to 
be reliable. I've gotten a proposal from an implementor to change Send 
to an unreliabel indication. The claim, which I can believe, is that it 
much simplified things. Any protocol riding about TURN that sends data 
(like STUn connectivity checks) has its own reliability mechanism 
anyway, making the mechanism redundant.

In and of itself, I think this is a good idea, but it would break 
backwards compatibility with any existing implementations. As such, I'd 
like some input prior to making any kind of change.

Thanks,
Jonathan R.
--

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
Permalink | Reply | 4 comments |

Gmane