Re: [sipcore] 4028bis: forking

[Roman Shpount <[e-mail]>]

Shinji,

I have an issue with two of your proposals:

1. Proxy cannot add Session-Timer
2. Proxy cannot generate 422 response

Both break session timer as it is implemented and used now.

Best,
_____________
Roman Shpount


On Mon, Jun 1, 2020 at 9:51 PM OKUMURA Shinji <[e-mail]> wrote:

> Roman,
>
> Three(b, c, d) of my suggestions are the same as RFC4028. The last one(a)
> also does not violate the RFC4028. Therefore, this situation can occur even
> with the current regulations.
>
> And rules regarding Min-SE have not changed. Even without using the 422
> response, proxies can indicate the desired Min-SE to a UAS. So if there is
> a security risk, it means that the RFC4028 has the same risk.
>
> Regards,
>
> Shinji
>
> On 2020/06/02 2:02, Roman Shpount wrote:
> >    Shinji,
> >
> > The main purposes of session timers is to allow SIP proxies to maintain
> dialog state for billing and other purposes. Proxies are the main agents
> that insert Session-Expires header. In most cases there is no reason for UA
> to use session timers since they can normally monitor call presence without
> it. Your proposal makes the most common use case for session timers
> impossible.
> >
> > Min-SE exists mainly for the purpose of preventing badly behaving
> proxies or UA from overload proxies on the call path or UAS. Not allowing
> proxy to send 422 creates a big security risk.
> >
> > My general attitude is that parallel forking is broken for a lot of use
> cases anyway, so it should be avoided. I do not think a lot of production
> deployments are actually use parallel forking. Most of the UA would not
> handle multiple 200 OK responses that can be created as a result of
> parallel fork. Session timers are, on the other hand, are used a lot. So I
> would prefer to live with broken or under-specified parallel forking vs
> breaking session timers.
> >
> > Thank You,
> > _____________
> > Roman Shpount
> >
> >
> > On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >     Hi,
> >
> >     I've not intended to suggest a common solution to the fork-issue. I
> am interested in how the fork does not happen. It is related to the
> behavior of proxies and a UAS in the 1st phase that you mention. My
> suggestion is that a UAS and proxies SHOULD avoid returning 422 as much as
> possible.
> >
> >     Considering backward compatibility, rules are as follows.
> >
> >     a) A UAC and proxies should not insert a Session-Expires header.
> >     b) A UAC and proxies may insert a Min-SE header or increase the
> value of it.
> >     c) A UAS may insert a Session-Expires header into a 200 response.
> >     d) A proxy may insert a Session-Expires header into a 200 response,
> but must not modify it.
> >
> >     Of course legacy proxies will return 422, but this is unavoidable.
> >     In that case, the following rule may be useful.
> >
> >     e) If a proxy increases the value of a Min-SE header and it becomes
> greater than the value of a Session-Expires header, then a proxy should
> increase the value of a Session-Expires header to the value of a Min-SE
> header.
> >
> >     However, this rule can be problematic in terms of backward
> compatibility.
> >
> >     Shinji
> >
> >     On 2020/05/29 11:30, Dale R. Worley wrote:
> >      > OKUMURA Shinji <[e-mail] <mailto:
> [e-mail]>> writes:
> >      >> As you point out, the other responses(407, 420, ...) cause the
> same problem.
> >      >> But session-timer is essentially a kind of pre-condition, so I'd
> like
> >      >> to avoid incoming calls to fail because of it. And I'd like to
> sort
> >      >> out also the rules in early dialog.
> >      >
> >      >> On 2020/05/27 19:16, Christer Holmberg wrote:
> >      >>> A proxy rejecting a request is not unique to the session-timer.
> >      >>>
> >      >>> If Alice receives a 422 she can send a CANCEL (if other early
> dialogs
> >      >>> have been established), and then a new initial INVITE.
> >      >
> >      > (This has a larger scope than just session-timers.)
> >      >
> >      > I don't know if the above writers intended this point, but
> reading what
> >      > they have said suggests to me this possible behavior for proxies
> (which
> >      > I don't recall seeing suggested):
> >      >
> >      > Note that 422 is one of a number of "pre-condition failure"
> response
> >      > codes.  Those have the properties (1) when they are generated,
> they are
> >      > generated nearly immediately from the INVITE, and (2) the UAC can
> adjust
> >      > the INVITE to prevent them.
> >      >
> >      > Suppose that if a proxy receives one of these "pre-condition
> failure"
> >      > responses, it immediately (or with short delay on a human scale)
> cancels
> >      > all remaining forks of the transaction and returns the failure
> response
> >      > upstream.
> >      >
> >      > The effect is to split the "early dialog" phase into two
> sub-phases, (1)
> >      > a very short phase where the forking of the INVITE effectively
> probes
> >      > for proxies and UASs that object to the the INVITE for
> "pre-condition"
> >      > reasons, and (2) a longer phase which resembles the current early
> dialog
> >      > phase.
> >      >
> >      > There are probably refinements needed to make this work in all
> cases.
> >      >
> >      > Dale
> >      >
> >
> >     _______________________________________________
> >     sipcore mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/sipcore
> >
>