Subject: [sipcore] RFC4028 : Clarification of se-value in Section 7.4. Generating Subsequent Session Refresh Requests

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 24 Jun 2020 18:22:42 +0900

Hi,

7.4.  Generating Subsequent Session Refresh Requests
=====================================================================
In a session refresh request sent within a dialog with an active
session timer, the Session-Expires header field SHOULD be present.
When present, it SHOULD be equal to the maximum of the Min-SE header
field (recall that its default value when not present is 90 seconds)
and the current session interval.  Inclusion of the Session-Expires
header field with this value avoids certain denial-of-service
attacks, as documented in Section 11.  As such, a UA should only
ignore the SHOULD in unusual and singular cases where it is desirable
to change the session interval mid-dialog.
=====================================================================

1. Why SHOULD the Session-Expires header field be present?
A UA1 sent an initial INVITE without a Session-Expires header, then UA1 became a refresher.
UA1 didn't a session-timer, and so it did not add a Session-Expires header to the INVITE.
As a perspective of UA, adding a Session-Expires header means that it own  needs a session-timer.
But UA1 doesn't need it even now. In this situation, why SHOULD the Session-Expires header field be present?

2. What SHOULD the value be equal to?
In general, the maximum of the Min-SE header field is not equal to the current session interval.
It is ambiguous. In the first place, a UAC doesn't always know the exact maximum.

3.Why dose inclusion of the Session-Expires header field with this value avoid certain denial-of-service
attacks?

Section 11.1 says:
=====================================================================
Next, consider the case of a rogue UAS that wishes to force a UAC to
generate refreshes at a rapid rate.  In that case, the UAC has to
support session timer.  The initial INVITE arrives at the rogue UAS,
which returns a 2xx with a very small session interval.  The UAC uses
this timer and quickly sends a refresh.  Section 7.4 requires that
the UAC copy the current session interval into the Session-Expires
header field in the request.  This enables the proxies to see the
current value.  The proxies will reject this request and provide a
Min-SE with a higher minimum, which the UAC will then use.
=====================================================================

As I pointed out earlier, if the rogue UAS returns a 2xx with a very small session interval again, the attack will continue. IMO the important point is that UAs need to know the maximum value of the Min-SE header field in the dialog. According to the current regulations, only the UAS can know the maximum value. I think that 2xx response should include Min-SE header. And proxies should check it.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Jun 2020 10:17:51 -0400

> Session-Expires header field be present?

This is an optimization. Setting Session-Expires to an existing session
timer value avoids session timer re-negotiation and potential 422 responses.

> It is ambiguous. In the first place, a UAC doesn't always know the exact

It is the maximum of Min-SE set by UAC and the current Session-Expires
value for the dialog. UAC knows both.

3.Why dose inclusion of the Session-Expires header field with this value
> avoid certain denial-of-service
> attacks?
>
> Section 11.1 says:
> As I pointed out earlier, if the rogue UAS returns a 2xx with a very small
> session interval again, the attack will continue. IMO the important point
> is that UAs need to know the maximum value of the Min-SE header field in
> the dialog. According to the current regulations, only the UAS can know the
> maximum value. I think that 2xx response should include Min-SE header. And
> proxies should check it.
>

In general I agree but it is not an entirely backwards compatible change.
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 27 Jun 2020 18:59:16 +0900

Roman,

> timer value avoids session timer re-negotiation and potential 422 responses.

Even if there is no Session-Expires header, negotiation is always done.
And if the Min-SE header shows the maximum value in the dialog, then no 422 response will occur. In other words, the Session-Expires header has nothing to do with optimization.

> value for the dialog. UAC knows both.

My question is whether the value set in the Session-Expires header is the maximum of the Min-SE header field or the current session interval. Probably this is an editorial error.

> In general I agree but it is not an entirely backwards compatible change.

To address this security consideration, UAC needs to know the maximum value of the Min-SE header in the dialog.
I think there are following solutions.

1. UAS copies a Min-SE header into 2xx response for an initial INVITE. I think this procedure is adequately backward compatible.

2. When a dialog is established, UAS sends a session refresh request. This is an entirely backwards compatible.

3. When a dialog is established, UAC sends a session refresh request with low Min-SE or no Min-SE. UAC can know the maximum value of the Min-SE by 422 response. This is an entirely backwards compatible.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 27 Jun 2020 19:07:31 +0900

> Even if there is no Session-Expires header, negotiation is always done.
                    ^^
Even if there is a Session-Expires header, negotiation is always done.
                  ^

---

From: Roman Shpount <[email-masked]>
Date: Sat, 27 Jun 2020 18:45:09 -0400

On Sat, Jun 27, 2020 at 5:59 AM OKUMURA Shinji <[email-masked]>
wrote:

> Even if there is Session-Expires header, negotiation is always done.
> And if the Min-SE header shows the maximum value in the dialog, then no
> 422 response will occur. In other words, the Session-Expires header has
> nothing to do with optimization.
>

Min-SE value for the dialog is generally not known (even though it can be
cached from previous 422 responses).

In any case, the intent of the current RFC is to keep session timer
settings the same unless someone (proxy or UAS) needs to change them.

> My question is whether the value set in the Session-Expires header is the
> maximum of the Min-SE header field or the current session interval.
> Probably this is an editorial error.
>
> Session-Expires is the maximum of the current session expires interval and
Min-SE in the session timer refresh request.

In general, unless you have a real problem to fix, I would not want to see
anything changed. What you are proposing is a non-trivial change to the
protocol. Unless it serves some purpose, I do not think we should do it.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Jun 2020 19:50:59 -0400

On 6/27/20 6:45 PM, Roman Shpount wrote:
> On Sat, Jun 27, 2020 at 5:59 AM OKUMURA Shinji <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     And if the Min-SE header shows the maximum value in the dialog, then
>     no 422 response will occur. In other words, the Session-Expires
>     header has nothing to do with optimization.
> 
> 
> Min-SE value for the dialog is generally not known (even though it can 
> be cached from previous 422 responses).

This reminds me, one thing I always felt was lacking in 4028 is an 
explicit statement that adds SessionTimer state to the dialog state.

	Thanks,
	Paul

>      >> In general, the maximum of the Min-SE header field is not equal
>     to the
>      >> current session interval.
>      >> It is ambiguous. In the first place, a UAC doesn't always know
>     the exact
>      >> maximum.
>      >
>     My question is whether the value set in the Session-Expires header
>     is the maximum of the Min-SE header field or the current session
>     interval. Probably this is an editorial error.
> 
> Session-Expires is the maximum of the current session expires interval 
> and Min-SE in the session timer refresh request.
> 
> In general, unless you have a real problem to fix, I would not want to 
> see anything changed. What you are proposing is a non-trivial change to 
> the protocol. Unless it serves some purpose, I do not think we should do it.
> _____________
> Roman Shpount
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>