updated TURN draft

Folks,

I did an update to the turn spec. I goofed on the I-D boilerplate, so 
there is a good chance it won't make it into the repository, in which 
case I'll submit right after ietf. Either way, you can pick up the 
update draft here:

http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-08.txt

There are many changes from the previous version, addressing most of the 
comments and concerns I have received privately and on the list. The 
comment on the list I did not resolve yet is how the server can 
differentiate TLS vs. regular TCP connections, the former used for 
shared secret requests, the latter for allocate.

Here are the changes:

* removed some remaining vestiges of lock-down discussion, including
the 439 response code

* defined numeric value for REALM - 0x0015, and defiend its grammar

* fixed some typos where "Binding Requests" should have said "Allocate
Requests"

* changed name of SOURCE-ADDRESS to REMOTE-ADDRESS. Though this had
the same name as a STUN attribute, it has a very different
semantic. To avoid confusion, I renamed it. It still has the same
attribute code as before, 0x0012.

* forwarding of UDP packets from outside to inside (and TCP
connections) is based on just the IP address matching a previous SEND
destination, not the IP address and port. This therefore emulates an
address-restricted cone nat.

* separated sending of packets from setting the active
destination. The latter is now done through a separate request. This
makes it easier to work with ICE. You let the whole ICE sequence
complete, and when a final address/port are selected, you set that to
active.

* There was previously a race condition. When non-TURN packets
received by the client after a Send Request, the client couldn't tell
whether those were from the previous destination or the new one. This
has been resolved by having the server send all packets after a Set
Active Destination Request using data indications, until three seconds
have elapsed.

* TCP works now. It really didn't work properly before. The problem
was that there was no framing defined for muxing normal data and TURN
on the same connection. There was also no way to have multiple
connections at the same time; once one was created to the server, all
others were rejected. This opens up TURN to major dos attacks. There
was also no way for a server to initiate a connection, which is going
to be essential for ICE operation (though this is not in the current
ICE draft). This is all fixed now. With TCP, the muxing problem is
solved by disallowing it. Once a connection is activated with a Set
Active Destination command, no other TURN messaging is allowed. Turns
out, none is needed. A client can issue a SEND request over TCP, which
will cause a new connection to be opened if needed. The server will
accept a connection from a peer if the client had previously tried to
open a connection TO it, mirroring the UDP rules. Effectively, TURN
uses simultaneous opens in either direction to establish permissions
for one of the two to succeed.

* clarified that the allocate request is sent to the same server as
shared secret requests, but from a different local ephemeral port.

* port range allocations aligned with behave, but more restrictive -
the turn server uses the full range only the client did

* added 441 response code to deal with the case where the client
supplied a valid username and password in a refresh Allocate (or Send
or Set Active Destination), but it was a different username than the
one used to allocate the binding

* added MESSAGE-INTEGRITY to Send Requests, Set Active Destination
requests, and their corresponding responses. However, it is not there
for DATA-INDICATION (I dont think its needed). At the moment, its not
there for the error responses (its not in the error responses for
rfc3489 either). This may be a bug; faked, unauthenticated error
responses could be used to cease transmissions of the request and thus
prevent a client from receiving the actual response.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email protected]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com