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

From: Steve Donovan <[email-masked]>
Date: Tue, 8 May 2001 11:48:31 -0400

I don't think we have reached consensus on this thread.

The fundamental problem is that the session timer draft does not adequately
address the potential smurf attack by a rouge UAC or proxy.  

Two solutions have been proposed:

1) Jonathan proposes defining a minimum value for session timer, with all
requests containing a smaller value being rejected.  

2) Dean, and others, propose that we make it a policy decision for each
entity in the SIP network to determine what is a reasonable minimum.

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

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.  

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.

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

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Thu, 10 May 2001 16:22:35 -0400

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 May 2001 16:10:06 +0300

Hi,

Some comments.

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

Regards,

Christer Holmberg
Ericsson Finland