[sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-sip-push-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5114



DETAIL
S 5.3.2.
>      request) addressed towards a SIP UA, if the Request-URI of the
>      request contains a pn-provider, a pn-prid and a pn-param (if required
>      for the specific PNS provider) SIP URI parameter, the proxy requests
>      a push notification towards the UA, using the PRID included in the
>      pn-prid SIP URI parameter and the PNS identified by the pn-provider
>      SIP URI parameter.

Maybe I'm missing something, but this seems like it leaves open the
possibility for the PRID to not match the rest of the URI. E.g.,
suppose that [e-mail] and [e-mail] both register with the
same proxy/registrar pair with PRIDa and PRIDb respectively. What
stops the registrar from generating (or forwarding) a call to
[e-mail], PRIDb? And what happens if that happens?


S 5.3.2.
>      also present (and has not expired) in the REGISTER response, the
>      proxy can forward the SIP request towards the UA, using normal SIP
>      procedures.  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

How does this happen? I.e., how does the the REGISTER get correlated
with the SIP request to be forwarded in order to execute this
requirement?


S 6.1.
>      and be able to find and retrieve that information when it receives a
>      mid-dialog request.  This section defines such mechanism.  The UA and
>      proxy procedures in this section are applied in addition to the
>      generic procedures defined in this specification.
>   
>   6.1.  SIP UA Behavior

This section needs some kind of diagram that explains what the
mechanism is. I've read it a bunch of times, and I still don't
understand it.


S 6.2.1.
>      generated key as the value to the associated 2xx REGISTER response.
>   
>      The PURR value MUST be generated in such a way so that it cannot be
>      used to retrieve information about the user or associate it with
>      registrations.  It can be generated e.g., by utilizing a
>      cryptographically secure random function.

This seems to weak. I assume you also don't want it to be possible to
determine that two PURRs correspond to the same user. Also who must be
able to use it in this way. Presumably the proxy can?

Why is this not a requirement for say PRID?






S 13.
>      specification.  Web push permits the sending of a push message
>      without a payload without encryption.
>   
>   13.  Security Considerations
>   
>      Different mechanisms exist for authenticating and authorizing devices

You need to discuss the security implications of knowledge of the push
parameters (principally PRID). What happens if an attacker learns
htem?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------




This document is very badly in need of editorial work for readability.
I would urge the responsible AD to make one.


S 1.
>      used to wake such applications, nor will incoming network traffic
>      wake the application.  Instead, one way to wake the application is by
>      using a Push Notification Service (PNS).  Typically each operating
>      system uses a dedicated PNS.  For example, Apple iOS devices use the
>      Apple Push Notification service (APNs) while Android devices use the
>      Firebase Cloud Messaging (FCM) service.

What is a Push Notification Service? I mean, I know, but you need to
say.


S 1.
>      will request push notifications towards the UA.
>   
>      When the proxy receives a SIP request for a new dialog or a stand-
>      alone SIP request addressed towards a UA, or when the proxy
>      determines that the UA needs to send a binding-refresh REGISTER
>      request, the proxy will request a push notification towards the UA,

"request ... towards" is ungrammatical


S 1.
>            |<---------------------|                         |
>            |                      |                         |
>            |          SIP REGISTER (Push Resource ID)       |
>            |===============================================>|
>            |                      |                         | SIP REGISTER
>            |                      |                         |============>

These arrows don't seem to go anywhere. I think you need to label the
registrar.


S 4.1.
>   
>      NOTE: The VAPID specific procedures of the SIP UA are outside the
>      scope of this document.
>   
>      When the UA receives a push notification, it MUST send a binding-
>      refresh REGISTER request, using normal SIP procedures.  If there are

This seems unnecessarily restrictive. Are we never going to want any
other kind of push notification?


S 4.1.
>      protocol is used, the SIP request might reach the UA before the
>      REGISTER response.
>   
>      NOTE: The lifetime of any NAT binding created by the REGISTER request
>      only needs to be long enough in order for the SIP request that
>      triggered the push notification to reach the UA.

This general architectural point should be made further up.


S 4.1.
>      [RFC3840] in each Contact header field URI of each REGISTER request.
>      Then, if the response to the REGISTER request contains a 'sip.pnsreg'
>      feature-capability indicator with an indicator value, the UA
>      refreshes the binding prior to the binding expires.  The indicator
>      value indicates a minimum time (given in seconds), prior to the
>      binding expires when the UA MUST send the REGISTER request.  Even if

This sentence needs a rewrite.


S 4.1.
>      Then, if the response to the REGISTER request contains a 'sip.pnsreg'
>      feature-capability indicator with an indicator value, the UA
>      refreshes the binding prior to the binding expires.  The indicator
>      value indicates a minimum time (given in seconds), prior to the
>      binding expires when the UA MUST send the REGISTER request.  Even if
>      the UA is able to to send REGISTER requests using a non-push

"to to"

Also, all UAs that are conformant to this specification are able to
send REGISTERS via a non-push as the first register is sent that way.


S 4.1.
>      capability indicator, the UA SHOULD only send a re-registration
>      REGISTER request when it receives a push notification (even if the UA
>      is able to use a non-push mechanism for sending re-registration
>      REGISTER requests), or when there are circumstances (e.g., if the UA
>      is assigned new contact parameters due to a network configuration
>      change) that require an immediate REGISTER request to be sent.

This text doesn't seem correct. If the initial response doesn't
contain "sip.pns" then you probably would still want to send regular
REGISTERs


S 4.1.
>      change) that require an immediate REGISTER request to be sent.
>   
>      NOTE: If the UA uses a non-push mechanism to wake and send a binding
>      refresh REGISTER request, such REGISTER request will update the
>      binding expiration timer, and the proxy does not need to request a
>      push notification towards the UA in order to wake the UA.  The proxy

This doesn't seem obviously correct. Why is this so?


S 4.1.
>      REGISTER request.
>   
>      If the UA no longer wants to receive push notifications (requested by
>      the proxy), the UA MUST send a binding-refresh REGISTER request
>      without including the SIP URI parameters described above, or the UA
>      MUST remove the registration.

This seems pretty hard to conform with, given that mobile applications
are often just shut down with no warning.


S 4.1.
>      document.
>   
>      For privacy and security reasons, the UA MUST NOT include the SIP URI
>      parameters defined in this document in non-REGISTER request, to
>      prevent the PNS information associated with the UA from reaching the
>      remote peer.  For example, the UA MUST NOT include the SIP URI

For non-SIP experts, why is this not an issue with REGISTER?


S 5.2.
>      the registrar using some mechanism.  Such mechanisms are outside the
>      scope of this document, but could be implemented e.g., using the
>      SIPregistration event package mechanism [RFC3680].
>   
>      When the proxy receives an indication that the UA needs to send a
>      binding-refresh REGISTER request, the proxy requests a push

You need to define what such an indication is.


S 5.2.
>      scope of this document, but could be implemented e.g., using the
>      SIPregistration event package mechanism [RFC3680].
>   
>      When the proxy receives an indication that the UA needs to send a
>      binding-refresh REGISTER request, the proxy requests a push
>      notification towards the UA.

"requests...towards" again


S 5.2.
>      If the UA has indicated, using the 'sip.pnsreg' media feature tag,
>      that it is able to wake using a non-push mechanism for sending
>      binding-refresh REGISTER requests, if the proxy does not receive a
>      REGISTER request prior to 120 seconds before the registration
>      expires, the proxy MAY request a push notification towards the UA, to
>      trigger the UA to send a REGISTER request.

This paragraph needs to be rewritten in some way that is not so
conditional dense.


S 5.2.
>      UA expects to receive push notifications from the network.  A proxy
>      will not request push notifications towards a UA that has not
>      provided a pn-prid SIP URI parameter.
>   
>      If the proxy receives information that a registration has expired,
>      the proxy MUST NOT request further push notifications towards the UA.

Again, how would it receive such information?


S 5.3.1.
>   
>   5.3.  SIP Requests
>   
>   5.3.1.  REGISTER
>   
>      The procedures in this section apply when the SIP proxy receives a

This section is incredibly hard to follow. Can you rewrite it with
some sort of structure that reflects the logic of the proxy?


S 5.3.1.
>      registrar too short, the proxy MUST NOT insert a Feature-Caps header
>      field with a 'sip.pns' feature-capability indicator in the response,
>      and the proxy MUST NOT request push notifications associated with the
>      registration.  A registration expiration interval MUST be considered
>      too short if the interval is smaller than the time prior to
>      expiration that the proxy would request a push notification.  The

What does this text mean?


S 5.3.2.
>   
>      If the proxy has knowledge that the UA is awake, and that the UA is
>      able to receive the SIP request without first sending a REGISTER
>      request, the proxy MAY choose to not request a push notification
>      towards the UA (and wait for the associated REGISTER request and 2xx
>      response) before it tries to forward the SIP request towards the UA.

Why not race these?


S 6.1.1.
>   
>   6.1.  SIP UA Behavior
>   
>   6.1.1.  Initial Request for Dialog
>   
>      When the UA sends in initial request for a dialog, or a 2xx response

"an initial request"


S 6.1.1.
>      triggered by incoming mid-dialog requests is done based on local
>      policy.  Such policy might be based on the type of SIP dialog, the
>      type of media (if any) negotiated for the dialog [RFC3264], etc.
>   
>      NOTE: As the 'pn-purr' SIP URI parameter only applies to a give
>      dialog, the UA needs to include a 'pn-purr' parameter in the Contact

"to a given" dialog?


S 6.2.1.
>   6.2.1.  REGISTER
>   
>      When the proxy receives an initial REGISTER request for a
>      registration from the UA, if the proxy supports requesting push
>      notifications, triggered by mid-dialog requests, towards the
>      registered UA, the proxy MUST store the information (the pn- SIP URI

Too many commas here to make sense of this requirement


S 10.
>      by two values, separated by a period (.): Team ID and Topic.  The
>      Team ID is provided by Apple and is unique to a development team.
>      The Topic consists of the Bundle ID, which uniquelly identifies an
>      appliciation, and a service value that identifies a service
>      associated with the application, separated by a period (.).  For VoIP
>      applications the service value is "voip".

What is the syntax of these params?


S 11.
>      The value of the pn-provider URI parameter is "fcm".
>   
>      The value of the pn-param URI parameter is the Project ID.
>   
>      The value of the pn-prid URI parameter is the Registration token,
>      which is generated by the FCM SDK for each client app instance.

Again, what is the syntax of this?