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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 02:26:47 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 7:37 PM
> To: 'Jonathan Rosenberg'; [email-masked]
> 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
[email-masked]                     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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 26 Jun 2001 15:21:31 -0400

> You're going to have troubles using session-timer for 

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

> However, I think the more common case is a constant 

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.