Subject: Re: [Sip] Session timer issue resolutions

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Oct 2004 08:58:53 -0400

OK, I think its fair to characterize this as a typo, and I will change 
it to >= during auth48.

Thanks,
Jonathan R.

Ragunath Devarasu wrote:

> One reason could be backward compatibility with older drafts which said:
> 
> "                               If a Min-SE header is included
> in the initial session refresh request, the value of the
> Session-Expires MUST be equal to the value in Min-SE."
> 
> I understand that we needed to relax this requirement and that is the reason
> we have changed it to GREATER THAN. 
> 
> Assume that Session-Expires of already existing session is 300 seconds.
> During session timer refresh, uac wants to put Min-SE along with
> Session-Expires, it needs to put Min-SE: 299 and Session-Expires: 300 just
> to satisfy GREATER THAN. If it would have been GREATER THAN or EQUAL TO, uac
> could as well put Min-SE: 300 and Session-Expires: 300
> 
> Thanks
> Ragunath
> 
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, September 15, 2004 8:43 PM
> To: Shriram Natarajan
> Cc: [email-masked]
> Subject: Re: [Sip] Session timer issue resolutions
> 
> I don't think there is really any difference between > and >= in this 
> case. Is there a specific reason you need equality?
> 
> Also, do note that session timer has been approved by IESG. As such, any 
> changes to this specification need to be done during authors 48 hours. 
> Such changes are meant to address editorial/typo problems, and bugs in 
> the spec. New features, improvements, etc. are not permitted.
> 
> Thanks,
> Jonathan R.
> 
> Shriram Natarajan wrote:
> 
> 
>>Good day Jonathan,
>>
>>Why must the initial session refresh request have SE > MinSE (if present)?
>>
>>draft-15 section 7.1 says:
>> >>
>>                            If a Min-SE header is included
>>   in the initial session refresh request, the value of the
>>   Session-Expires MUST be greater than the value in Min-SE.
>><<
>>
>>What is the problem in modifying this to say:
>>
>> >>
>>                            If a Min-SE header is included
>>   in the initial session refresh request, the value of the
>>   Session-Expires MUST be greater than or equal to the value
>>   in Min-SE.
>><<
>>
>>
>>With best regards
>>Shriram
>>
>>
>>
>>
>>On 7/18/2004 2:03 PM, Jonathan Rosenberg wrote:
>>
>>
>>>Folks,
>>>
>>>Over the past few months, there were a bunch of comments on the list 
>>>regarding the previous revision of session timer. That previous 
>>>revision, -13, was made to address IESG comments, as the document 
>>>completed working group last call and was making its way towards 
>>>approval.
>>>
>>>I'll summarize what was said and the conclusions that were reached.
>>>
>>>Comment: I never saw -13, what happened?
>>>
>>>Conclusion: There was some kind of secretariat problem, I don't know 
>>>why. It was resubmitted and a -14 appeared, with no content change 
>>>from -13.
>>>
>>>Comment: Making Min-SE a minimum of 90s is too low for applications 
>>>that want to know quickly when there is a failure, including billing.
>>>
>>>Conclusions: Usage of the session timer for such fine grained liveness 
>>>tests is simply out of scope. Session timer is explicitly designed to 
>>>deal with cleanup of old, stale state.
>>>
>>>There were some comments along the lines of, "don't impose this 90s 
>>>minimum because of philosophical objections to this usage". However, 
>>>the reason that the 90s minimum was introduces is not philosophical at 
>>>all. There was a REAL practical problem of sessions being 
>>>inappropriately timed out. Here is the example. We set up a call with 
>>>the minimum session timer. Half way through it, the client tries to 
>>>refresh. A few packets get lost, so the refresh takes a bit. However, 
>>>since the session timer was so small, the session gets torn down by 
>>>the peer UA and/or intermediaries. This is bad. The session should 
>>>continue as long as the refresh transaction can complete successfully, 
>>>if initiated halfway through the interval. Do a bit of math, and this 
>>>tells you that you need around a 90s minimum.
>>>
>>>A final point on this topic - I agree it would be useful for third 
>>>parties to get VERY fine grained notifications of session liveness and 
>>>failure. However, the session timer mechanism is just flat out 
>>>inappropriate for that. I think that, if this was the driving 
>>>requirement, you would define a totally different solution; something 
>>>that did very frequent, low-overhead messages (like a stun request for 
>>>example) directly between interested entitites. As such, if people 
>>>want a good way to solve this problem, please write some requirements 
>>>down, bring them forward, and we can work on it. But, session timer is 
>>>not going to EVER be good enough for 6s failure detections (6s was 
>>>explicitly mentioned in the thread as a goal).
>>>
>>>As such, I have not changed the 90s requirement.
>>>
>>>Comment: Paul made a comment, preferring the usage of "infinite" for a 
>>>UA and "indefinite" for a proxy, as a description of the default value 
>>>of the session timer (i.e., whats in place when nothing is 
>>>negotiated). Dean commented that IESG felt that this would not be 
>>>good, and that the document would have trouble passing with this change.
>>>
>>>Conclusion: The current wording stays.
>>>
>>>
>>>Comment: the document defines "initial session refresh" as a 
>>>mid-dialog request, but it can happen in the middle of a dialog.
>>>
>>>Conclusion: this is a good point. I have fixed the terminology.
>>>
>>>
>>>Comment: can session timer be used in SUBSCRIBE dialogs?
>>>
>>>Answer: I don't think its needed, since subscriptions have their own 
>>>way of refreshing. I see adding the session timer to that as 
>>>confusing. Granted, subscription durations aren't negotiated with 
>>>input from proxies, but I dont see why they'll care for the most part. 
>>>Invite sessions are different because of the heavy involvement from 
>>>intermediaries.
>>>
>>>Comment/Question: If UAC includes both Session-Expires and Min-SE in 
>>>an initial request, it is required to make the values the same 
>>>(section 7.1). Why???
>>>
>>>Answer:
>>>
>>>Good question. Turns out this is a bug, and there is a historical 
>>>reason for it.
>>>
>>>First, you must pay attention to this bit in the security 
>>>considerations section:
>>>
>>> Next, consider the case of a rogue UAS that wishes to force a UAC to
>>>   generate refreshes at a rapid rate. In that case, the UAC has to
>>>   support session timer. The initial INVITE arrives at the rogue UAS,
>>>   which returns a 2xx with a very small session interval. The UAC uses
>>>   this timer, and quickly sends a refresh. Section 7.1 requires the UAC
>>>   to copy the current session interval into the Session-Expires header
>>>   field in the request. This enables the proxies to see the current
>>>   value. The proxies will reject this request, and provide a Min-SE
>>>   with a higher minimum. The UAC will then use this higher minimum.
>>>   Note, that if the proxies did not reject the request, but rather
>>>   proxied the request with a Min-SE header field, an attack would still
>>>   be possible. The UAS could discard this header field in a 2xx
>>>   response, and force the UAC to continue to generate rapid requests.
>>>
>>> From this, it is clear that for subsequent refreshes (rather than 
>>>initial ones), the session-expires should be placed into the request 
>>>as it was, allowing the chance for proxies to reject it. Note, 
>>>however, that the text above references section 7.1 which talks about 
>>>*initial* session refresh requests. Now, in an earlier version of the 
>>>document, the description of initial and subsequent behavior was 
>>>combined, and the section reference was valid. After it was split 
>>>apart, the functionality was inappropriately left in the section on 
>>>initial requests, and the reference also stayed in tact.
>>>
>>>The requirement is there in a slightly different form for subsequent 
>>>session refreshes:
>>>
>>>   In a session refresh request sent within a dialog with an active
>>>   session timer, the Sesssion-Expires header field SHOULD be present.
>>>   When present, it MUST be equal to the maximum of the Min-SE header
>>>   field (recall that its default value when not present is 90 seconds)
>>>   and the current session interval.
>>>
>>>As such, I believe the constraint can be removed for initial requests. 
>>>I've fixed that (SE just has to be larger than Min-SE), and adjusted 
>>>the reference from the security considerations section.
>>>
>>>Now, the behavior for subsequent requests needs some further 
>>>consideration. Both strengths ought to be the same; there is no point 
>>>in making the Session Expires max(min,current) if its not going to be 
>>>present in the request. So, I changed the second MUST to a SHOULD, and 
>>>explained that you normally want this to avoid dos attacks, but can 
>>>remove it or set it larger if you want to "reset" the process and 
>>>compute a new Session expires.
>>>
>>>
>>>
>>>Comment: what if a proxy (such as that in an ALG) has a MAXIMUM timer 
>>>it can support? Can we reject a refresh request and include some kind 
>>>of max-se header field?
>>>
>>>Answer:
>>>
>>>You can't have it both ways. If you allow for rejection of requests 
>>>because an interval is above someones maximum, you can get a situation 
>>>where someones maximum is below someones minimum. This is unsolveable 
>>>by any protocol means - the constraint cannot be jointly met. So, 
>>>which is worse - having an interval thats longer than someone wants, 
>>>or shorter? I say, its worse to have one that is longer than someone 
>>>wants, because having one that is too short can generate a lot of 
>>>traffic and processing for everyone. Thus, for the purposes of being a 
>>>good sip citizen, it is better to have an interval be longer than you 
>>>might want.
>>>
>>>So, I have made no change to the spec.
>>>
>>>I'll post a separate note with the specific changes.
>>>
>>>-Jonathan R.
>>>
>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip