Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-si p-session- timer: refresh rate)

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 8 May 2001 11:00:29 -0500

>In an effort to come to closure on this question, I would propose the
>following be added to the session timer draft:
>
>1) A method for a proxy or UAS to reject a session timer 
>request because the
>session timer value is too small.  This is needed for both 
>approaches, so
>should not be controversial.  I would propose that we use the 
>488 response
>with a reason phrase of Session Timer Too Small (or something 
>similar).  I
>would also propose that the session-expires header be used in 
>this response
>to indicate the minimal acceptable session timer value.  
>(Note: I'm trying
>to reuse an existing response instead of creating a new one.  We can
>certainly create a new one, if there is consensus to do so).

This seems ideal.

>
>2) We change the session-expires header to only support delta 
>times with a
>granularity of minutes.  I think there is consensus that 
>session-expires
>values of less than one minute are not needed.  

I don't see the need for this. While I think it really only
makes sense to use delta values, for consistency I would allow
both forms. Not allowing the absolute form doesn't help solve
the smurf attack; disallowing small delta values does.

>
>3) We add stronger wording in the security section of the 
>draft describing
>the smurf attack that Jonathan is worried about.  As part of 
>the wording, we
>add the statement that entities supporting session timer 
>SHOULD support a
>minimum time of n minutes.  I propose we take Jonathan's 
>suggestion and make
>n = 30.  The obvious difference here is that Jonathan's 
>suggestion becomes a
>SHOULD instead of a MUST.

A recommended value of 30 minutes is fine. Making it a SHOULD seems
slightly too strong. Having the 488 response allows a UA to adapt
to the networks desire for longer session timers.

/sean

>
>Thoughts?
>
>Steve
>
>---
>Steven R. Donovan
>Architect                           dynamicsoft                
>         
>mailto:[email-masked]     5100 Tennyson Parkway
>sip:[email-masked]    Plano, Texas 75025
>tel:+1-972-473-5469                 http://www.dynamicsoft.com

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 09 May 2001 08:58:22 +0300

Hi,

My comments are almost the same as Sean's.

>>request because the session timer value is too small.  This is needed for both
>>approaches, so should not be controversial.  I would propose that we use the
>>488 response with a reason phrase of Session Timer Too Small (or something
>>similar).  I would also propose that the session-expires header be used in
>>this response to indicate the minimal acceptable session timer value.
>>(Note: I'm trying to reuse an existing response instead of creating a new one.  We can

[Christer]: I agree. I would like to add a specific 4xx response code
for this, though, instead of having to read the reason phrase.
  
>>draft describing the smurf attack that Jonathan is worried about.  As part of
>>the wording, we add the statement that entities supporting session timer
>>SHOULD support a minimum time of n minutes.  I propose we take Jonathan's
>>suggestion and make n = 30.  The obvious difference here is that Jonathan's
>>suggestion becomes a SHOULD instead of a MUST.
>

I agree. I would even argue that a recommended specific timer value
(e.g. 30 minutes) is too "strong", because what data do we have to "back
up" that value? The proper value is depending on so many things (network
architecture, transport protocol, number of nodes, network reliability,
node reliability, network size, distance between nodes etc etc etc etc
etc), so I would rather describe how the session-timer shall be used,
and why a relatively high value shall be used ( 30 minutes can be given
as an EXAMPLE instead of a RECOMMENDATION). This is just a smaill
detail, though, so we should not spend too much time arguing about it.

Regards,

Christer Holmberg
Ericsson Finland