Subject: [sipcore] Comments on draft-ietf-sipcore-sip-push-04

From: [email-masked] (Dale R. Worley)
Date: Tue, 06 Feb 2018 00:02:58 -0500

I have reviewed draft-ietf-sipcore-sip-push-04 and have the following
comments.  I think the document needs careful revision, and there are
still significant technical issues that need to be settled.

** Major/global issues

* Parameters vs. header parameters

   The document defines new SIP URI parameters,

I still strenuously object to implementing these as URI parameters
rather than as header field parameters, given that the information
carried is information *about* the registered SIP URI and not part of
the URI.  E.g., you wouldn't include these parameters in the
request-URI of an INVITE.

* Reregistration

Handling re-registration still needs some work.  The difficulty is
that the registrar/proxy does't know when the UA needs to reregister,
it only knows when the current registration is going to expire.  In
particular, some UAs use a reregistration strategy copied from some
DHCP clients:  reregister at intervals of (expiration time)/3 -
epsilon.  This allows the UA three opportunities to reregister, and
they are widely separated in time, thus minimizing the chance that all
three will be defeated by temporary network interruptions.  The
registrar/proxy has no way of knowing this.

In addition, the registrar/proxy doesn't know the amount of time that
it will take the UA to wake up from a push notification and send its
re-REGISTER.

Ultimately, the dataflow is difficult:  the UA requests a registration
duration, the registrar allows a registration that may be less than
the requested duration, and from the allowed duration, the UA
determines when it wants to reregister.  But this process seems to
require three messages to pass between the UA and the registrar,
whereas the REGISTER transaction only has two messages.

OTOH, it seems that in most cases, the UA can instruct its OS to wake
it up after a certain time interval, and thus does not need a push
notification for reregistration to maintain its AOR.  If that is so,
the reregistration parts of this document can simply be removed,
because the ordinary implementation practices will work well -- once the
UA receives the 200 response to its REGISTER request, it will set a
timer with its OS for whenever it wants to reregister.

* Extraneous use of "SIP"

There are various places where "SIP" is used extraneously.  E.g.,
"proxy", "registrar" "555 response", "request", "URI", "UA", "INVITE
request", "REGISTER request", "network".  Given that the entire
document is about SIP, almost no noun needs to be qualified with
"SIP".

* The prefix "pns-"

There are places where the prefix "pns-" is used, but it appears that
the author intends for "pn-" to be used.

** Local issues

1.  Introduction

   Due to the restriction above, applications can not be woken up by
   non-push notification traffic.  This means that a suspended SIP UA
   will not be able to receive an incoming SIP request (e.g., a SIP
   INVITE request), or to send periodic re-registration requests.

"awakened" is usually more proper than "woken up" in written text.

Note that reregistration isn't being awakened by traffic, but
internally-generated activity.  The first sentence needs to be revised
to include that the application cannot schedule its own awakening
either.  (But is there ever a case where the UA cannot schedule its own
awakening at a definite future time?)

Figure 1 omits quite a bit of the action.  Viz., once SIP UA has sent
the REGISTER, there should be shown a period of suspension.  At the
end of suspension, an INVITE arrives at SIP Proxy, triggering it to
send the Push Message.  It seems that the mechanism requires that the
awakened SIP UA must send a REGISTER immediately to inform the proxy
that it can now receive messages, and that REGISTER should be shown,
after which the incoming request is sent.

3.  Push Resource ID (PRID)

This section should describe the expected syntax or character set used
by PRIDs and the other values.  Actually, all of these are general
"pvalue" from RFC 3261, and so can represent arbitrary character
strings.  But that should be stated clearly.

4.  SIP User Agent (UA) Behavior

   When the SIP UA receives a 200 (OK) response to the SIP REGISTER
   request, if the response does not contain a Feature-Caps header field
   with a '+sip.pns' header field parameter, ...

The items in a Feature-Caps header are "indicators", not
"parameters".  See RFC 6809 section 6.3.

   When the SIP UA receives a 200 (OK) response to the SIP REGISTER
   request, if the response does not contain a Feature-Caps header field
   with a '+sip.pns' header field parameter ...

The text must include a positive statement indicating when the UA can
understand that its desired push notification service is supported for
the registration.  Or better, the sense of the condition at the
beginning of the paragraph should be inverted:

   When the SIP UA receives a 200 (OK) response to the SIP REGISTER
   request, the response contains a Feature-Caps header field
   containing a '+sip.pns' indicator, and that indicator's value
   contains a tag-value that is the same as the pn-provider in the
   REGISTER, the UA can assume that push notifications will be
   triggered by any SIP proxy handling requests for the given AOR.  In
   all other cases, the UA cannot assume that push notifications will
   be triggered by a SIP proxy.  The actions taken by the UA might be
   dependent on implementation or deployment architecture, and are
   outside the scope of this document.

Note that I've also fixed the logic here:  success requires that
+sip.pns value contains the same tag as the pn-provider that was used.
The original text was that the +sip.pns value contains a tag that the UA
supports, but that does not guarantee that the supported tag is the one
the UA *used*.

   If the SIP UA expects to receive payload in the push notification,
   the UA MAY add a pn-enckey and a pn-encsec SIP Contact header field
   SIP URI parameter, in order to allow encryption of the data using the
   mechanism in [RFC8291].  The pn-enckey URI parameter contains the
   public key, and the pn-encsec URI parameter contains the
   authentication secret [RFC8291].  The format of such payload is
   outside the scope of this document.

   NOTE: End-to-end encryption of the payload between the SIP proxy and
   the SIP UA cannot be used if the push notification request payload
   contains information that needs to be accessible by the PNS provider.

It's not clear to me, regarding the payload that is encrypted using
pn-enckey and pn-encsec, who generates it and what it contains.  If it
is generated by the registrar (or the proxy pretending to be the
registrar), then this document should define what the payload is.  If
the payload is generated by the push notification service itself,
presumably the payload contents are defined by the PNS, but it's not
clear how the parameters in the REGISTER will be transmitted to the
push notification service.

   ... a pn-enckey and a pn-encsec ...

"pn-encsec" doesn't seem to be used elsewhere in the document.
Perhaps "pn-enccode" was meant?  Or rather, "encsec" seems a better
name than "enccode" and should be used throughout...

5.  SIP Proxy Behavior

   When the SIP proxy receives (or, in case the proxy is the SIP
   registrar, creates) a SIP request for a new dialog (e.g., a SIP
   INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE
   request) aimed for a SIP UA, if the Request-URI of the request
   contains ...

Isn't this just a prolix way of saying "When the SIP proxy receives a
request aimed for a SIP UA ..."?

   If the SIP proxy is able to assume that the SIP UA is awake ...

Better wording is "If the SIP proxy has knowledge that the SIP UA is
awake ...".  (Because anything "is able to assume" anything, though it
might be wrong...)

   If the SIP proxy is not able to contact the push notification
   provider, or to forward the SIP request to the SIP UA, the proxy MUST
   reject the SIP request.

It might be useful to describe what response code(s) should be used in
this situation.  408 seems suitable, but it is not specific to this
situation.  480 is "Temporarily Unavailable", but that means that the
*user* is temporarily unavailable rather than the *network*.  It might
be worth defining a response code meaning "UA is temporarily
unavailable".

7.3.  SIP URI Parameters

     The format and semantics of pns-param is specific to a given
     pns-provider value.

I think "pns-param" is supposed to be "pn-param".

Isn't it true that the format of pn-prid, pn-enccode, and pn-enckey
are also controlled by the pns-provider?

8.  PNS Registration Requirements

   The value of the pn-param URI parameter is the APNs App ID, which is
   encoded by two values, separated by a period (.): Team ID and Bundle
   ID.  The Team ID is provided by Apple and is unique to a development
   team.  The Bundle ID is unique to a development team, and is a string
   that will can match a single application or a group of applications.

   Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp

As written, this is confusing, because the description of the syntax
of pn-param doesn't allow the reader to parse the given example, since
the example contains three periods.  Probably the Team ID cannot
contain a period, which disambiguates the example, but that needs to
be stated to avoid confusing the reader.

9.  pn-provider, pn-param and pn-prid URI Parameters for Apple Push
10.  pn-provider, pn-param and pn-prid URI Parameters for Google

It seems like sections 9 and 10 could be grouped as subsections of a
single section, most likely part of section 12.

11.  Security Considerations

There is no description of what mechanism prevents one UA from
registering using the pn-parameters of another device, or even using
entirely random pn-parameters.  The document is written as if the
pn-parameters form a "capability", an identifier containing so much
entropy that just knowing the identifier of a resource proves that one
has the right to access the resource.  However, the example in section
8 suggests that this is not so.

12.1.1.  pn-provider

This section doesn't mention that it is connected with either the
registry for its values (defined in section 12.4) or the currently
defined values (defined in sections 9 and 10).

Dale

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 16:20:26 +1100

> request-URI of an INVITE.

Does the fact that a push subscription might be identified by a HTTPS
URL tip the scales in either direction at all?

---

From: Mickey Arnold <[email-masked]>
Date: Tue, 6 Feb 2018 11:52:38 +0000

Hi Dale,

In your feedback you wrote the following:

"OTOH, it seems that in most cases, the UA can instruct its OS to wake it up after a certain time interval, and thus does not need a push notification for reregistration to maintain its AOR.  If that is so, the reregistration parts of this document can simply be removed, because the ordinary implementation practices will work well -- once the UA receives the 200 response to its REGISTER request, it will set a timer with its OS for whenever it wants to reregister."

This is increasingly not the case on mobile platforms as mobile OS vendors try to limit battery usage and background processing for 3rd party apps. For example, on iOS, App creators can define scheduled operations but there is no guarantee how often these will happen as the OS will wait for "good conditions" before scheduling the app. Practically this results in the OS routinely taking multiple times longer than the requested interval to schedule the app, in the case of a SIP UA this leads to registrations lapsing. As another example, Android 8 contains similar (although more lenient) restrictions on background scheduling with one of the recommended methods of prompting an app to do work being through the FCM platform.

I am definitely not advocating that we specify based solely on these implementations but it does show that this mechanism addresses a specific need for a set of UAs. As such, I am strongly against entirely removing the re-registration mechanism.

That said I think it can be allowable for the proxy or registrar to use the pn-provider parameter to decide whether or not to prompt re-registrations for a particular UA. Practically the pn-provider will often map to a certain class of UAs allowing the network operator to provide this function where required and optimize it out where it's not. This also avoids the need for extra flows or parameters. I read section 5.2 as allowing this already but it could be worth an extra sentence to clarify.

Thanks, Mickey

---

From: Roman Shpount <[email-masked]>
Date: Tue, 6 Feb 2018 16:20:47 -0500

On Tue, Feb 6, 2018 at 6:52 AM, Mickey Arnold <[email-masked]
> wrote:

>
> That said I think it can be allowable for the proxy or registrar to use
> the pn-provider parameter to decide whether or not to prompt
> re-registrations for a particular UA. Practically the pn-provider will
> often map to a certain class of UAs allowing the network operator to
> provide this function where required and optimize it out where it's not.
> This also avoids the need for extra flows or parameters. I read section 5.2
> as allowing this already but it could be worth an extra sentence to clarify.
>

I have suggested in another thread that proxy should return minimum
interval after which it expects to trigger a push notification for
registration (something like pn-refresh SIP URL parameter in Contact
registration response). Based on this SIP UA can try to schedule the
re-registration. If SIP UA successfully re-register before proxy triggers
push notification, then push notification will be avoided. If UA does not
re-register either due to mobile OS limitations or OS scheduling failure,
proxy will trigger the push notification to wake the client and trigger the
re-registration.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 15 Feb 2018 21:52:49 -0500

> proxy will trigger the push notification to wake the client and trigger the

It seems to me that an effective way to parameterize this (possibly in
an extension, as Christer discusses), is a parameter that specifies how
long before registration expiration the proxy/registrar should
push-notify the UA.  This approach has some advantages:

The UA is likely to know the time delays involved (the PN service's
delays, the UA's device's wake-up delays, the internal delays in the
UA).

If the registrar allows less time for the registration than the UA has
requested, the time of the PN is moved to compensate.

Some exceptional value of the parameter can indicate "PN for
reregistration is not needed".

Since the PN is triggered by the near-expiration of the registration, if
the registration is renewed before that point for any reason, the
scheduled PN for reregistration is automatically postponed.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Feb 2018 06:29:32 +0000

Hi,

>> re-registration. If SIP UA successfully re-register before proxy 
>> triggers push notification, then push notification will be avoided. If 
>> UA does not re-register either due to mobile OS limitations or OS 
>> scheduling failure, proxy will trigger the push notification to wake 
>> the client and trigger the re-registration.
>
> It seems to me that an effective way to parameterize this (possibly in an extension, as 
> Christer discusses), is a parameter that specifies how long before registration expiration the
> proxy/registrar should push-notify the UA.  This approach has some advantages:
>
> The UA is likely to know the time delays involved (the PN service's delays, the UA's device's 
> wake-up delays, the internal delays in the UA).
>
> If the registrar allows less time for the registration than the UA has requested, the time of the PN is moved to compensate.
>
> Some exceptional value of the parameter can indicate "PN for reregistration is not needed".

The UA indicates that by inserting the extension.

>Since the PN is triggered by the near-expiration of the registration, if the registration is renewed before that 
>point for any reason, the scheduled PN for reregistration is automatically postponed.

Yes. There is text about that in the latest version. The proxy simply monitors when the registration is about to expire.

Regards,

Christer