Subject: [BEHAVE] Simplifying TURN/UDP destination handling

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 1 Feb 2007 10:34:55 +0200

Hello,

Currently, TURN requires a time-dependant state machine to handle Set Active 
Destination (SAD).

First, some of the requirements there do not seem to be really required: e.g., 
why forbid the client from sending multile different SAD within the 5 seconds 
delay? Any sane TURN client implementation will not send multiple confilcting 
SAD if it risks wreaking havoc to its allocation, and any insane 
implementation has dozens of ways to screw itself up whatever we do.

But in fact, it seems to me that this can never be fully sorted out anyhow, 
because there will always be corner-case packet loss issues.

So the question is, do we really need to send SAD at all? I would expect 
TURN-enabled applications to integrate in a way that is similar to the BSD 
socket API. Also, looking at typical UDP protocols, I do not see much use for 
SAD.

Scenarios I can realistically think of:

1/ Server or otherwise one-to-all

That would cover ICE in the probing phase, or TEREDO, or any server-typeof 
protocol. TURN currently forbids this use case anyway.

I can understand some people do not want this to happen:
- because of policy constraints, and/or
- to protect last-mile link fro being flooded

It would still be interesting to conditionnaly allow this because:
- it saves the server the need to maintain the access list if the client 
wishes not to use it, and policy does not mandate it either,
- it improves support for ICE-type-of things if the "other side" does not 
support TURN, and runs behind a symmetric NAT: by allowing this, the TURN 
allocation would mimic a full-cone NAT; symmetric-to-full-cone traversal 
works, while symmetric-to-restricted traversal does not.

This scenario is equivalent to socket/bind/sendto/recvfrom/close in socket API 
terms. Because the destination will keep changing, SAD is unusable anyway and 
Send Indication must always be used instead.

2/ One-to-many

Like 1, but TURN still maintain the access list based on Send Indication. This 
will be used instead of 1 when the access list is required for whatever 
reasons.

3/ Client-to-server or otherwise one-to-one

That covers SIP and RTSP (and DNS but you don't want to do DNS on TURN) 
clients. This is socket/bind/connect/send/recv/close in socket API terms.

It is also possible to go from scenarios 1or2 to scenario 3 through a ONE-TIME 
Set Destination, which could probably be merged with Connect. Once this is 
done, traffic from other peers is dropped and server can stop putting the 
remote address in data messages.

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

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