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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 03:22:47 -0400

Folks,

Whilst writing up a discussion of the smurf attack for the session-timer
spec, I ran into a problem.

We added the ability for a proxy to reject a request if the session timer
was too low. Consider the case of a UAC A, two proxies B and C, and UAS D. A
sends an INVITE, with Supported: timer. It lists a value of 1 hour. This
hits proxy B. B feels this is too long, and wants the 30 minute minimum. So,
it reduces it. That hits C. C feels this is too short, below its 45 minute
minimum. So, it rejects the request, and includes a session-expires header
with 45 minutes. 

So, A resends the request, with a session-expires of 45 minutes. This, once
again, is too short for B, which reduces it to 30 minutes, and passes it to
C. C rejects it because its too long, and includes a session-expires header
with 45 minutes.

This will then continue ad-infinitum. Its also a nice DoS attack in and of
itself.

Dean raised this issue a while back. I had suggested the ability of a proxy
to increase the session-expires, and then include a header, say
Minimum-Timer, which indicates its minimum value that no one else can reduce
it below. He pointed out that you have problems, then, if two proxies have
non-overlapping preferences. Well, we still have that problem. The result of
the 422 rejection response is that proxies can, effectively, increase the
value of the session timer, so the same problem arises.

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. 

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!

-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
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jun 2001 18:55:38 +0300

Hi,

I think that the Minimum-Timer header could work.

However (forgive me if this issue has been raised and discussed before),
the UAC now does not know due to WHICH proxy the minimum value exists.
Maybe that proxy didn't insert a Record-Route, so the re-INVITEs would
never reach that proxy, so it doesn't matter what its minimum value is.
I guess this problem exists no matter if the Minimum-Timer header is
used or not, though, since a proxy can always return 422 if the received
value is too small.

One option would be to add a rule in the spec, saying that a proxy that
does modify the Session-Expires header, OR sends 422, also MUST insert
itself in the route. It may sound obvious, but I think it should be
written somewhere (unless it isn't allready...).

Comments?

Christer Holmberg
Ericsson Finland

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 21 Jun 2001 19:37:05 -0400

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

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.

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

> front of the attacking proxy to reject the low values inserted by the

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.  
If you are suggesting the use of the same 
Minimum-Timer header to avoid the 422's, I agree.

_______________________________________________
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