[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] new open issue in session timer: NEEDS resolution now!
Hi,
Just a small correction to my previous mail.
In the second chapter it should be "The UAC will have to send a new
request", instead of "The UAC will not have to send a new request".
Regards,
Christer Holmberg
Ericsson Finland
Christer Holmberg wrote:
>
> Hi,
>
> The issue is not about which proxy is complaining, but that a proxy that
> will not be in the call path may affect the session-timer value in a
> negative way.
>
> For example, it may decrease the value, which the next server (proxy or
> UA), which WILL be in the call path, does not except, so it will send
> 422. The UAC will not have to send a new request, even if the original
> value given in the first request would have been accepted by all parties
> that will be in the call path, but the "non path" proxy decreased it.
>
> I don't see this as a big problem, but as a bad situation that MAY
> occure, so that's why I was wondering if it at least in the draft could
> be RECOMMENDED that proxis that do not insert Record-Route will not care
> about the session-timer value.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > > Sent: Monday, June 18, 2001 11:56 AM
> > > To: Jonathan Rosenberg
> > > Cc: 'sip@ietf.org'
> > > Subject: Re: [Sip] new open issue in session timer: NEEDS resolution
> > > now!
> > >
> > >
> > >
> > >
> > > 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.
> >
> > I don't understand the problem. Why does it matter which proxy was the one
> > that complained? Even if the one that complained is not on the route, so
> > what? The call will still succeed; perhaps with a larger timer than might
> > have been needed, but this is an oddball case we are talking about.
> >
> > >
> > > 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...).
> >
> > Again, I don't understand the problem you are trying to fix.
> >
> > -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
> >
> > >
> > > 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