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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Mar 2001 02:45:09 -0500

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 2:42 PM
> To: [email-masked]
> Subject: draft-ietf-sip-session-timer: refresh rate (was 
> draft-RE: [SIP]
> SIP Registration interval)
> 
> 
> > 
> > The only issue is how the server can differentiate between small
> > registration lifetimes which are useful for some services 
> > (and should be
> > allowed), and small registration lifetimes that will be used 
> > continuously
> > (which the server may want to disallow). I would suggest that 
> > the two cases
> > can be differentiated, if needed, by heuristics at the 
> > registrar. When a
> > contact is registered with a lifetime below X, its accepted, 
> > and the server
> > increments a counter for this registration. Everytime that 
> contact is
> > refreshed in less than X seconds, the counter is bumped. If 
> > it exceeds N,
> > the server can return some larger expiration time in the next 
> > refresh. 
> > 
> > This works assuming that short lived registrations for these 
> > services are
> > "one-shots", which seems to be the case so far.
> > 
> 
> The suggested method works for registrations.
> 
> Are people opposed to allowing for the same 
> rule within the Session Timers draft as a 
> means for a stateful proxy or UA to request 
> a reduction of session extending re-INVITEs?

Well, session timer is actually a different problem.

Its different because there are multiple entities which can modify the
timer. If you consider the case where a proxy can increase it, and the
client simply uses what is returned, it doesn't help. Lets say the client
picks a value that is too small, say timer1. Proxy P1 gets this, and raises
it to an acceptable level, timer2. It proxies the request. It arrives at
proxy P2. P2 lowers it back to timer1. This value is reflected in the 200
OK. Now, the client ends up using timer1, even though this was too small for
P1.

This is actually a harder problem to solve. You could start by adding a
response code which is "timer too small", and then include a new header in
the response with the minimum timer. This actually doesn't solve the problem
above.

A slightly better approach is to allow proxies to insert a header into
proxied requests which indicates their minimum allowed value; proxies can
increase the value in this header, but not decrease it, and then decrease or
increase the timer itself, but not below this value. That works in a
cooperative environment.

In a non-cooperative environment, session timer turns out to be a really
nice DoS attack. It provides unlimited amplication capabilities. It is
possible to use rogue proxies, UACs, or UASs to cause other elements to send
periodic refreshes of the INVITE at fairly fast rates. I don't think session
timer adequately addresses this problem. Right now, it says to use IpSec
between elements. Thats not going to be likely between the UA and proxies,
and these attacks can be launched from a UAC or UAS as well.

Session timer also has a huge impact on performance of systems, even in
legitimate applications. If I send session timer at a rate of every 1.5
minutes, given average call hold times of 3 minutes, my overall call per
second processing rate of proxies is reduced by a factor of two.
Unfortunately, this penality is suffered by ALL proxies that record-route,
even ones that don't care about session timer.

My proposal to fix this is a bit radical, but here goes. I'd like to put
into the spec a minimum session timer value. A client never runs session
timer more frequently than this interval. I would propose that this value be
on the order of 30 minutes.

Folks who have it in their heads to use session timer as a tool to assist in
per-minute billing won't like that. However, I would argue that per-minute
billing is associated not with sip, but with gateway services, and that
these gateways can determine call durations far more effectively through
RTCP and media path characteristics. Session timer is handy for elements
within the network which need a way to discard state that they create, in
the event BYE is not sent. For those cases, I think timeouts on the order of
30 minutes are reasonable.

I'm sure this will invite plenty of flames. We can discuss some more during
IETF as well. Its already on my open issues list.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
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: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2001 17:39:43 +0200

Hi,

My comment is only on Jonathan's session-timer change proposal.

>on the order of 30 minutes.

I am not sure if that is needed (it could be RECOMMENDED, though), if we
define the "timer too low" header. Then the proxy administrator can
choose to use a minimum value of 30 minutes, 60 minutes or whatever he
wants. Because, no matter if there is a minimum value or not, one can
hack his/her client to send re-INVITEs every second...

>30 minutes are reasonable.

This is one of the things I many times have said I think re-INVITEs are
"too heavy" for, ie to send all headers, session description(s), and who
knows what, in short intervals only to ping that the call is alive. This
is something that the "PING" method I've been talking about could be
used for, ie a method that basically only contains the call headers (To,
From, Call-ID), and of course the mandatory headers (CSeq, Route,
Via,....).

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 27 Mar 2001 15:23:13 -0600

I would suggest an even simpler approach -- guidance to implementors that
suggests they implement a configuration variable to treat session-timer
values below that variable's value as having that value, and guidance to
operators on the tuning of that value. As session-timer is only intended as
a guideline for how long state should be kept on an inactive call, there's
no real harm in (beyond state preservation load) in keeping it a little
longer. This allows the lower-bound in effect to be defined on a a
per-network, per device basis and adjusted for operator requirements.

If someone's rogue UAC decides to start resending INVITES every few
milliseconds, no specification can stop it from doing so. That's like trying
to legislate rainfall . . .

--
Dean

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, March 16, 2001 1:45 AM
Subject: [SIP] Session timer considered harmful (was RE:
draft-ietf-sip-session- timer: refresh rate)