Subject: [BEHAVE] TURN and TURNS URI and resolution mechanism

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 22 Apr 2008 07:48:20 -0700

I just submitted an I-D that defines URIs and a resolution mechanism to
find TURN servers:

http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uri-00.txt

Comments appreciated.

Thanks.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 22 Apr 2008 15:49:10 -0400

Most this draft makes sense to me and seems I like it. One thing that  
I don't understand, what's the need for S-NAPTR in the type of use  
case we need here. Why not just  greatly simplify this and just have  
SRV (and of course A/AAAA implied by that)?

Cullen <with my individual hat on>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 22 Apr 2008 16:48:58 -0700

Cullen Jennings wrote:
> 
> Most this draft makes sense to me and seems I like it. One thing that I
> don't understand, what's the need for S-NAPTR in the type of use case we
> need here. Why not just  greatly simplify this and just have SRV (and of
> course A/AAAA implied by that)?

My original reason for using the S-NAPTR mechanism was to give a TURN
servers administrator a possibility to provision the preferred order to
use the different transport protocols between the TURN client and the
TURN server (UDP, TCP and TLS as currently defined).  This is not really
needed when using TURN with ICE because the socket on the TURN client
should be able to receive/send with the same protocol that is used on
the relayed port, so the preferred transport list used in the resolution
mechanism contains only one protocol.  But be able to give preference to
a transport over another can still be useful for other usages, e.g. an
administrator with resources constraints can prefer that the clients use
UDP, and another administrator with security constraints can prefer that
the clients use TLS (obviously in the cases where both protocols can be
used).

Another reason could be remote hosting.  A VoIP provider can have a
contract with a different company that provides only the TURN servers.
The provider does not (and cannot) manage the SRV records, as the
servers are not under its control, so S-NAPTR can solve this problem:

example.com IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp" "" other.com.

other.com IN NAPTR 100 10 "s" "RELAY:turn.udp" "" _turn._udp.other.com
other.com IN NAPTR 200 10 "s" "RELAY:turn.tcp" "" _turn._tcp.other.com
_turn._udp.other.com IN SRV   10  10 3478 a.other.com.
_turn._udp.other.com IN SRV   10  10 3478 b.other.com.
_turn._udp.other.com IN SRV   10  20 3478 c.other.com.
_turn._tcp.other.com IN SRV   10  10 3478 a.other.com.
_turn._tcp.other.com IN SRV   10  10 3478 b.other.com.
_turn._tcp.other.com IN SRV   10  20 3478 c.other.com.

Here the company providing the TURN servers does not know (and does not
care) if the VoIP provider is using the servers for ICE or another usage.

I am even thinking that this mechanism could be used to select a TURN
server by its feature set (versus trying all the servers until one
responds with the set of features needed).  Let take the example of
turn-ipv6.  Without S-NAPTR one will have to try to allocate an IPv6
address/port on the first SRV RR returned then if it fails try the next
server and so on until one return an IPv6 address/port.  Now if
turn-ipv6 defines an Application Protocol tag named turn.udp+ipv6, a
TURN client can directly retrieve the SRV RR pointing to servers that
can allocate an IPv6 address.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 23 Apr 2008 08:50:36 +0300

> http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uri-00.

Should this not:
1/ allow for [username@[password:]], e.g. as HTTP, and,
2/ use UNAPTR rather than NAPTR?

-- 
Rémi Denis-Courmont

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 23 Apr 2008 02:57:49 -0700

> 1/ allow for [username@[password:]], e.g. as HTTP, and,

The password in the URI is now deprecated (RFC 3986 section 3.2.1),
which is a good thing.  I am not sure that be able to provide the
username on the URI adds anything useful - in all case the end-user will
have to be prompted for the password, so prompting also for the username
should not be a problem.  There is also the minor security risk that it
can be used to confuse the end user (e.g.
turn:[email-masked]).  This said I can add the username
component if people think it is important.

> 2/ use UNAPTR rather than NAPTR?

I did not find a use case where a TURN URI needs be converted into
another URI, but as it annoys me when authors reject suggestions because
then cannot think of a use case to justify it, so let me know if you
have a good reason for this.

Thanks.

<rant>I always found this "use case" thing extremely annoying when
working with the IETF, and this for two reasons.  Firstly I consider
top-down design as bad engineering.  Secondly there is often use cases
that can justify to add something to an RFC, but I cannot talk about
because it would give an insight to my competitors on what I am working
on - another good reason for bottom-up design.</rant>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 Apr 2008 09:42:31 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin
> Sent: Wednesday, April 23, 2008 2:58 AM
> To: Rémi Denis-Courmont
> Cc: [email-masked]
> Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism
> 
> http://www.ietf.org/internet-drafts/draft-petithuguenin-behave
> -turn-uri-00.
> >> txt
> > 
> > Should this not:

Your I-D describes an address resolution mechanism, which is unlike
HTTP (or FTP, which can also have username:password) that accesses
a resource (a 'document' or 'file').  

The only value that I see with allowing the username in the URI is
if we expect someone might want:
  
  turn:[email-masked]
  turn:[email-masked]

to resolve to different IP addresses.  That doesn't seem likely to
me, (for whatever my foresight is worth).

-d

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 23 Apr 2008 10:30:32 -0700

Dan Wing wrote:
> to resolve to different IP addresses.  

Yes, I like the idea that all components in the URI are exclusively for
the purpose of guiding the resolution mechanism.

> That doesn't seem likely to

Well, one can design a mechanism that would resolve a user component to
a SRV/A RR, e.g. with distributed hash tables (a hash is associated to a
SRV RR in the DNS, the client calculates a hash for the user component
and use the SRV RR with a hash value equal or lower to the user hash value).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 Apr 2008 10:44:09 -0700

> and use the SRV RR with a hash value equal or lower to the 

Sure, but you could do that without usernames by encoding
that value you want to hash as if it was a hostname,

  turn:dan.wing.turn.example.com
  turn:joe.sixpack.turn.example.com

and a wildcarded DNS record (yes, not pretty) could be tied into the
hash generation.

-d