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

["Brett Tate" <brett@broadsoft.com>]

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

I agree.  However I assume that there are 
products and services that might desire using 
Session-Expires for quicker cleanup on errors when 
predetermine max length of session happens to be 
smaller than the acceptable 
minimum-session-expires value.  The "none" value 
of the refresher parameter would easily accommodate 
such a thing.

http://www.ietf.org/mail-archive/working-groups/sip/current/msg00168.html

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

The text that I was questioning was the part about
- 
  without inserting the same timer value in subsequent 
  re-invites, it opens the call-leg up to smurf attack.
-
The same smurf attack will always exist when the 
proxy returns small timer values to the refresher 
without having added/proxied the small value forward.  
(Note: This attack is performed by malicious proxies 
since that draft requires proxies to added their 
session-expires modifications in the request before 
blindly/maliciously adding them in the response.)


A---P1-----P2------B (INVITE/reinvite direction A to B)

If your concern was with A or P1 being able to 
reject a session-expires added by P2 or B; then 
minimum-session-expires can be added/updated by A 
or P1 in the INVITE/re-INVITE.  It sounds like 
minimum-session-expires should be added/updated 
in INVITE/re-INVITE by all proxies/UACs that are 
concerned or do not intend to honor small 
session-expires values that could otherwise added 
by P2 or B.  The minimum-session-expires value in 
a request can be increased but not decreased as it 
traverses proxies.


_______________________________________________
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