Subject: [Ietf-behave] Re: I-D ACTION:draft-ietf-behave-turn-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 1 Mar 2006 19:59:19 -0800 (PST)

Here you have the new and much improved TURN specification.

The biggest change is that turn is now a 'stun usage', rather than being 
a separate protocol. It defines some new request types and attributes, 
but otherwise inherits is base processing from stun. It depends a lot on 
the revised stun draft, which will be out shortly, but you can probably 
follow turn without it if you are familiar with the previous stun draft.

Besides this change (which was a big one), there were many functional 
and other improvements. These include:

* Removed terms symmetric, port-restricted, etc. and use behave
terminology.
* Substantial movemenet of text between STUN and TURN. Much of what
was only in TURN is
now in the STUn draft, including digest authentication, the concept
of a magic cookie, ALTERNATE-SERVER and the 300 response. TURN
is now described as a usage of STUN, and
repeats nothing that is in the STUN specification. Previously, turn
repeated many concepts from stun,
* Change in handling of authentication. TURN previously said that the
credentials learned from the shared secret request last a long time,
over 30m, in contrast to stun where its 9m. Instead of working this
way, the allocate request itself is challenged using digest, and the
username/password is either the long-lived provisioned credential
between the client and server, or a short-term shared secret created
from a Shared Secret Request. This allows unification of the shared
secret mechanism, and also allows regular digest authentication to
apply to stun, without the shared secret request at all. While less
secure than the shared secret, it is as secure as basic SIP is, and
much more easily deployable. (most of this is in stun)
* Active destination section now includes an explicit state machine
which substnatially clarifies how this works, along with an
explanation of the race condition that the state machine is trying to
solve. Behavior between UDP and
TCP is now unified; the difference is handled through a timer setting
which is zero for TCP and three seconds for UDP. The value of the
timer is communicated to the client in the response. The mecahnism also
now allows the client to unset the active destination; this was
forbidden previously.
* Send is now an indication, not a request. Thus, it generates no
response. Message integrity and authentication services are not
provided for it (there is no point; sending unencapsulated data
provides the same function and that is never authenticated).
* Unified tcp and udp processing. Both now allow turn messaging after
the active destination is set. Previously, this was only allowed for
udp.
* Removed the 440 error case. Set Active destination is now allowed
for destinations that have not been contacted with a Send.
* Allocate requests, like all stun requests, can now include a
MAPPED-ADDRESS, which allows the client to obtain reflexive and
relayed addresses in one request. This is really, really nice with ICE.
* Added the ability to ask for a specific port parity (odd or even),
to request contiguous ports, or to request a specific port. Contiguous
port requests are more like hints that the client will ask for the
next higher port; they are not guaranteed.
* Added the ability to ask for a specific IP address. This is needed
with ice-tcp, for example
* Added the ability to ask for a specific transport protocol, so that
TURN can convert between UDP and TCP or vice a versa. Since TURN can
also do tls, this allows a client to connect to the turn server over
tls and request a udp port. Text mentions that, in this conversion,
packets may be lost if the throughput of the incoming packets (say,
over UDP) exceed the througput of the tcp connection towards the
client. No attempt is made to do traffic shaping; the server just
tries to the deliver the packets.
* Permissions for an allocation (which define when the server will
relay packets towards the client) are now set by both a Send
indication and a set active destination. Previously, it was just with
a send request.
* Previously, a send request that opened a tcp connection caused an
ephemeral port to be opened on the server. THis was done to avoid
simultaneous opens. Now, the server opens from the the allocated
transport address. This allows the client to request a simultaneous
open if desired. If one is not desired, the client can perform another
allocation on the same interface and open from there. This logic is in
ice-tcp now.
* Closures of tcp connections from external clients to the server no
longer clear the allocation. This used to be a consequence of the fact
that, for tcp, you couldn't change the active destination once
set. Now, you can.
* Allocation lifetimes are now refreshed only with allocate requests,
not data packets. THis was done to facilitate implementations where 
there is a separate data plane and turn signaling processing plane.

* Added a new request - Connect. This is used by the client to open a
tcp connectoin towards an external client. Previously, this was done
as a byproduct of Send. However, now that Send is an indication, it
genreates no response. As such, the client could not figure out
whether the connection setup succeeded. It needs to know this for
proper operation of ICE. As such, a separate Connect request is used,
and it genreates a success response when the connection succeeds. The
mechanism has somewhat of a hack in it to deal with the fact that a
tcp connection attempt may take longer than the stun transction
timeout.
* added a long overdue example

* small update to security considerations section, rewrite of overview
of operation
Thanks,
Jonathan R.
Internet-Drafts@xxxxxxxx wrote:

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           : Obtaining Relay Addresses from Simple Traversal of 
UDP Through NAT (STUN)
        Author(s)       : J. Rosenberg, et al.
        Filename        : draft-ietf-behave-turn-00.txt
        Pages           : 47
        Date            : 2006-3-1
        
   This specification defines a usage of the Simple Traversal of UDP
   Through NAT (STUN) Protocol for asking the STUN server to relay
   packets towards a client.  This usage is useful for elements behind
   NATs whose mapping behavior is address and port dependent.  The
   extension purposefully restricts the ways in which the relayed
   address can be used.  In particular, it prevents users from running
   well 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-00.txt
To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-behave-turn-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@xxxxxxxxx
In the body type:
        "FILE /internet-drafts/draft-ietf-behave-turn-00.txt".
        
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
------------------------------------------------------------------------

_______________________________________________
I-D-Announce mailing list
I-D-Announce@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/i-d-announce
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 11 Mar 2006 10:19:50 -0800 (PST)

One comment on this draft:

REQUESTED-IP in this draft and XOR-MAPPED-ADDRESS in RFC3489bis-03 share
the same definition (0x0020).

-- 
Marc Petit-Huguenin
Home: marc@xxxxxxxxxxxxxxxxxx
Work: marc@xxxxxxx

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Mar 2006 08:17:18 -0800 (PST)

Good catch. Changed REQUESTED-IP to 0x0022.

Thanks,
Jonathan R.
Marc Petit-Huguenin wrote: