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

[Magnus Westerlund <[e-mail]>]

Hi Simon,

Sorry for being tardy in the response. I will be on vacation next week,
so a quick turn around on this is appreciated.


Simon Perreault skrev 2010-01-25 04:34:
> Magnus Westerlund wrote, on 23/01/10 01:04 AM:
>> 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.

> 
>> 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?
> 
> Good thinking, thanks.
> 
> However, there are many other timeouts involved in the TCP state machine. I
> don't expect the client to have control over all of them. Is the connection
> timeout important enough to give control over it to the client?
> 
> I don't think client control over TCP timeouts is important given the expected
> use cases for TURN.
> 
> The upper limit of the connection timeout can already be controlled by clients.
> They can just close their connection to the server when it starts taking too
> long. (Does this need to be mentioned explicitly?)
> 
> 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.

> 
>> 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.

> 
>> 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 [e-mail], so I wonder why this text isn't
> already in the draft...)

Ok, please get some text in there.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------