RE: [Sip] new open issue in session timer: NEEDS resolution now!

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Thursday, June 21, 2001 7:37 PM
> To: 'Jonathan Rosenberg'; sip@ietf.org
> Subject: RE: [Sip] new open issue in session timer: NEEDS resolution
> now!
> 
> > The only sensible out that I see is to add back this 
> > Minimum-Timer header. A
> > UAC, when it gets a 422 Session Timer too small, remembers 
> > the value of the
> > Session-Expires in that response. It stores the largest value 
> > returned in
> > any 422 for the call leg in question. In any re-invites with 
> > session timers,
> > the UAC includes a Minimum-Timer header with this value. A 
> > proxy MUSTNOT
> > reduce the session timer below this value. 
> >
> 
> Using the 422 and Minimum-Timer sounds fine with 
> me.  It solves the problem while allowing for 
> Session-Expires negotiation.

OK, great.

> 
> The header name is also ok since the option-tag 
> for the draft is "timer".  Minimum-Session-Expires 
> seems a little more precise, but it is little 
> longer.

How about Min-SE?

> 
> Intentional or not, the solution reduces the 
> possibility of smaller Session-Expires values 
> that might want to be used in pre-paid services 
> through proxies.  

You're going to have troubles using session-timer for duration-based billing
for prepaid anyway.

> However I guess that it is 
> better than adding a parameter to
> Session-Expires to indicate that the session 
> will not or cannot be extended; thus please 
> allow this small value.  The parameter would
> also guarantee faster cleanup of sessions known 
> to be of a predetermined short length.

The minimum of 30min that we have discussed is a SHOULD, not a MUST. You can
put 1 minute in there if you want, and if none of the proxies object with a
422, you're good to go.

> 
> > I welcome any other suggestions....
> > 
> > Another requirement for this to work is that, when a UA 
> refreshes, it
> > inserts a session-expres with the same timer as the previous 
> > successful
> > re-INVITE, unless it explicitly wishes to disable session 
> > timers. Without
> > that, the smurf attack is still possible! Thats because, if 
> > each re-invite
> > doesn't contain the last session timer, no request will 
> actually ever
> > contain a session-expires, and so there is no opportunity for 
> > a proxy in
> > front of the attacking proxy to reject the low values 
> inserted by the
> > attacking proxy!
> 
> I'm not sure that I understand your reasoning 
> for requiring the same Session-Expires for 
> re-INVITEs that were in the previous INVITE.  
> Can't the whole renegotiation process take 
> place again among the entities that stayed 
> in the route?  This would force the smurf 
> requesting small values to stay in the route.  

Thats true, but I don't consider this sufficient deterrent for this attack
to be prevented. In any case, the session-expires can still be renegotiated.
However, I think the more common case is a constant session-timer for the
call leg anyway.

> If you are suggesting the use of the same 
> Minimum-Timer header to avoid the 422's, I agree.
> 

No, it was the same Session-Expires, not Minimum-Timer.

-Jonathan R.


---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip