Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations

From: Philip Matthews <[email-masked]>
Date: Tue, 15 Jan 2008 10:23:48 -0500

Here is my proposed text to handle this issue:

    When the server receives the Allocate Request, it begins by
    processing it according to the base protocol procedures described in
    [I-D.ietf-behave-rfc3489bis], plus the Long-Term Credential  
Mechanism
    procedures if the server is using this mechanism.

    It then checks if the 5-tuple used for the Allocate Request matches
    the 5-tuple used for an existing allocation.  If there is a match,
    then:

    o  If the transport protocol is UDP, and the transaction id in the
       request message matches the transaction id used for the original
       allocation, then the server treats this as a retransmission of  
the
       original request, and replies with the same response as it did to
       the original request.  The server may do this by either storing
       its original response and resending it, or by rebuilding its
       original response from other state data.

    o  If the transport protocol is not UDP, or if the transaction id in
       the request message does not match the transaction id used for  
the
       original allocation, then the server replies with an error
       response containing the error code 437 Allocation Mismatch.

    If the 5-tuple does not match an existing allocation, then  
processing
    continues as described below.

Comments?

I am particularly interested in comments about how easy it is for  
servers to rebuild the original response from other state data. I  
took a quick look at this, and it seems straightforward to me: the  
server simply pulls the values for the RELAY-ADDRESS, LIFETIME, and  
BANDWIDTH from the state data.

- Philip

On 14-Dec-07, at 08:46 , Philip Matthews wrote:

> That is fine with me.
> - Philip
> On 14-Dec-07, at 00:12 , Jonathan Rosenberg wrote:
>
>> Ah, OK. I think this is an esoteric case but I agree this is an  
>> inconsistency. I'd suggest a minor word smithing in rfc3489bis to  
>> fix this.
>>
>> -Jonathan R.
>>
>> Philip Matthews wrote:
>>> I see a very small inconsistency between this and 3489bis.
>>> Let's assume the server uses Remi's suggested implementation  
>>> technique. And lets say a client does an Allocate transaction  
>>> with the server, then immediately deletes the allocation, and  
>>> then does a second Allocation that happens to use the same  
>>> transaction id as the first, but which the server cannot accept  
>>> for some reason. Say all this happens within 10 seconds. Then the  
>>> server needs to response with an error response, but 3489bis says  
>>> that is should respond with a success response.
>>> The problem is simply that the language in 3489bis is too strong  
>>> for the TURN case. We could fix this either by changing the  
>>> language in 3489bis, or by specifying Remi's proposed  
>>> implementation technique and saying that this overrides the text  
>>> in 3489bis about the 10 second stuff.
>>> - Philip
>>> On 12-Dec-07, at 23:24 , Jonathan Rosenberg wrote:
>>>> I don't see what the duration of the allocation has to do with  
>>>> the 10 second timer. Another way to think about the timer is  
>>>> that the server has to provide transaction state and retain it  
>>>> for 10 seconds after the end of the transaction.
>>>>
>>>> -Jonathan R.
>>>>
>>>> Philip Matthews wrote:
>>>>> On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote:
>>>>>> inline:
>>>>>>
>>>>>> Rémi Denis-Courmont wrote:
>>>>>>> Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg,  
>>>>>>> vous avez écrit :
>>>>>>>> There was general agreement at the ad-hoc that this is a non- 
>>>>>>>> issue. TURN
>>>>>>>> servers are already required to maintain state, in the form of
>>>>>>>> allocations, permissions, channel bindings, and so on.  
>>>>>>>> Transaction state
>>>>>>>> is not much more.
>>>>>>>>
>>>>>>>> Note that, rfc3489bis requires stun transactions (including  
>>>>>>>> extensions
>>>>>>>> like TURN) to be idempotent. Note that, despite the  
>>>>>>>> different response
>>>>>>>> codes for a retransmit and new transaction, TURN remains  
>>>>>>>> idempotent.
>>>>>>>> Idempotency only requires that subsequent retries do not  
>>>>>>>> alter the state
>>>>>>>> on the server; it does NOT require the same response. We  
>>>>>>>> went through
>>>>>>>> this ad-nauseum on XCAP.
>>>>>>>>
>>>>>>>> The proposal is therefore to just document this fact, but  
>>>>>>>> otherwise not
>>>>>>>> change anything.
>>>>>>>>
>>>>>>>> Please comment if you agree (or not) with this.
>>>>>>> If I understand correctly, this practically means the server  
>>>>>>> must remember the ID of the STUN transaction that created the  
>>>>>>> TURN allocation. When it receives an allocation, it returns a  
>>>>>>> success response if it's the same ID or an error if it's not.  
>>>>>>> Right?
>>>>>>
>>>>>> Yes.
>>>>> To be consistent with 3489bis, you would also have to have a 10  
>>>>> second timer. 3489bis says:
>>>>>    If the request uses UDP transport and is a retransmission of a
>>>>>    request for which the server has already generated a success  
>>>>> response
>>>>>    within the last 10 seconds, the server MUST retransmit the same
>>>>>    success response.  One way for a server to do this is to  
>>>>> remember all
>>>>>    transaction IDs received over UDP and their corresponding  
>>>>> responses
>>>>>    in the last 10 seconds.
>>>>> For short-lived TURN allocations, the 10-second timer is  
>>>>> probably pointless, even though 3489bis requires it. For long- 
>>>>> lived allocations (days or weeks or even months), the timer  
>>>>> might become important -- I haven't worked out the math. In  
>>>>> either case, I think the two documents should be consistent.
>>>>> - Philip
>>>>
>>>> -- 
>>>> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
>>>> Cisco Fellow                                   Edison, NJ 08837
>>>> Cisco, Voice Technology Group
>>>> [email-masked]
>>>> http://www.jdrosen.net                         PHONE: (408)  
>>>> 902-3084
>>>> http://www.cisco.com
>>>>
>>
>> -- 
>> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
>> Cisco Fellow                                   Edison, NJ 08837
>> Cisco, Voice Technology Group
>> [email-masked]
>> http://www.jdrosen.net                         PHONE: (408) 902-3084
>> http://www.cisco.com
>>
>
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave
>

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