Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Aug 2007 17:14:54 -0700

This document is looking very good - few big items

I don't understand when a server would send a status indication with  
the state as LISTEN. Can we remove this value?

I'm a bit lost on auth stuff - probably need separate thread on that.  
3489bis removed a way to get short term secrets but turn seems to  
assume they are still there. More importantly, we need to have some  
sort of security on the connection status indication bet since this  
can not be challenged, we can only use short term credentials.  
However, it's not clear how to get one. I suspect we may need a  
conference call some time on STUN/TURN credentials. It's not clear  
that the right message have enough in them to make replay attacks not  
be a problem for short term credentials usage.

What happens when relay receives more than it can send. My initial  
thought on this is 1) when receiving UDP packets, discard them. 2)  
when receiving TCP, stop reading from the incoming TCP buffer until  
their is space to send. If there are multiple incoming TCP  
connection, order they get serviced in is not specified and clients  
can't make any assumptions about it.

If a client ends up with two remote TCP connection (on the same  
allocation), it would be nice to have a way to close one of them but  
not the other.

The connection status indication probably needs the remote address  
attribute so that one can figure out what is going on when there are  
two TCP connection to same allocation.

Section 6.1.2.1 .. the idea that a move can be signaled by using the  
same credential would work for short term credentials but not long  
term ones as more than one client can share the same long term. I  
find this "move" idea fraught with peril to implement - particularly  
in the TCP case, I wonder if we really need it. I have a hard time  
imaging an TCP connection with active data flowing not getting out of  
sync during a move.

The redirect to a different server when overloaded seems like a bad  
idea. Imagine I have two servers A and B that are both overloaded -  
seems like I could have endless redirects. Having the client know  
about two servers via DNS then try one and if it is busy try the  
other makes more sense to me.

It might make sense to suggest that after a TCP allocation happened,  
the TURN server using BSD sockets would not want to start listening  
on it until their was at least one valid permission set on it.

Trivial stuff after this ....

Be nice to have an example showing TCP simultaneous open.

Section 4.1 - 2nd para - you suggest that there are cases where TLS  
will get thorough a firewall and TCP will not - this is true but so  
is the converse so don't want to imply one way or other is better for  
firewall traversal.

Figure 1 - would make more sense to me with s/STUN/TURN

Section 6.1.2.1 - It is confusing how the client would know what IP  
address the server supports  for relaying when the client wants to  
use the REQUEST-IP attribute. If you added some text explaining that  
this was used when allocating a second port after first port was  
allocated, it would be easier to understand.

In
   The server SHOULD only allocate ports in the range 1024-65535.  This
    is one of several ways to prohibit relayed transport addresses from
    being used to attempt to run standard services.
This does not seem to be a good way (or the way used in the draft) to  
accomplish this so I would just delete the second sentence.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 29 Aug 2007 08:56:35 -0700

Cullen Jennings wrote:

[snip]

> seems like I could have endless redirects. Having the client know about
> two servers via DNS then try one and if it is busy try the other makes
> more sense to me.
> 

I agree that using the redirect in this case will not really help.  My
proposal was to send back a domain name instead of an IP address, and to
use it in the client in replacement of the current domain used to find
the SRV records, but by remembering all the IP addresses already tried
and excluding them from the results of the subsequents SRV queries.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Aug 2007 15:15:03 -0700

Ah, I see what you are thinking but seems like it would be better to  
just start out with the SRV record and never need the redirect.

On Aug 29, 2007, at 8:56 AM, Marc Petit-Huguenin wrote:

>> about

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 29 Aug 2007 16:12:26 -0700

> just start out with the SRV record and never need the redirect.

Yes, but the redirect permits to do things a little bit more
dynamically.  Here's an example:

Let's say we have 3 data centers, one in London,  one in Santa Clara, CA
and another in Hong Kong.  The initial SRV lookup for the example.com
domain returns this:

SRV 0 1 3478 redirect.london.example.com.
SRV 0 1 3478 redirect.santa-clara.example.com.
SRV 0 1 3478 redirect.hong-kong.example.com.

All RR have the same priority, so one of them is randomly selected.  The
client sends the request to the server, the server uses a geoip lookup
to detect the closer data center to the client, and sends a redirect
with the domain hong-kong.example.com.  The client then do a SRV query
for hong-kong.example.com, with the following result:

SRV 0 1 3478 turn1.hong-kong.example.com.
SRV 0 1 3478 turn2.hong-kong.example.com.
SRV 1 1 3478 turn1.santa-clara.example.com.
SRV 1 1 3478 turn2.santa-clara.example.com.
SRV 1 1 3478 turn1.hong-kong.example.com.
SRV 1 1 3478 turn2.hong-kong.example.com.

The TURN servers in the Hong Kong data center will be tried first, then
the TURN servers in the other data centers if they are unreachable.

Note that this is just an example, there is better ways to achieve the
same result.