Subject: Re: [BEHAVE] TURN 06 Comments

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 13:10:18 -0500

Cullen:

Thanks for your comments. Sorry to be slow in responding.
Some of your comments have been overtaken by subsequent discussions,  
but I have made some changes in the document as a result of others.  
See more in-line.

On Fri, 25-Jan-08, at 01:39 , Cullen Jennings wrote:

>
> Gave the document a quick skim. Few comments ....
>
>
> The whole design of refreshing and lifetimes of allocations and  
> permissions seems very disjoint and sub optimal.  I would be  
> tempted to go with allocation go away 30 seconds after they have no  
> valid permissions. Permissions can be updated by client sending  
> data or zero length send. Permissions durations match BEHAVE UDP  
> documents.

Personally, I like your idea that allocations go away 30 second after  
the last permission. However, on the last conf call, so one else was  
in favor. People wanted to keep the explicit refresh mechanism for  
allocations. One reason to keep this is that it provides a way to  
change the allocation bandwidth, which is (currently) another TURN  
feature.

So I have make the following changes instead:
* Permission lifetime is 5 minutes, fixed.
* Channel lifetime is 10 minutes, fixed.
* Allocation lifetime is 10 minutes, adjustable.
The client can increase the allocation lifetime, but cannot decrease it.

For refreshing:
* Permissions are refreshed by sending data to that IP address, or  
with a Data indication with no DATA attribute.
* Channels are refreshed by sending data on that channel, or by  
rebinding the channel to the same peer.
* Allocations are refreshed using the Refresh transaction.

IMO, this simplifies things and gets rid of silly things like a 20  
second allocation lifetime.

>
> Much of the discussions around permissions make them sound like  
> they are not bound to a specific allocation and instead the  
> permissions is granted to the whole TURN server. This needs to be  
> cleaned up. (Normative stuff looks right).

I have rewritten section 2.5 in the Overview of Operation section. It  
now says:
2.5.  Permissions

    To ease concerns amongst enterprise IT administrators that TURN  
could
    be used to bypass corporate firewall security, TURN includes the
    notion of permissions.  TURN permissions mimic the address- 
restricted
    filtering mechanism of NATs that comply with [RFC4787].

    If the client has send data to a peer (via the server) within the
    last 5 minutes, then any peer with the same IP address (the port
    numbers can differ) is permitted to send data to the client.   
After 5
    minutes, the permission times out and the server drops any UDP
    datagrams arriving at the relayed transport from that IP address.
    Note that permissions are within the context of an allocation, so
    adding or expiring a permission in one allocation does not affect
    other allocations.

    Data received from the peer DOES NOT refresh the permission.

In addition, there is now a new section in the normative portion of  
the document that goes into detail on how permissions work. Other  
sections now reference that section whenever they mention one of they  
ways that a client can establish/refresh a permission.

>
> I view the whole redirect to another TURN server as a really bad  
> idea. Not to mention that it conflicts with the 3489 usage of this  
> but even worse, it is highly likely to cause things to fail during  
> overload in a way where the overloaded machine gets bounced around  
> and the system never recovers. I think the SRV mechanisms are  
> sufficient for load balancing, work well, and we should get rid of  
> this stuff.

I have simplified the text, but have left it in for now. But I have  
flagged it as an open issue. Personally, I am happy to take it out if  
no one want it.

>
> Not a big deal but I don't like the waiting to 3/4 of LIFETIME, If  
> the lifetime is 7200 this is way too early - I would prefer  
> something more like LIFETIME minus 5 seconds and some introduction  
> of jitter.

The text now recommends 1 minute before the allocation expires (out  
of min 10 minute allocation lifetime). I think 5 seconds before is  
too short.

>
> section 5.2, 2nd bullet point. It looks like it always replies with  
> 437 to a request over TCP. I might just be reading this wrong.

This section has been rewritten. I think the problem has gone away.

>
> Bandwidth - section 5.2.1.1 I would not want to use the words"  
> determines if there is sufficient capacity" as this may be very  
> hard to do, instead something like "decide if willing to grant this  
> bandwidth". The contract is not guaranteeing a minimum, it is  
> setting a max and suggesting a best attempts will be made to do  
> minimum, We still need to specify the algo for computing this.

The text now uses the word "grant". It also points out that all this  
is really placeholder text and that we still need to work out the  
details.

>
> Section 5.2.1.4: One of the key design points of this protocols is  
> that you can not use it to pick an arbitrary port number to run  
> over. This seems to change that and that is one of the things I  
> feel very strong about. You need to support paired ports for RTP/ 
> RTCP because TURN is the last line of defense that is supposed to  
> always work. I am fine with a protocol where the client asks for a  
> pair and gets X and knows that X+1 is reserved and then requests X 
> +1. I am not ok with a protocol where the client gets to choose the  
> port the server uses.

TURN now uses your proposed mechanism, though I changed the encoding  
details slightly.

>
> 5.2.1.6, 2nd para. The idea that "standard services" run on ports  
> below 1024 does not seem true.

What words would you say here?

>
> Section 6.3 - This should be reworded to say what goes in the UDP  
> payload and then a UDP packets is sent. Once we start talking about  
> forming UDP checksums, it is a sign something is not right :-)

OK, OK!! After your and EKR's comments, I have removed the last two  
bullets. The text now says:

    If the received Send indication contains a DATA attribute, then it
    forms a UDP datagram as follows:

    o  the source transport address is the relayed transport address of
       the allocation, where the allocation is determined by the 5-tuple
       on which the Send Indication arrived;

    o  the destination transport address is taken from the PEER-ADDRESS
       attribute;

    o  the data following the UDP header is the contents of the value
       field of the DATA attribute.

    The resulting UDP datagram is then sent to the peer.  If any errors
    are detected during this process (e.g., the Send indication does not
    contain a PEER-ADDRESS attribute), the received indication is
    silently discarded and no UDP datagram is sent.

I made a similar change in the section on channels.

>
> Section 7.5, first para. Where you have SHOULD use the Channel- 
> Data, I think that has to be a MUST. The server has no way of  
> knowing what the clients bandwidth issues are thus cannot make a  
> reasonable determination.

I have changed it to a "MUST".

>
> Section 2.1. para 2. I find this paragraph somewhat bogus. The  
> visibility of peers to attacker between client and TURN server is  
> not a threat model I have seen brought up before. Doubt it is  
> relevant. I find the argument that TLS has better success rate of  
> traversing firewalls than TCP to be, uh, unproven at best.

Jonathan had a related comment, so we changed the text to the following:

    For TURN clients, using TLS over TCP to communicate with the TURN
    server provides two benefits.  First, the client can be assured that
    the addresses of its peers are not visible to any attackers between
    it and the server.  Second, the client may be able to communicate
    with TURN servers using TLS when it would not be able to communicate
    with the same server using TCP or UDP, due to the policy of a
    firewall between the TURN client and its server.  In this second
    case, TLS between the client and TURN server facilitates traversal.

However, this does not address your first comment.

Do you feel we should drop TLS as a transport to the server for TURN?  
If not, then what benefits do you think it provides?

>
> Section 12
>
> The whole document (not just this section) seems a bit weak on  
> short and long term credentials. My understanding is that we don't  
> want to create unauthenticated open relays. So even if anyone can  
> get an account on a public server, we still want to be able to log  
> what account did what. My recollection of previous conversations  
> when doing STUN bis was the allocated were going to use long term  
> credentials and help set up the short term credentials used to  
> authenticate the data, send, and channel data.  I'm not claiming I  
> corruptly remember any of this but either way, still looks like  
> some work needed here on how this is all authorized.

The idea of using the long-term credential mechanism to set up short- 
term credentials was dropped last spring during the big "finish  
3489bis" push. I convinced Jonathan that it was way too complex. So  
short-term credentials are not used in TURN.

TURN uses only the Long-Term Credential mechanism. Most of the text  
on how it is used has been rewritten in TURN-07. Hopefully the  
details are now clear.

The one point that I am somewhat unsure about is how a public TURN  
server might work. The text currently says that the server SHOULD use  
the Long-Term Credential mechanism, where the idea behind the SHOULD  
is to allow public servers to not do it. But this really weakens TURN  
security. I have added this as an open issue.

> As a trivial side note, it looks like some of the issues with NAT  
> remote in section 12 could be substantially mitigated by clients  
> choosing random channel numbers.

I think they are also mitigated by waiting 2 minutes before the 5- 
tuple (between the client and the server) can be re-used. This is  
what TURN now does.

>
> On the open issues, I don't actually think all of these are open:
>
> 1) thought we agreed to do this

BANDWIDTH is being retained, but the details are still open. TURN-07  
has a placeholder mechanism while we debate the details.

>
> 2) I think we agreed address-restricted. I suspect I was the only  
> person arguing for address-and-port and well, I loose :-)

Yup.

> 3) we need this

TURN-07 uses your mechanism.

>
> 4) uh, we are looking for a demux simpler than bit mask 2 bits?  
> Surely you are joking :-) Actually I have no idea if we are done or  
> not here. I think we need to go think carefully about all the demux.

We agreed to keep the mechanism of TURN-06.

> 6) any reason why not?

No. So I have adopted this.

>
> 8) I found Magnus and Lars emails about this pretty much sold me on  
> the answer

It seems that Magnus and Lars don't like the current "preserving IP  
header bits" proposal.

>
> 10) A client should only be able to request an IP address returned  
> in allocate response fro the same server and for a allocation that  
> is still valid.

Err... This was not the issue in question.  Anyway, I closed the  
issue as "no restrictions"
>
> 11) we should make this the same as the BEHAVE UDP documents. Note  
> that choices other than this will result in the same long  
> discussions over again and be difficult to implement for some  
> styles of implementations (i.e. windows or unix not running as root).

We agreed to silently discard.

>
> 12, 14 - see previous comments on this

See responses above.

>
> 15 - I don't care but my gut feeling is put on v4/v6 relays for  
> now. Or at least make sure you have the support of the v6ops  
> community before you do it.

The document now prevents v4-to-v6 relaying, and points at Oscar and  
Gonzalo's document as a possible extension to allow this.

>
> Cullen <with my individual contributor hat on>
>

- Philip

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