Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Mickey's comments

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jan 2018 17:32:47 +0000

Hi Mickey,

Thanks for your review! Please see inline.

-- Major comment --

>Section 1:
>   The proxy can use the
>   receipt of the REGISTER request as a trigger to forward SIP request
>   towards the UA, using normal SIP routing procedures.
>
>Section  4:
>   If the SIP proxy triggered
>   the push notification because it wants to forward a SIP request
>   towards the UA, the receipt of the REGISTER request can be used by
>   the proxy as a trigger to forward the request.
>
>Section 5.3:
>   As the push notification will trigger the SIP UA to perform a re-
>   registration, the SIP proxy can use the receipt of the SIP REGISTER
>   request as a trigger to forward SIP request towards the UA.
>
> The SIP proxy should only be allowed to use the received (or generated if the Proxy contains the registrar functionality) 200 OK
> response to the REGISTER as a trigger to send on the queued message. Otherwise the proxy will be re-routing based on a unconfirmed 
> REGISTER request. If the reregister fails then the proxy has forwarded the INVITE or OOD request on to a contact URI that is not stored 
> in the registrar. This would likely cause the call to fail but also raises security concerns where a well-timed re-register with incorrect 
> SIP authentication by a 3rd party could "steal" a SIP message.

That's a good point.

Obviously, since the SIP request has been forwarded to begin with, the registration is considered active. But, some registration information may have changed in the triggered REGISTER request, and then the REGISTER needs to be accepted before the request is forwarded.

=====

-- Minor comments --

>Typo in Section 1. I think
>"Some are based on there standardized mechanism..."
>Should be
>"Some are based on the standardized mechanism..."

Will fix as suggested.

>Section 1
>Consider adding a mention of the feature capabilities indicator.

Will be added.

>Section 3
>Consider clarifying that PRID need only be unique per PNS. Also consider clarifying that this mechanism is only 
>appropriate for notification systems that provide such a token.

I think all notification systems provide some kind of token (otherwise, how would the push notification be routed?). But, I can add a note clarifying it.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of A. Jean Mahoney
Sent: 25 January 2018 20:35
To: SIPCORE <[email-masked]>
Subject: [sipcore] WGLC: draft-ietf-sipcore-sip-push

Hi all,

Working Group Last Call starts today for draft-ietf-sipcore-sip-push.

https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/

Please provide any feedback to the sipcore mailing list by Friday, February 9th.

Thanks!

Jean

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