Subject: Re: [BEHAVE] AD comments on draft-ietf-behave-turn-tcp-05

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Mar 2010 11:29:43 -0500

On 2010-02-03 07:52, Magnus Westerlund wrote:
>>> 1. Section 3.4 and 5.2, if the Turn server takes time to complete the
>>> Connect request, can additional connect or other TURN requests be issued
>>> with one connect request outstanding?
>>
>> Yes. As with any other STUN/TURN request, processing multiple requests in
>> parallel is allowed. The Connect request is special in that its processing
>> involves reaching across the Internet, but this is orthogonal.
>>
>> Do you think it need to be mentioned explicitly?
>
> Maybe, I think there is some point to say yes, but attempting to limit
> the number of simultanous ones. That might be easiest accomplished by
> pointing to some existing text around this issue. I can't remember if
> that is in STUN, TURN or ICE.

I haven't found any text in these documents that might apply to this. 
Therefore I created some.

For client processing:

    As with any other request, multiple Connect requests MAY be sent
    simultaneously.  However, Connect requests with the same XOR-PEER-
    ADDRESS parameter MUST NOT be sent simultaneously.

For server processing:

    If the server is currently processing a Connect request for this
    allocation with the same XOR-PEER-ADDRESS, it MUST return a 446
    (Connection Already Exists) error.

>>> 2. Section 5.2: Any consideration for timeout for the TCP connection
>>> attempt from the server? Is that purely a server implementation choice?
>>> Some minimal value the client can expect? Maybe a option to specify a
>>> timeout for the client would be appropriate here?
>>
>> For the lower limit, how about mentioning that servers MUST ensure at least 10
>> seconds before connection timeout?
>
> No, I don't think client control of the timeout is important either.
> However, I think there is a point in specifying a minimal timeout the
> server may use. And I think that should be larger than 10 seconds, more
> like 30s. I know that is an eternity for some real-time applications.
> However 10s is not that long if there is need for some end-point
> synchronization or other. The expectation here is that the client will
> kill the connection attempt if it is no longer needed. Until that the
> server should continue to try. But not for ever due to the possibility
> to use the TURN server as attack tool in that case.

Agreed. I added this in the Connect server processing section:

    The timeout value MUST be at least 30 seconds.

>>> 3. Section 5.2: Why is the initial data buffered? Isn't it better to not
>>> read from the socket until its peer TCP connection is available. That
>>> way the stream will not advance until the data can be forwarded.
>>
>> Whether data is buffered in kernel or user space is irrelevant from the point of
>> view of the protocol. It's an implementation detail.
>
> My point is the question on what assumptions the client can make ones
> the data has been acked. Especially in cases where the application
> adapts the content based on what it manage to send through. Thus having
> the document indicate that the server shall buffer, especially the
> initial data seems wrong to me.

I don't understand your point.

Here's the current text:

                      The server MUST buffer any data received from the
    peer.  Data MUST NOT be lost unless the buffer is about to exceed a
    limit defined by local policy, in which case the data connection MUST
    be closed.  The server adjusts its advertised TCP receive window to
    reflect the amount of empty buffer space.

The current text ensures that once the data is acked by the server, the 
server is in charge of it. That's the assumption that the client (or 
peer) can make.

Even if we don't read from the socket, the kernel will send ACK packets. 
The kernel will buffer data for user-space even if no buffering is done 
in user-space. And this is what we want.

>>> 4. Section 5.3, shouldn't the connection attempt be checked against the
>>> permissions before being accepted?
>>
>> Yes and no.
>>
>> The server needs to check permissions. This is an omission in section 5.3. It is
>> a big error that needs to be fixed. Thanks for noticing it.
>>
>> However, the permission check needs to happen after the connection is accepted
>> but before the ConnectionAttempt indication is sent to the client. This is so
>> because a user-space implementation cannot know the identity of the peer before
>> calling accept(). So we accept the connection, then drop it if it fails the
>> permission check.
>>
>> (I recall explaining this on [email-masked], so I wonder why this text isn't
>> already in the draft...)
>
> Ok, please get some text in there.

I added the following text:

    If no permission for this peer has been installed for this
    allocation, the server MUST close the connection with the peer
    immediately after it has been accepted.

I will update the references and produce an updated draft shortly.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Mar 2010 11:55:54 +0100

Thanks Simon,

I am not certain about the buffering part. But I will leave it to let
others react to it if they have issues. I have requested last call. It
will run until the end of the month due to the meeting. I will also hand
this document over to David for the next steps.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------