Re: [sipcore] 4028bis: forking

[OKUMURA Shinji <[e-mail]>]

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
>