Subject: [sipcore] Draft new version: SIP Push -20

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Oct 2018 07:15:49 +0000

Hi,

Based on Robert’s comments, I have submitted a new version (-20) of draft-sip-push.

Regards,

Christer

---

From: Yehoshua Gev <[email-masked]>
Date: Mon, 22 Oct 2018 17:34:15 +0300

Hi,

I have some questions regarding the following sentences in section 5.3.2:
   If the contact of the REGISTER request does not match
   the Request-URI of the SIP request to be forwarded, or if the contact
   was not present in the REGISTER response, the proxy MUST reject the
   SIP request with a 404 (Not Found) response.  This can happen if the
   UA sends a binding refresh REGISTER request with a new contact at the
   same time the registrar forwards a SIP request towards a UA using the
   previously registered contact in the Request-URI.

a. What kind of matching should be done to capture the case of "the contact
   of the REGISTER request does not match the Request-URI of the SIP
request"?
   In case the incoming REGISTER request has a different Contact than the
   Contact of the postponed request, what will make the proxy assume that
   it is related to the postponed request?
   (I guess that a possible answer is that outbound or GRUU is used).

b. The last sentence give justification for rejecting the request, which
   I fail to understand. Say that the UA is using outbound and wishes to
   replace its Contact, why would we require the request to be rejected?

As an alternative, I suggest that there will be no explicit text about
rejecting the request, but rather requiring the proxy to perform the
regular routing logic again (after processing the REGISTER response) -
maybe with a restriction of not performing another push notification (to
avoid loops).
This will allow changing of the Contact as long as the proxy has logic for
correctly route the request to the UA.
This will also give a more precise response code (404 is misleading if
the UA's Contact was just replaced).

Additionally, I think that the text about matching the Request-URI with the
Contact should be relaxed, to allow matching using other methods (like
GRUU, outbound flow tokens, etc.), which are not necessarily done by
matching with the REGISTER's Contact.

Another small issue, with the following paragraph:
   In case of non-2xx response to the REGISTER request, the proxy MUST
   reject the SIP request with a 404 (Not Found) response.
Should we consider an attacker sending the REGISTER and being denied
by the registrar? If so, the proxy should not perform any action on non-2xx
responses.

Thanks,
Yehoshua

On Fri, Oct 19, 2018 at 10:16 AM Christer Holmberg <
[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Oct 2018 15:15:08 +0000

Hi,

>   of the REGISTER request does not match the Request-URI of the SIP request"?

We could add sentence saying that other methods can be defined to match the request, but that such methods are outside the scope of the document.

(For example, we have previously said that push-with-outbound would be described in a separate draft.)

But, no matter what method is used to match the request, if the proxy is going to request a push notification, I think that the PRID must always match.

> by the registrar? If so, the proxy should not perform any action on non-2xx

Assuming that the attacker has the information needed to match the request-to-be-forwarded with the REGISTER. 

...and that the proxy knows that the REGISTER is sent by an attacker to begin with.

Regards,

Christer

On Fri, Oct 19, 2018 at 10:16 AM Christer Holmberg <mailto:[email-masked]> wrote:
Hi,

Regards,
 
Christer
mailto:[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Oct 2018 15:18:32 +0000

Hi,

Note, though, that the submission cut-off date is today, so if we are going to add some text based on Yehoshua's comments I'd suggest to do it later. Because I'd really like to move the draft forward.

Regards,

Christer

On 22/10/2018, 18.16, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    

    

    Regards,
    
    Christer

    

    Regards,
     
    Christer

---

From: Yehoshua Gev <[email-masked]>
Date: Thu, 25 Oct 2018 12:54:53 +0300

Hi,

We could add sentence saying that other methods can be defined to match the
> request, but that such methods are outside the scope of the document.
>

Great.

>
> But, no matter what method is used to match the request, if the proxy is
> going to request a push notification, I think that the PRID must always
> match.
>

What would rejecting the call achieve?
If the UA has successfully sent a refresh REGISTER, it means it is alive
and probably
accessible.

According to the current wording of the draft, the actual request of the
push notification
is done statelessly - solely according to the PRID of the Request-URI.
If, at the same time (or just a moment before), the UA has changed its
PRID, the
push notification will probably fail.
Even in such case, I don't think that the proxy MUST reject the request,
due to the same reasoning that appear on the last paragraph of the section
("If the proxy has knowledge that the UA is awake..."). In all of those
cases,
the proxy has knowledge, as a refresh registration was just received.

> Assuming that the attacker has the information needed to match the
> request-to-be-forwarded with the REGISTER.
>
 I agree that it might be a bit far-fetched.

> ...and that the proxy knows that the REGISTER is sent by an attacker to
It might know it by the fact that the REGISTER was rejected by an upstream
entity.

Additional argument against rejecting - in some cases a rejected REGISTER
might
trigger an immediate refresh REGISTER (e.g., authentication, 423 Interval
too brief,
or some application-specific logic).

Thanks,
Yehoshua

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Oct 2018 10:23:35 +0000

Hi,

> If the UA has successfully sent a refresh REGISTER, it means it is alive and probably accessible.
>
> According to the current wording of the draft, the actual request of the push notification
> If, at the same time (or just a moment before), the UA has changed its PRID, the
> ("If the proxy has knowledge that the UA is awake..."). In all of those cases,

Fair enough, but I think that would be covered in a separate other-methods-to-match-the-request draft.

> It might know it by the fact that the REGISTER was rejected by an upstream entity.

If the REGISTER was rejected by the home proxy, the home proxy may not forward requests towards the UA either.

But, I guess what we can do is to say that REGISTER requests sent by an attacker, that are rejected, might prevent the proxy from forwarding requests.

> Additional argument against rejecting - in some cases a rejected REGISTER might
> trigger an immediate refresh REGISTER (e.g., authentication, 423 Interval too brief,

We can add a sentence saying that if the proxy expects a new REGISTER to arrive immediately (e.g., based on the response code of the rejected REGISTER), it might choose to not reject the request.

Regards,

Christer