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

[Christer Holmberg <christer.holmberg@lmf.ericsson.se>]

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



Jonathan Rosenberg wrote:
> 
> 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
begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard