Subject: Re: [sipcore] 4028bis: forking

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 1 Jun 2020 18:56:45 +0900

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 <[email-masked]> 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
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Jun 2020 13:02:40 -0400

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 <[email-masked]> 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.
>
> 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.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 2 Jun 2020 10:51:05 +0900

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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>      > OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> writes:
>     [email-masked] <mailto:[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Jun 2020 02:16:51 -0400

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 <[email-masked]> 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
>
> > 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.
> >
> >     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.
> >

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 2 Jun 2020 16:49:02 +0900

Roman,

> 2. Proxy cannot generate 422 response

I'm not suggesting that proxy cannot add Session-Timer. The use of "should not" may not have been appropriate. I think it is a requirement levels issue.
How about rephrasing it as follows?

"A UAC and proxies MAY add a Session-Expires header, but it is NOT RECOMMENDED."

Obviously, legacy proxies add a Session-Expires header, so another proxy need to be prepared for that.

Shinji

On 2020/06/02 15:16, Roman Shpount wrote:
> On Mon, Jun 1, 2020 at 9:51 PM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Roman,
> 
>      > On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi,
>      >
>      >      > OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> 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
>      >      >
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Jun 2020 04:18:24 -0400

Shinji,

Proxies adding Session-Expires header is the primary reason for existence
of SIP Session Timers. This header is added almost exclusively by proxies
in order to maintain dialog state.

Because of this, your proposal makes no sense to me.

As I have said, I would much rather see parallel forking dropped from
supported scenarios.
_____________
Roman Shpount

On Tue, Jun 2, 2020 at 3:49 AM OKUMURA Shinji <[email-masked]> wrote:

> I'm not suggesting that proxy cannot add Session-Timer. The use of "should
> not" may not have been appropriate. I think it is a requirement levels
> issue.
> >     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
> >
> >      > 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.
> >      >
> >      > 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 <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> 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
> >      >     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.
> >      >
> >      >      > OKUMURA Shinji <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>> writes:
> >      > [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>