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

From: "Kevin Johns" <[email-masked]>
Date: Tue, 23 Jan 2007 10:34:01 -0700

Rohan,

Two questions on your proposed changes:

I do have some concern on requiring the client to refresh the
allocation. What is the driver for having the client refresh the
allocation even in the presence of relayed data?

The new text implies that only a single active destination is allowed.
Is my read correct or can the client set multiple active destinations?

Kevin

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Friday, January 19, 2007 9:03 PM
To: [email-masked]
Cc: Rohan Mahy
Subject: [BEHAVE] TURN major issues and proposed fixes

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: Rohan Mahy <[email-masked]>
Date: Tue, 23 Jan 2007 21:12:00 -0800

Hi Kevin,

> allocation even in the presence of relayed data?

A few come to mind:
1. The WG came to consensus on general principal that an explicit 
reallocation mechanism was preferable to an implicit one.
2. Keeping timers for permissions and allocations conjoined is messy.  
What happens after all the permissions time out?  That MUST NOT cause 
the allocation to suddenly expire.  To get sane behavior, the TURN 
server would need to start the allocation timer after all the 
permissions went away.  This seems overly complicated on the server 
side.
3. If a TURN client has an open allocation, and there is no explicit 
reallocation required, another host that spoofs the client's source IP 
address can send traffic through the TURN server toward an established 
peer indefinitely.  If reallocation is required, the attacker would be 
limited to a fixed period of time unless the attacker had the client's 
TURN credentials.

> Is my read correct or can the client set multiple active destinations?

By definition, there can only be one active destination.  Note that the 
active destination does not mean it is the only destination for which 
traffic can be flowing. The active destination means the only host for 
which end-to-end data is not wrapped in Send and Data indications.

thanks,
-rohan