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

From: Steve Donovan <[email-masked]>
Date: Tue, 15 May 2001 09:33:33 -0400

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2001 8:10 AM
> To: [email-masked]
> Cc: 'Steve Donovan'; [email-masked]
> Subject: Re: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 
> 
> Hi,
> 
> Some comments.
> 
> >>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).
> >Reusing 488 is fine, but the current bis definition
> >only reflects that SDP is the problem instead of
> >potentially the headers.
> > 
> >Reusing Session-Expires in the 488 is fine, but it
> >would potentially cause confusion with the fact
> >that currently Session-Expires in a negative response
> >will still reset session timer.  [However as I've
> >mentioned previously, I wish negative response
> >couldn't extend sessions since a proxy could have
> >generated the negative response instead of the UAS.]
> 
> [Christer]: I would still vote for a specific 4xx code. It is then
> possible to specify specific actions, by nodes supporting the
> session-timer, to be taken when it arrives, ie that the 
> Session-Expires
> header would have a special meaning.

This can be achieved by using the combination of the 488 and the presence of
a session-expires header.

>  
> >>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.
> > 
> >Keeping granularity in seconds is fine with me.
> >I'm more concerned about the minimum Session-Expires
> >value.
> > 
> >>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.
> > 
> >I prefer that Session-Expires MUST NOT be less than
> >2 minutes.  This helps accommodate for the retries of
> >200 and INVITE over UDP to get the session extended.
> >I'd actually prefer a higher value, but I assume
> >that some would be uncomfortable with the
> >"MUST NOT" part of the text if the value was higher.
> > 
> >In addition to the MUST NOT be less than 2 minutes,
> >I prefer the draft state that Session-Expires
> >SHOULD NOT be less 30 minutes for SIP messaging
> >that traverses a public network.
> > 
> >Based on the recommendation of sending refreshers
> >after 1/2 Session-Expires, the Session-Expires
> >triggered re-INVITEs MUST NOT occur more often
> >than every minute and SHOULD NOT occur more often
> >than every 15 minutes.
> > 
> >It might also be beneficial to mention in the draft
> >that support of the Session-Expires can lead to
> >more re-INVITE collisions, especially if the
> >Session-Expires value is small.
> 
> [Christer] I am still against the MUST NOT for the time value. If we
> define a 4xx (or if we use 488), with the Session-Expires 
> header telling
> the minimum value, there is no need to specify a minimum value in the
> standard. It's then up to the operator/network provider to specify a
> minimum value for his network, and configure the nodes to not 
> accept any
> value below that.

I agree.  The current plan is for the next revision of the draft to contain
that the session timer value SHOULD NOT be less than 30 minutes.

> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
>  
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementor's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to
> > [email-masked] with "subscribe" 
> in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 May 2001 08:56:31 +0300

Hi,

>a session-expires header.

True.

>>header telling the minimum value, there is no need to specify a minimum value in the
>>minimum value for his network, and configure the nodes to not accept any
>>value below that.
> 

That sounds fine.

Also, like you mentioned, we should explain in the draft the
disadvantages of using a low value, and why it is recommended not to use
a value less than 30 minutes. Otherwise we will soon have the same kind
of discussion on the list again.

Regards,

Christer Holmberg
Ericsson Finland