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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2001 02:03:52 -0500

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 10:40 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session-timer: refresh rate)
> 
> 
> >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.
> 
> 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. 

No, that doesn't help. A rogue proxy could still reduce the value of the
"minimum timer value" header, even though its not supposed to. Mandating
that the clients never send faster than X, means that no rogue proxy or UA
could ever cause a session timer refresh to be used as an attack.

Because, no matter if there is a minimum value or not, one can
> hack his/her client to send re-INVITEs every second...

That is not the point. The point is whether an attacking device can
introduce an amplification attack against existing, compliant devices. With
current session timer, they can.

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

No.

We have discussed this before. One of the core concepts in sip is the
"soft-state" nature of INVITE. It is fundamental to the operation of these
soft-state kinds of protocols that the thing which initializes the state
looks the same as the things that refresh it. We have obtained huge benefits
towards removing state from the core as a result of this property, and thats
the reason its there.

At a minimum rate of 30 minutes, I really don't care about an extra ACK.

-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: Wed, 21 Mar 2001 09:51:15 +0200

Hi,

>could ever cause a session timer refresh to be used as an attack.

As much as a proxy can reduce the value, even it it's not supposed to, a
client can send faster than X, even it it's not supposed to...

I do belive, however, than an operator will not have this problem in his
network, since he will control all his proxies. This problem will only
come up if I plug my phone to the internet and call someone "directly"
via some "public" proxy server, or something. And, if that proxy starts
to do strange things people will probably stop using it... In other
words, I personally don't think that I am going to reach unwanted and
unknown proxies - instead I think that "hacker" clients will be a bigger
problem.

>current session timer, they can.

Yes, but are you sure that introducing a minimum value will solve this?

>>>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.
>>
>>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
>>headers (To, From, Call-ID), and of course the mandatory headers (CSeq, Route,
>>Via,....).
> 
>No.
> 

Well, the purpose of the ping would NOT be to refresh the state. From a
SIP core point of view, it would
only be to ping the call, ie get 200 if the call exists, or 481 if it
doesn't. Overlaying applications, ie a charging application, can then
use this to update whatever internal state that specific application may
have.
 
>At a minimum rate of 30 minutes, I really don't care about an extra ACK.

No, but the issue was if someone - for whatever reason - wants to use a
lower rate.

Regards,

Christer Holmberg
Ericsson Finland