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

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

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
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip