Subject: RE: [MMUSIC] Status of TURN

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 9 Oct 2003 11:08:58 -0500

The Transport Area Directors understand that this document will proceed as
an individual submission, outside the context of any of the working groups
in the Transport Area. It is clearly of interest to a number of these
working groups.

I gather that at least one more revision needs to be undertaken before this
document will be considered for publication as an RFC, but we're very
interested to see it go forward.

Jon Peterson
NeuStar, Inc.
(co-AD for Transport)

> -----Original Message-----
> From: Joel Tran [mailto:[email-masked]]
> Sent: Tuesday, October 07, 2003 11:08 AM
> To: Jonathan Rosenberg; Mmusic
> Subject: [MMUSIC] Status of TURN
> 
> 
> Hi Jonathan,
> 
> I would like to ask you two little questions concerning TURN.
> 
> First, I would like to know what is the exact status of TURN? 
> Will it be
> adopted as a Workgroup item of MMUSIC since TURN is refeered 
> in various
> documents?
> 
> Second, I would like to ask you if there is a reason why the 
> lastest version
> of the draft is not on the IETF web and only available throught
> http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt?
> 
> Thanks,
> ...J
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Oct 2003 12:44:05 -0400

Thanks for the clarification, Jon.

To answer Joel's second question - there were some mixups during the 
submission process last time, and the -02 never got into the archives. 
I've just resubmitted it so it should be there shortly.

I am also hoping to get in a real revision (resulting in a -03 
version) before the deadline. Please, if you have comments or 
questions, forward them to me.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Joel Tran" <[email-masked]>
Date: Tue, 14 Oct 2003 15:07:28 -0400

Thanks for your answers concerning TURN.

...J

Here are few comments and questions regarding TURN after my first reading. 

I would also like to suggest to put the section 9 concerning the "Protocol
Details" before the section 7 concerning the "Server Behavior". In the
section 7 & 8, some protocol specific messages are being used with prior
introduction on the TURN messages/protocol. It is thus difficult to read the
document. With a proper introduction on the messages of the protocol, the
document will be easier to read.

[PAGE 3]   
   A complete solution requires a means by which a client can obtain a
   transport address from which it can receive media from any peer which
   can send packets to the public Internet. This can only be
   accomplished by relaying data though a server that resides on the
   public Internet. This specification describes Traversal Using Relay
   NAT (TURN), a protocol that allows a client to obtain IP addresses
   and ports from such a relay.

Joel : Not true. A relay server can reside in a private network (i.e. full
media proxy server/by setting a virtual server provided by NAT routers).

[Page 5]
      TURN Client: A TURN client (also just referred to as a client) is
      an entity that generates TURN requests. A TURN client can be an
      end system, such as a Session Initiation Protocol (SIP) [6] User
      Agent, or can be a network element, such as a Back-to-Back User
      Agent (B2BUA) SIP server. The TURN protocol will provide the STUN
                                                                   ^^^^
      client with IP addresses that route to it from the public
      Internet.
Joel : Did you mean TURN clien or really STUN client? TURN and STUN
request/protocol are not the same and thus can not respond to it.

[Page 6]
   When a client is behind a NAT, transport addresses obtained from the
   local operating system will not be publically routable, and
   therefore, not useful in these protocols. TURN allows a client to
   obtain a transport address, from a server on the public Internet,
   which can be used in protocols meeting the above criteria. However,
   the transport addresses obtained from TURN servers are not generally
                                                              ^^^^^^^^^
   useful for receiving data from anywhere.
Joel : It is ambigious to say generally. This implies that TURN purpose is
not ment to receive data from anywhere but can be used to receive data from
anywhere.

[Page 7]
   A TURN client first discovers the address of a TURN server. This can
   be preconfigured, or it can be discovered using SRV records [3] This
                                                                  ^^
   will allow for different TURN servers for UDP and TCP.
Joel : . Missing!
Joel : Phrase unclear : This will allow for different TURN servers for UDP
and TCP. Should it be something like : This will allow the use of different
TURN server for UDP and TCP.

[Page 8]

   transport address, PA, in the TURN response. The TURN server is
   responsible for guaranteeing that packets sent to PA route to the
   TURN server.
Joel : The PA is the TURN Server. How can you send data from PA to the TURN
Server? Should this phase be something like :  The TURN Server is then
responsible for guaranteeing that packets sent to PA route get to SA.

   TURN also allows a client to request an odd or even port when one is
   allocated, and for it to pre-allocate the next higher port. This is
   useful for securing consecutive ports for usage with the Real Time
   Transport Protocol (RTP) [5].
Joel : The phrase is unclear, the two cases should be separated to make it
clear: First, request for an odd or event port at the allocation time.
Second, Request for a subsequent pre-allocated port.

[Section 7.1]
Joel: It will proabaly ease the reading of this section if you list and
describe all the ERROR-CODE in a table. Furthermore, you can probably do a
use case diagram to ease the reading of this section.

[Page 11]
   The server proceeds to authorize the client. The means for
   authorization are outside the scope of this specification. It is
   anticipated that TURN servers will be run by providers that also
   provide an application service, such as SIP or RTSP. In that case, a
   user would be authorized to use TURN if they are authorized to use
   the application service.
Joel: You should point to the document which solves the issue concerning the
authorization.

[Page 12]
   the case in TURN. In TURN, the server MUST store the allocated
   username and password for a duration of at least 30 minutes. Once an
   Allocate request has been authenticated using that username and
   password, if the result was an Allocate Error Response, the username
   and password are discarded. If the result was an Allocate Response,
   resulting in the creation of a new binding, the username and password
   become associated with that binding. They can only be used to
   authenticate Allocate requests sent from the same source transport
   address in order to refresh or de-allocate that binding. Once the
   binding is deleted, the username and password are discarded.

Joel: How long should the binding in TURN last last? When does the binding
expires? This paragraph is concerning Share secret. It should not include
elements on Allocate Request. This could be move to the next section.

   Allocate requests are used to obtain an IP address and port that the
   client can use to receive UDP and TCP packets from any host on the
   network, even when the client is behind a symmetric NAT. To do this,
   a TURN server allocates a local transport address, and passes it to
   the client in an Allocate Response. When the server receives packets
   on this allocated address, it acts as a relay, and forwards them
   towards the source of the Allocate request. The server remembers the
   source transport address where that packet came from, and "locks
   down". This means that packets sent from the client to the TURN
   server are forwarded to that address.
Joel: "Locks down" what? The phrase is unclear. Locks down the transport
address from the source packet.

[Page 13]
   provided by the server. Typically, this will be XXXX, the default
   TURN port. [[OPEN ISSUE: Can we just use the STUN port?]].
Joel: I wonder if there is some security issue if we use the same port as
STUN. For example, how do we treat purely STUN user without authentication?
How STUN and TURN server can interoperate if they are not merge into a
single daemon?

   The server MUST check the Allocate Request for a MESSAGE-INTEGRITY
   attribute. If not present, the server generates a Allocate Error
   Response with an ERROR-CODE attribute with response code 401.
Joel: Another table combined with a use case will ease the reading of this
section.

[Page 14]
   determines whether or not it has sufficient capacity to handle a
   binding that will generate the requested bandwidth. If so, the server
   looks for the presence of the TRANSPORT-PREFERENCES attribute in the
   request. If the attribute indicates that an even port is requested,
   the server attempts to allocate a transport address with an even
   port. If the attribute indicates that an odd port is requested, the
   server attempts to allocate a transport address with an odd port. If
   the attribute indicates that there is no preference for port parity,
   or if the TRANSPORT-PREFERENCES attribute was absent, the server
   attempts to allocate a port with either parity. The server MUST NOT
   allocate ports from the well-known port range (0-1023) and MUST NOT
   allocate ports from the user registered port range (1024 through
   49151).
Joel : You should introduce the two elements TURN are looking for at first
and then describing them to ease the reading. 

[Page 15]

   Request (TCP or UDP), the source IP address and port of the allocate
   five-tuple are set to the source IP address and port in the Allocate
   Request, and the destination IP address and port of the allocate
   five-tuple are set to the destination IP address and port in the
   Allocate Request). The protocol in the remote five-tuple is set to
   the protocol from the Allocate Request. The source IP address of the
   remote five-tuple is set to the interface from which the base port
   was allocated. The source port of the remote five-tuple is set to the
   base port. If the binding was allocated for TCP, the connection on
   which the Allocate request was received is associated with the
   allocate five-tuple in the binding.

   The server MUST remember the one-time username and password used to
   obtain the binding.

Joel: You should probably mention that in the remote tuples, the remote
transport address is left blank.

Joel : A little suggestion, at the creation of the request message, a 3 way
binding should be created with the one-time username/password, the allocate
and remote five-tuples. When a packet is received at the transport address,
the binding is changed to only the two five-tuples.

Joel: There is no case threating the case were, in the two five-tuples, the
protocol of the remote five-tuples does not match the protocol of the
allocate five-tuples. For example, what happen when TCP is used in
combination with UDP? Personally, I think an error should occur since it is
not the purpose of TURN to make such things as UDP over TCP or TCP over UDP.

[Page 16]

   The server MUST add a BANDWIDTH attribute to the Allocate Response.
   This MUST be equal to the attribute from the request, if one was
   present. Otherwise, it indicates a per-binding cap that the server is
   placing on the bandwidth usage on each binding. Such caps are needed
   to prevent against denial-of-service attacks (See Section 10.
Joel: Closing ) mising.

[Page 17]
   present, the server checks that this address and port has been
   pre-allocated by a previous Allocate Request. The only user
   authorized to allocate a pre-allocated address is the same one that
   generated the pre-allocation. Note that the one-time usernames for
   both requests (the pre-allocation and the final allocation) will be
   different. However, both MUST have been obtained through Shared
   Secret Requests authenticated as being sent from the same user.
Joel: Which error code is sent if the pre-allocated is not generated by the
user who generated the pre-allocation?

   Once a binding has been created, packets received from the client are
   generally forwarded to the remote client. However, if the binding is
   UDP, the client can send subsequent Allocate requests to the TURN
   server. To determine which packets are for the TURN server, and which
   need to be relayed, the server looks at the packet. If the packet is
   shorter than 28 bytes, it is not a TURN request. If it is longer than
   28 bytes, the server checks bytes 25-28. If these bytes are equal to
   the MAGIC-COOKIE, the request is a TURN request. Otherwise, it is a
   data packet, and is to be relayed.
Joel : Why between 25-28? This can be problematic in the future if some
extension is added to a TURN messages. I'm not familliar with Ipv6 but is
there some issues with IPv6 adress releam? I understand that this is within
the mecanism to determine which packet are TURN packet and which packet are
relaying packet.

All comments are welcome!

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de
Jonathan Rosenberg
Envoyé : 9 octobre, 2003 12:44
À : Peterson, Jon
Cc : 'Joel Tran'; Mmusic
Objet : Re: [MMUSIC] Status of TURN

Thanks,
Jonathan R.

Peterson, Jon wrote:

> The Transport Area Directors understand that this document will 
> proceed as an individual submission, outside the context of any of the 
> working groups in the Transport Area. It is clearly of interest to a 
> number of these working groups.
> 
> I gather that at least one more revision needs to be undertaken before 
> this document will be considered for publication as an RFC, but we're 
> very interested to see it go forward.
> 
> Jon Peterson
> NeuStar, Inc.
> (co-AD for Transport)
> 
>

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 15 Oct 2003 13:47:09 +0100

Dear Jon,

I'm very surprised to see that TURN is being encouraged to be put forward as
an individual submission.  We believe that TURN has major security flaws, is
incomplete, and there are better ways of achieving Symmetric NAT traversal.
Suggesting it should become an RFC without debate and full consideration
would be wrong.

If you remember, TURN was just one of the candidates put forward as a
pre-Midcom solution that at that time was put aside in favour of developing
a consensus protocol.   Despite our commitment, consensus wasn't reached,
mainly due to the amount of effort that was being put into SIP (RFC3261) by
other important stake holders.

We feel that to arbitrarily promote TURN at this time is short cutting the
consensus making process.  Surely, if there is sufficient interest in a
standard of this nature, the correct way forward is to assign it as a work
item in a suitable group and re-start the consensus process. If so, we
remain willing to help with time, resource and considerable technical
know-how. Several significant developments have meant the world of Symmetric
NAT traversal has advanced considerably since the pre-Midcom days.

Regards,

Pete.

=============================================
Pete Cordell
Ridgeway
=============================================

----- Original Message -----
From: "Peterson, Jon" <[email-masked]>
To: "'Joel Tran'" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>; "Mmusic" <[email-masked]>
Sent: 09 October 2003 17:08
Subject: RE: [MMUSIC] Status of TURN

> I gather that at least one more revision needs to be undertaken before
this

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Oct 2003 21:16:34 -0400

Just because its an individual submission does not mean that comments 
and criticisms are not welcome. Please feel free to send me a note.

Thanks,
Jonathan R.

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 20 Oct 2003 15:01:05 +0100

Hi Jonathan,

That's generous of you, but I basically feel that there is either a need for
this work, in which case it should be done as part of the normal open IETF
process, or there isn't a need, in which case it should go no further.

As I've said elsewhere, I think the reason the effort failed last time was
because people were working on the SIP RFC.  I know you're superhuman (I am
impressed by your output), but I think even you were saturated at that time.
And I actually agree with your prioritisation at the time (there's no point
in having a traversal solution if there is nothing that needs traversing!)

However, to put it bluntly, I would feel aggrieved if those circumstances
were later used to justify fast tracking a proposal that did not represent
consensus of the interested parties involved.

Pete.

+44 1473 635863

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: "Peterson, Jon" <[email-masked]>; "Mmusic" <[email-masked]>;
<[email-masked]>
Sent: 17 October 2003 02:16
Subject: [midcom] Re: [MMUSIC] Status of TURN

> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 20 Oct 2003 16:47:12 +0100

Melinda,

I would argue that individual submissions are part of the IETF process, but
are not necessarily open.  If we and Jonathan were to evolve TURN (or
something similar) outside of a working group item, that would effectively
be a behind closed doors effort, and would not be open in the sense that
most IETF working group work is.

Publishing TURN as an individual submission would also set a bad precedent.
There's been a significant boom in the number of traversal solution
providers lately.  Publishing TURN would set the precedent that it is OK to
bypass the open process (at least in the traversal space) and use the
individual submission process to get that attractive RFC number (marketing
people and buyers don't really care what type it is).  True, the individual
process requires a lot of patience.  However, the open process requires a
thick skin, a willingness to compromise, re-writing code, possibly delayed
launch dates and ... a lot of patience!

Pete.

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Peterson, Jon"
<[email-masked]>; "Mmusic" <[email-masked]>; <[email-masked]>
Sent: 20 October 2003 15:27
Subject: Re: [midcom] Re: [MMUSIC] Status of TURN

> On Monday, October 20, 2003, at 10:01 AM, Pete Cordell wrote:
> I hope it's understood that the publication of individual
> submissions (i.e. not working group output) is in fact part of
> the normal open IETF process, available to anybody who wishes
> to jump through the various hoops to do it.  RFC 2026 mentions
> it but probably doesn't make it as clear as it should.
>
> Melinda
>
>

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 20 Oct 2003 18:13:02 +0100

I agree that the process allows this.  However, I believe it would be unwise
to take this route.

The IESG can recommend that a draft not be published if (among other
reasons) it conflicts with work in the IETF.

The effort was stopped because people were too busy doing other things,
rather than it was not possible to reach consensus, hence it is not a failed
effort in that sense.  Now that people have more time, it seems that there
is still interest in it from more than one group.  Hence the correct thing
to do is see whether the work should be resumed.  (If you like, the work
should have been considered paused rather than stopped.)

It seems an act of considerable bad faith to stop a piece of work going
forward because you are busy, and then later claim that your individual
submission should be adopted because the work was stopped.

There seems only two options: the work item is re-started, or all work is
stopped.  To do otherwise would be an abuse of the spirit of the IETF even
if it is not in violation of the written rules.

Pete.

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Peterson, Jon"
<[email-masked]>; "Mmusic" <[email-masked]>; <[email-masked]>
Sent: 20 October 2003 17:11
Subject: Re: [midcom] Re: [MMUSIC] Status of TURN

> On Monday, October 20, 2003, at 11:47 AM, Pete Cordell wrote:
> That's one way to look at it, I suppose, but the point really
> is that publication of individual submissions is a route open
> to anybody and that there's no process subversion here.  Note
> as well that it's being published in draft form and he's
> solicited input.
>
> I'm actually not very happy about this, myself, and would
> oppose pretty much any relaying technology.  Aside from the
> technical issues, among the unfortunate consequences of all
> this pre-midcom stuff has been that it's taken the pressure
> off of firewall/NAT vendors to do something useful.  That's
> not good.  But regardless of how I feel personally about all
> this stuff I really think that advancing an individual draft
> towards publication is not even remotely an abuse of IETF
> process.
>
> Melinda
>
>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 20 Oct 2003 10:27:25 -0400

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Mon, 20 Oct 2003 12:11:15 -0400

Melinda