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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 9 Apr 2001 19:18:11 -0400

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, April 09, 2001 6:43 PM
> To: Jonathan Rosenberg; [email-masked]; [email-masked]
> Subject: Re: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 
> 
> Lower "sanity" bounds in UA1 or UA2 have the opportunity to 
> correct the
> situation.
> 
> An interesting point -- (in the absence of reply modification) the
> session-timer approval process appears to give the proxy 
> closest to the
> terminating UA significantly more "say" about the session 
> timer value. 

Yes. That is the essense of the problem, for which this Min-Timer header (or
whatever I had called it) was meant to solve. 

> Of
> course, a rogue proxy could just retransmit INVITES as often 
> as it wants, no
> need to have the UA do it on its behalf by munging 
> session-timer  

Not true at all! Getting someone else to send lots of packets, without
having to do it yourself, is the essence of smurf attacks. I have described
in a previous note, a very nice attack which can bring down an origination
provider network:

http://lists.bell-labs.com/pipermail/sip/2001q2/006528.html

Also, there are really TWO separate problems here:

1. how to deal with the case, where all elements are cooperating, and we
want to make sure that the session timer is not lower than the minimum of
the smallest allowed timers across all proxies. For that, this Min-Timer
value has been proposed.

2. how to deal with the case where a rogue proxy or UA can use session timer
to launch attacks against network elements.

> However, another edge condition may result -- perhaps one 
> proxy tolerates a
> session-timer value (T)  in the range A<T<B, and another 
> tolerates C<T<D,
> where A<B<C<D. That is to say, it is possible that NO value 
> of session-timer
> is acceptable to all proxies. On the other hand, NO 
> negotation protocol can
> meet these requirements . . . . so I guess we need 
> bidirectional negotation
> to be able to detect it.

Ouch... I'd rather not go down that avenue.

In this case, I'd rather enforce the lower limit above the higher one. That
is, the proxy who wants A<T<B loses, and the timer is set at C.

-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

> ----- Original Message -----
> From: "Jonathan Rosenberg" <[email-masked]>
> To: "'Dean Willis'" <[email-masked]>; "Jonathan Rosenberg"
> <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Wednesday, April 04, 2001 9:04 AM
> Subject: RE: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Dean Willis [mailto:[email-masked]]
> > > Sent: Wednesday, April 04, 2001 3:16 AM
> > > To: Jonathan Rosenberg; [email-masked]; 
> [email-masked]
> > > Subject: Re: [SIP] Session timer considered harmful (was RE:
> > > draft-ietf-sip-session- timer: refresh rate)
> > >
> > >
> > >
> > > Yes, but if each of the proxies along the path knows what its
> > > safe "lower
> > > bound" on retransmits is and refuses to pass a session timer
> > > with a value
> > > lower than the safety threshold, the attack can be avoided.
> > > This isn't a
> > > protocol change.
> >
> > No, thats not true. Consider the case of:
> >
> > UA1 -> P1 -> P2 -> P3 -> UA2
> >
> > UA1 requests session timer. Its OK to P1. Goes to P2, which 
> thinks it too
> > low. P2 increases it. Now the request goes to P3, which 
> reduces it to an
> > even lower value. This is forwarded to UA2, which reflects it in the
> > response, and its forwarded upstream towards UA1. I guess 
> P2 could discard
> > the response, but thats not really a good thing, since the 
> transaction
> will
> > end up timing out. Even then, rogue P1 could reduce the 
> timer value in the
> > response once its passed P2.
> >
> > -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.
> 

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Mon, 9 Apr 2001 19:11:37 -0500

Ok, if a proxy doesn't stay in the route, it has no need to set the
session-timer value, right?

If a proxy DOES stay in the route, there's no amplifier effect because the
proxy that set the low timer is still being forced to forward the results .
. .

What you really seem worried about is a proxy, in the path ONLY during the
first INVITE, using session-timer to gain amplification via each of the
terminal nodes for each call transiting that proxy.

So, could we tie the ability to set session-timer to record-route?

--
Dean

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "'Dean Willis'" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, April 09, 2001 6:18 PM
Subject: RE: [SIP] Session timer considered harmful (was RE:
draft-ietf-sip-session- timer: refresh rate)