Subject: Re: [BEHAVE] TURN major issues and proposed fixes

From: Philip Matthews <[email-masked]>
Date: Thu, 15 Feb 2007 17:39:56 -0500

Why not have allocation behavior correspond to the way NATs typically  
work?
That is traffic sent in the "outbound" direction refresh the  
permission for that
destination, and also refresh the corresponding allocation. However,  
it does
not refresh any other permissions.

Other things sounds ok.

For TCP, I prefer option A.

- Philip

On 19-Jan-07, at 23:02 , Rohan Mahy wrote:

> Hi Folks,
>
> The following issues have all come up from implementors of TURN and
> are big enough issues that I wanted to get some list feedback before
> incorporating these in a new rev.
>
> 1. Allocations, Bindings, Permissions, Timeouts, and the Active  
> Destination.
>
> The current text is still a bit fuzzy and inconsistent about what is a
> difference between permission and a binding and what keeps bindings
> open. Also, many implementors have expressed confusion between the
> behavior of an ordinary NAT binding and a "STUN Relay binding", so I
> am proposing we skip the binding terminology in favor of "permission".
> Much of the following came from consensus at one of the meetings. I've
> come up with the following proposal which fills out a consistent set
> of rules:
> - Remove the terminology "binding" altogether inside the TURN server.
> Only use "binding" when talking about a "real" NAT (ex: between the
> TURN client and the TURN server)
> - All requests and indications except for initial Allocation requests
> are sent in the context of a matching valid allocation, otherwise they
> are rejected (requests) or discarded silently (Indications).
> - Allocations are explicitly refreshed via subsequent allocation
> requests.  Allocation timeout values are on the order of minutes. Send
> and Data indications do not refresh Allocations. Allocation timers are
> based on the LIFETIME attribute.
> - Each allocation can have zero or more permissions
> - When allocations are destroyed all related permissions are deleted.
> - Permissions are only created by Send Indications over UDP and
> Connect Requests over TCP.
> - Data sent to a peer (via send Indications and unencapsulated data
> sent to the active destination) by the TURN client refresh the
> relevant permission. Data to one permission does not refresh other
> permissions associated with the same binding.
> - The expected timeout interval for all permissions for an allocation
> is conveyed from the server to the client using the REFRESH-INTERVAL
> attribute in an initial successful Allocate Response.
> - The active destination is changed only with the Set Active
> Destination Request for an allocation. The active destination is
> completely independent of any permissions.
>
> 2. SetActiveDestination should not be limited to existing permissions
> Current text in some places says that the active destination needs to
> be an existing permission. This is actually unnecessary however, and
> loosening this restriction is useful.
> Take the case where the TURN client receives a SIP INVITE with an
> offer, and the TURN client wishes to accept the offer. The TURN client
> should be able to set the active destination immediately before
> issuing its first Send request (to this destination). Using this order
> of operations insures that the TURN client receives all data traffic
> unencapsulated. This provides for more consistent bandwidth usage in
> this case.
>
> The proposal is to change the current text to completely decouple the
> active destination from any permissions.  A permission controls
> whether traffic flows.  The active destination controls whether
> traffic flowing over a binding is encapsulated of not.
>
> An alternative to this proposal is to create a new permission if no
> permission for the active destination exists.  The problem is that
> this does not result in sending any data to the peer (as described in
> the applicability statement and UNSAF considerations), it is
> completely implicit behavior, and the opposite operation (clearing the
> active destination) does not delete permissions.
>
> 3. SetActiveDestination changing destinations
>
> Currently there are several pages of text devoted to a timer based
> state machine that needs to be implemented on both the server and the
> client to handle the case of switching the active destination from one
> address to another. The problem is that  over UDP, the client cannot
> tell which unencapsulated data is from the old active destination vs.
> the new active destination.
>
> However, requiring timers and a state machine on the server is a
> significant implementation burden which provides no benefit for the
> TURN server or its administrative domain.
>
> The proposal is to put this problem completely into the hands of the
> client.  Some clients may never wish to change the active destination
> for example and will have no need to implement anything special.
> Those clients that want to change the active destination over UDP are
> required to clear the active destination, wait for an appropriate
> interval (5 seconds is suggested), then set the active destination to
> the new address.
>
> Specific proposed text for items 2 and 3 and also delete the TIMER-VAL
> attribute:
>
> <section title="Set Active Destination Request">
> <section title="Client Behavior">
> <t>
> The Set Active Destination address allows the client to create an
> optimized relay function between it and the server. When the server
> receives packets from a particular preferred external client, the
> server will forward those packets towards the client without
> encapsulating them in a Data Indication. Similarly, the client can
> send non-STUN packets to the server without encapsulation, and these
> are forwarded to the external client. Sending and receiving data in
> unencapsulated form is critical for efficiency purposes. One of the
> primary use cases for the STUN relay usage is in support of Voice over
> IP (VoIP), which uses very small UDP packets to begin with. The extra
> overhead of an additional layer of encapsulation is considered
> unacceptable.
> </t><t>
> The Set Active Destination request is used by the client to provide
> the identity of this preferred external client. The Set Active
> Destination address MAY contain a REMOTE-ADDRESS attribute. This
> attribute, when present, provides the address of the preferred
> external client to the server. When absent, it clears the value of the
> preferred external client. This address has no effect on the existence
> of any permissions.
> </t><t>
> The client MUST NOT send a Set Active Destination request with a
> REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an
> active destination is already set for that allocation. If the client
> wishes to set a new active destination, it MUST wait until 5 seconds
> after a successful response is received to a Set Destination Request
> removing the active destination. Failure to wait could cause the
> client to receive and attribute late data forwarded by the STUN relay
> server to the wrong peer.
> </t><t>
> <list><t>Consider the case where the active destination is set, and
> the server is relaying packets towards the client. The client knows
> the IP address and port where the packets came from - the current
> value of the active destination. The client issues a Set Active
> Destination Request to change the active destination, and receives a
> response. A moment later, a data packet is received, not encapsulated
> in a STUN Data Indication. What is the source if this packet? Is it
> the active destination that existed prior to the Set Active
> Destination request, or the one after? If the transport between the
> client and the STUN server is not reliable, there is no way to
> know.</t></list>
> </t>
> </section>
>
> <section title="Server Behavior">
> <t>
> The Set Active Destination Request is used by a client to set the
> forwarding destination of all data that is not encapsulated in STUN
> Send Indications. In addition, when a matching permission is present,
> all data received from that external client will be forwarded to the
> STUN client without being encapsulated in a Data Indication. This
> request does not modify any permissions.
> </t><t>
> The request MUST be authenticated using the same shared secret as the
> one associated with the allocation, or be authenticated using a short
> term password derived from that shared secret. If the request was
> authenticated but not with such a matching credential, the server MUST
> generate an error response with a 441 response code.
> </t><t>
> If the Set Active Destination request does not contain a
> REMOTE-ADDRESS attribute, the value of the active destination is
> cleared. If the Set Active Destination request contains a
> REMOTE-ADDRESS attribute, and the active destination is not set, the
> active destination is set to that IP address and port. If an active
> destination is already set, and the request was received over a
> reliable transport, the active destination is changed to the new
> value.  If the active destination is already set and the request was
> received over UDP, the Set Active Destination request is rejected with
> a 439 Active Destination Already Set error response.  This prevents
> the race condition described in the previous section.
> </t>
> </section>
> </section>
>
> 4. Opening TCP permissions
>
> Currently TCP to TCP traffic between TURN servers requires the TURN
> servers to implement simultaneous open.
>
> SYN ->
> <- SYN
> SYN-ACK ->
> <- ACK
>
> Option A is to leave this as is and to clarify this non-obvious
> implication to implementors (you cannot receive an incoming connection
> unless you first try to open one with the Connect request.  Option B
> is to include an explicit Open Permission Request to create a specific
> permission for the TURN server to receive a TCP SYN from one specific
> IP address and port number.
>
> I will implement Option A unless there is strong desire on the list to
> do something else.
>
> thanks,
> -rohan
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave

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

---

From: Brian Hibbard <[email-masked]>
Date: Fri, 16 Feb 2007 16:38:59 -0600

Hello Rohan,

My sincere apologies for not posting earlier.  Comments are inline.

> TURN client and the TURN server)

That will be nice.

> completely independent of any permissions.

I like the idea that a TURN client explicitly refreshes its  
allocation.    Since it ought to be a lot more work to provide an  
allocation than a permission, I think it is right to give allocations  
a lifetime that is distinct from the permissions.  Is the purpose of  
the permission timers to avert the proliferation of permissions for  
an allocation?  Is it worthwhile for the TURN server to bother  
maintaining permission timers for some other reason?  The client can  
always send packets to refresh NAT bindings without the TURN server  
having to maintain state.

> active destination) does not delete permissions.

If it's OK for Set Active Destination to create a new permission  
implicitly without sending data, it would make sense to have an Open  
Binding^h^h^h^h^h^h^h Permission message that allows a client to set  
permissions explicitly without sending data.   I missed the argument  
as to why the explicit control of permissions was considered  
undesirable, but it doesn't sound like a major issue if you continue  
to omit such messages if they are a problem.  Would you consider  
including a paragraph that explains "why not", for posterity?

> the race condition described in the previous section.

This sounds great.  That should be worlds better than having timer- 
driven state machines on both client and server.  As an aside, would  
it be worthwhile to specify what a client should do if it receives  
encapsulated data what it believes is its current Active Destination?

> I will implement Option A unless there is strong desire on the list to

Simultaneous open is an unusual enough scenario that option A makes  
me want to test my TCP stacks on all our platforms to verify that  
they actually do that correctly.  Option B seems simpler to  
understand, implement and test.  Therefore, I am in favor of B,  but  
certainly not with a passion.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Feb 2007 15:49:22 -0800

> > permission for the TURN server to receive a TCP SYN from 
> > one specific IP address and port number.
> >
> > I will implement Option A unless there is strong desire on 
> > the list to do something else.
> 
> they actually do that correctly. 

TCP simultaneous-open was first documented in RFC793's figure 8, and
was also in RFC793's apparent precursor, RFC761.

> Option B seems simpler to  

B seems to align with how the UDP permissions work, too.

-d