[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] new open issue in session timer: NEEDS resolution now!
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