Subject: [BEHAVE] draft-ietf-behave-turn-05

From: Philip Matthews <[email-masked]>
Date: Sat, 17 Nov 2007 12:39:44 -0500

I have just posted draft-ietf-behave-turn-05. A formal announcement  
notice should appear shortly.

As you may be aware, Rohan Mahy, Jonathan Rosenberg, Dan Wing, and I  
have been working hard on a revision of TURN since early September.  
We have made quite a few changes to the spec in order to address the  
comments received from the working group and others on the -04  
version. Originally, we were hoping to have a final version ready for  
working group last call by this time, but that has proven impossible.  
So we are publishing this draft aware that there are still some  
editorial changes to make, and perhaps one or two minor technical  
details to tweak. However, we would like to get feedback on all the  
changes we have made, with the hopes that we can rapidly make any  
fixes required and get a final version out for WGLC some time early  
next year.

I have copied section 15 from the draft below which lists the changes  
made since turn-04.

- Philip

15.  Changes since version -04

    This section lists the major changes between this document and
    draft-ietf-behave-turn-04:

    o  Removed the ability to allocate addresses for TCP relaying.  This
       is now covered in a separate document.  However, communication
       between the client and the server can still run over TCP or TLS/
       TCP.  This resulted in the removal of the Connect method and the
       TIMER-VAL and CONNECT-STAT attributes.

    o  Added the concept of channels.  All communication between the
       client and the server flows on a channel.  Channels are numbered
       0..65535.  Channel 0 is used for TURN messages, while the
       remaining channels are used for sending unencapsulated data to/
       from a remote peer.  This concept adds a new Channel Confirmation
       method and a new CHANNEL-NUMBER attribute.  The new attribute is
       also used in the Send and Data methods.

    o  The framing mechanism formally used just for stream-oriented
       transports is now also used for UDP, and the former Type and
       Reserved fields in the header have been replaced by a Channel
       Number field.  The length field is zero when running over UDP.

    o  TURN now runs on its own port, rather than using the STUN port.
       The use of channels requires this.

    o  Removed the SetActiveDestination concept.  This has been replaced
       by the concept of channels.

    o  Changed the allocation refresh mechanism.  The new mechanism uses
       a new Refresh method, rather than repeating the Allocation
       transaction.

    o  Changed the syntax of SRV requests for secure transport.  The new
       syntax is "_turns._tcp" rather than the old "_turn._tls".  This
       change mirrors the corresponding change in STUN SRV syntax.

    o  Renamed the old REMOTE-ADDRESS attribute to PEER-ADDRESS, and
       changed it to use the XOR-MAPPED-ADDRESS format.

    o  Changed the RELAY-ADDRESS attribute to use the XOR-MAPPED-ADDRESS
       format (instead of the MAPPED-ADDRESS format)).

    o  Renamed the 437 error code from "No Binding" to "Allocation
       Mismatch".

    o  Added a discussion of what happens if a client's public  
binding on
       its outermost NAT changes.

    o  The document now consistently uses the term "peer" as the name of
       a remote endpoint with which the client wishes to communicate.

    o  Rewrote much of the document to describe the new concepts.  At  
the
       same time, tried to make the presentation clearer and less
       repetitive.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 19 Nov 2007 15:20:35 -0800

Some comments and questions:

1. Section 3, 1st paragraph: "...is connected to a private network and
through one or more NATs to the public Internet.  On the public Internet..."

There is no such thing as a non-public Internet.

2. Section 5:  I think it would be better to integrate this whole
section in the Client/Server behavior, as one have to continuously read
back and forth between the client/server behavior sections and this section.

3. Section 6.1.2: Refresh Requests:  I see that the possibility of
moving an allocation to a different tuple was completely removed in this
draft (see paragraph 7 of section 6.1.2.1 of turn-04).  Why?

4. Section 6.1.2, 1st paragraph.  "Before 3/4 of the lifetime..."  I
never understood this 3/4 thing (I do not either understand a similar
rule for SIP registration).  Wouldn't it be more efficient to have the
rule saying "16 times the RTO if using UDP or 7900ms if using TCP before
the expiration of the lifetime timer..."

5. Section 6.2.1.1, 3rd paragraph: "... the server allocates a port..."

It cannot do this yet, as it has to first check the REQUESTED-IP and
REQUESTED-PORT-PROPS attributes.  More generally, I found turn-05 more
difficult to read (from a developer point of view) than turn-04, because
the text does not follow the flow of the code.

6. Section 6.2.1.4 paragraph 6: "Note that the LIFETIME attribute an
Allocate request..."  There is something missing in this sentence.

7. Section 6.2.1.4 paragraph 6:  There is no error code defined to
reject a LIFETIME attribute too short.

8. Section 7.1.1 paragraph 5 and 6: "...receives a ChannelConfirmation
Indication..."  Should be "Channel Confirmation indication"

9. Section 7.2.1: "When the server receives a Data indication..." should
be "...a Send indication"

10. Section 8.1: Is there a good reason to have two reserved bytes and a
length of 4 instead of no reserved bytes and a length of 2?

11. Sections 8.4, 8.6 and 8.9:  What is the reason to xor-encode the IP
address?

12. Section 10: 2nd paragraph: '...instead of just "stun".'  should be
'...instead of "stun".'

Thanks.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 19 Nov 2007 22:04:20 -0800

> draft (see paragraph 7 of section 6.1.2.1 of turn-04).  Why?

The design team was concerned that if we include a partial mobility  
feature, that other mobility requirements would creep in. Mobility  
was not an original feature of the protocol.  It is certainly  
something that could be added later if it proves useful and we have  
consensus on those requirements.

> the expiration of the lifetime timer..."

The LIFETIME is related to the lifetime of the allocation, which has  
a recommended default of 10 minutes.  After 3/4 of this time (7.5  
*minutes*) the client is expected to refresh its allocation.

This is completely orthogonal and unrelated to the amount of time a  
client waits after sending a keepalive before determining that a flow  
is dead (16x RTO for UDP); and it is also different from the amount  
of time before a permission times out (typically about 30 seconds for  
UDP allocations).

> the text does not follow the flow of the code.

good catch.  if you could point out other places where the order is  
different please let me know.

> length of 4 instead of no reserved bytes and a length of 2?

To make the framing the same for all transports, and to insure we are  
always aligned on a double word boundary.

> 11. Sections 8.4, 8.6 and 8.9:  What is the reason to xor-encode  

To prevent it from being rewritten by a NAT with a "generic ALG".

thanks,
-rohan

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 19 Nov 2007 22:58:10 -0800

Hi Rohan,

Thanks for your answers.  More comments below.

Rohan Mahy wrote:
> feature, that other mobility requirements would creep in. Mobility was
> not an original feature of the protocol.  It is certainly something that
> could be added later if it proves useful and we have consensus on those
> requirements.

Fair enough.

> The LIFETIME is related to the lifetime of the allocation, which has a
> recommended default of 10 minutes.  After 3/4 of this time (7.5
> client waits after sending a keepalive before determining that a flow is
> dead (16x RTO for UDP); and it is also different from the amount of time
> before a permission times out (typically about 30 seconds for UDP
> allocations).

I understand this.  What I do not understand is the choice for the value
3/4.  In the worst case (all UDP packets lost excepted for the last
one), a Refresh request will be received by the server 63 * RTO
milliseconds after the beginning of the transaction.  If the last
retransmission is not received, the allocation will expire and it does
not matter if the transaction began (1/4 * lifetime) or (lifetime - 64 *
RTO) before the expiration.  So why do not use (lifetime - 64 * RTO)
instead?

> different please let me know.

OK, I finished my server implementation and I am currently working on
the client side, so I'll send a more complete review after this.

> always aligned on a double word boundary.

OK, but with length=2, the padding algorithm still align on a double
word boundary.  Not that it really matters, I am just curious about how
the choice is made between reserved bits and padding.

> To prevent it from being rewritten by a NAT with a "generic ALG".

How a generic ALG can rewrite an IP address assigned to the TURN server?
 And if a NAT can do this, then why do not also xor-encode
ALTERNATE-SERVER in rfc3489bis?

Thanks.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 21 Nov 2007 09:06:19 -0500

On 20-Nov-07, at 01:58 , Marc Petit-Huguenin wrote:

>> was

The design team is very interested in trying to get the portion of  
TURN that people want today done ASAP. For that reason, we split UDP  
and TCP allocations (because we felt that the demand today is for UDP  
allocations, not TCP allocations) and that is also the reason we  
pulled the mobility feature (we didn't see anyone wanting to use it  
today).

We debated both of these actions, and the decision on both was taken  
late in the game, but we feel we have made the right decision.  
Basically, we don't want the base TURN spec held up over anything  
that people don't want right now.

If we are wrong in our assessment of what is really important now,  
please let us know.

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 27 Nov 2007 11:04:14 -0800

Continued...

13. Section 6.1.1 paragraph 5:  "The client MUST include a
REQUESTED-TRANSPORT attribute."

This is inconsistent with section 6.2.1.1 paragraph 3 that says that
"[i]f the request did not contain a REQUESTED-TRANSPORT attribute..."

14.  Section 6.1.1 paragraph 6:  "As an example, the Real Time Transport
Protocol (RTP) [rfc3550]..."  should be "...the Real-time Transport
Protocol..."

15.  Section 6.1.1 paragraph 6:  "...the Real Time Transport Protocol
(RTP) [RFC3550] requires that RTP and RTCP ports be an adjacent pair..."

should be "...(RTP) [RFC3550] recommends that RTP and RTCP ports..."

16.  Section 6.2.1.1 paragraph 3:  "If the request did not contain a
REQUESTED-TRANSPORT attribute, the server MUST use the same transport
protocol as the request arrived on."

Without the turn-tcp extension, if the request arrived on a TCP or TLS
transport protocol without a REQUESTED-TRANSPORT, the server must reject
the request with a 442.

17.  Section 6.2.1.3 paragraph 3.  This paragraph does not explain how
to allocate the port that was reserved by a previous allocation.  This
is explained in section 8.7 but the text should add that the allocation
of the reserved port must be done with the same tuple and same
username/realm/password that was used to reserve it.

18.  Section 6.2.1.4 paragraph 6:  "Note that the LIFETIME attribute an
Allocate request can be zero, though this is effectively a no-op."

Why authorizing this, if it effectively does nothing?  See also my
comment #7 below.

19. Section 6.2.2 paragraph 2:  "First, the request MUST be
authenticated using the same shared secret as the one associated with
the allocation."

What happen if the user password is changed during an allocation?

20. Section 6.2.2

There is no explanation on what can be done after an allocation expires.
 Is it possible to create a new one?  With the same username/realm/password?

21.  Section 7.2.3 paragraph 2.  I suggest to move this paragraph just
after the first paragraph of section 7.2.2

22.  Section 8.9 1st paragraph:  "...so as to be able to allocate more
than 64k transport addresses." should be "...more than 63k transport
addresses."

23.  Section 10.  I suggest to add NAPTR (ala RFC 3263) processing to
choose the preferred transport for a domain if it does not matter for
the client.

24.  Section 15 paragraph 12:  I cannot find this discussion in the
document.

Thanks.