Subject: [BEHAVE] READ and COMMENT: Re: TURN major issues and proFrom [email-masked] Sun Feb 04 19:26:03 2007

From: "Rohan Mahy" <[email-masked]>
Date: Sun, 4 Feb 2007 16:25:13 -0800

IMPORTANT NOTE: if you are receiving this auto responder after accessing Acme Packet's web portal or sending an email to a mailing list, rest assured that your message has been received and will be acted upon by the appropriate personnel.

I am taking Friday, February 2 through Tuesday, February 6 off and will be mostly unavailable during this time.  I will not have access to a computer, but will be reachable via my cell phone in the event of emergencies.

For support issues, please contact [email-masked].  For non-support issues, please contact Erin Medeiros, Vice President of Professional Services, at [email-masked].

Thank you,
Patrick Timmons
Vice President, Systems Engineering
Acme Packet, Inc.

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 6 Feb 2007 16:59:15 +0200

Le Monday 05 February 2007 02:25, ext Rohan Mahy a écrit :
> > 1. Allocations, Bindings, Permissions, Timeouts, and the Active
> > Destination.
(...)
> > - 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)

Yep, sticking to allocation and permission is more clear.

> > - 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).
(...)
> > - Each allocation can have zero or more permissions

I don't recall any notes that TURN server may put a limit on the number of 
permissions per allocation. In practice, like it or not, it will be that way, 
what should a server do if the limit is reached? What is the minimum limit a 
server must accept?

> > - When allocations are destroyed all related permissions are deleted.

Yeah, this is obvious :)

> > - Permissions are only created by Send Indications over UDP and
> > Connect Requests over TCP.

What if you do want to add a UDP permission without sending anything? This 
actually makes a lot of sense of the other side is running behind a symmetric 
NAT and without TURN: waiting for the other side to send allows avoiding the 
ICMP errors issue that is found in many non-behave-compliant NATs.

Send Indications without payload attribute maybe?

(...)
> > - The active destination is changed only with the Set Active
> > Destination Request for an allocation. The active destination is
> > completely independent of any permissions.

Yes, this simplifies a tiny bit.

> > 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.

Yes. But that seems to contradict the previous paragraph!?

> > 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.

No. Because of UDP packet loss or reordering, the client will still need to 
use Send Request after Set Active Destination (which makes me wonder if it 
would not be better to always use send and drop set active altogether).

> > 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.

As noted above, there should be a way to add permission without sending 
anything. It does not necessarily need to be through Set Active Destination 
though.

> > 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.

Agreed.

> > 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.

Ack.

> > 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>

The same 5 seconds interval might perhaps be applied to retransmit if the Set 
Active Destination has not been acked (packet loss).

> > <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>

To handle retransmission sanely, the server will still need to accept and ack 
Set Active Destination where REMOTE-ADDRESS matches current active dst, 
perhaps?

-- 
Rémi Denis-Courmont <[email-masked]>
Research Engineer