Subject: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Fri, 01 Mar 2019 09:15:13 -0800

Adam Roach has entered the following ballot position for
draft-ietf-sipcore-sip-push-26: No Objection

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/

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

Thanks for addressing my discuss points. Although I find the solution
for SUBSCRIBE dialogs particularly unsatisifying, I'm not going to get
in the way of working group consensus here. The original discuss points
(and original comments) are detailed below.

---------------------------------------------------------------------------

Thanks to everyone who is put work into defining this mechanism. I think it will
be very useful to have a solution for integrating push mechanisms into SIP
networks. I've identified three issues that I think need to be addressed in the
current document before it can move forward, and a fourth serious flaw that I
call out in my comments below.

---------------------------------------------------------------------------

It's nice that this document has considered the impact of inbound mid-dialog
messages in long-lived dialogs. However, it appears to have a major hole in it:
handing of outbound messages for the purpose of maintaining soft-state in those
dialogs isn't handled correctly.

In particular: networks that deploy this mechanism will cause SUBSCRIBE
dialogs to time out and be destroyed while they are still in use.
Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dialogs
will suffer the same fate.

I can think of a couple of ways for these situations to be handled, but they
need explicit text in the document.

One approach would be to specify that the User Agent selects its requested
"Expires" value in its registration to be the smallest value before its set of
subscriptions and session timers needs to be refreshed. This would cause a push
notification to happen to prevent registration timeout, and the client could
refresh the other soft state at that time. Complications arise if the registrar
responds with a 483 (Interval too Brief), and we'd need to find a solution for
that.

Another approach would be for the clients to refresh all soft state whenever
they send a registration, and set the timeout for that soft state to be equal to
or greater than the registration timeout. A complication could arise if the
notifier or the peer in an invite dialog shortens the requested time, and we'd
need to find a solution for that.

A third approach would be getting the proxy involved in some way -- either by
requiring it to observe subscription and session timer timeouts and requiring it
to send push notifications prior to their expiration, or by an explicit
communication between the UA and the proxy that indicates when the next push
notification should be scheduled. If the latter approach is taken, I would
suggest that it needs to be taken for REGISTER messages as well.

I really don't think this mechanism is feasibly deployable without a solution to
this problem.

---------------------------------------------------------------------------

§4.1:

>  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.

This seems to ignore the availability of Contact URI parameters via RFC 3680
subscriptions. This would seem to impose a requirement on Registrars to strip
this information before making it available to any other party (which, in
turn, requires that the system have explicit Registrar *and* Proxy support).
As far as I can tell, the system so far has not required explicit proxy support
(and there's certainly no mechanism built-in that ensures that a proxy has any
special handling regarding this mechanism).

If the PNS information is sensitive, and cannot be allowed to leak out to
other users, then we need some way to ensure the registrar has provided
positive confirmation that it will not do so before allowing it to come into
possession of them.

---------------------------------------------------------------------------

§4.2:

>  The UA can do so by only including the pn-provider
>  SIP URI parameter in the SIP Contact header field URI of the REGISTER
>  request, but without including the pn-prid SIP URI parameter.

Unless I'm mistaken, this is a barrier to interoperation.

It's not 100% clear, but I suspect the intended implication is that the
pn-provider parameter here will contain a single value? The syntax of the
parameter certainly seems to imply that. This seems to be a pretty big
problem, since it presupposes that the client will know which PNSes the Proxy
supports.  Consider, for example, an iOS client that can use any of RFC 8030,
FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
If the client doesn't know a priori what the proxy supports (and this entire
section only makes sense if that's true), then it won't know which of those
three services to indicate in its REGISTER request. If it guesses wrong, this
mechanism simply fails.

I think you need a different discovery mechanism here -- either have one that
has the client offering multiple PNS protocols and the proxy responding with
one, or have one in which the proxy indicates all of its supported services in
a response, and the client chooses one to use in its next REGISTER message.

---------------------------------------------------------------------------

Figure 1:

This diagram includes both a ladder diagram and an example REGISTER message.
While both of these are useful at this point in the document, neither of them is
an "Architecture," and they're really two different things. I suggest breaking
this into two Figures, entitled "Typical Information Flow" and "Example REGISTER
Message" (or similar), respectively.

---------------------------------------------------------------------------

§4.1:

>  As long as the UA wants to receive push notifications (requested by
>  the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
>  (if required for the specific PNS provider) SIP URI parameter in each
>  binding-refresh REGISTER request.

Please be clear that these parameters appear in the Contact URI.

---------------------------------------------------------------------------

§5.2:

>  In order to request push notifications towards a SIP UA that will
>  trigger the UA to send binding-refresh SIP REGISTER requests, the SIP
>  proxy needs to have information about when a registration will
>  expire.  The proxy needs to be able to retrieve the information from
>  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].

Nit: "SIP registration"

This mechanism seems to be predicated on an architecture in which the proxy must
be on the traffic path. Although it's problematic from a "what proxies are
expected to do" perspective, it seems like the proxy could glean this
information from the 200 response to the REGISTER request. (I mean, the proxy is
already reading parameters out of the contact header field, so the behavior of
acting on registration information is already assumed). The proxy would, of
course, need to run its own timers, but that seems to be a pretty minor
requirement, given everything else involved here.

---------------------------------------------------------------------------

§5.3.1:

This is a major comment, and one that has a sufficient impact on interop that I
had a long debate with myself about whether it should be a DISCUSS. Please take
it very seriously.

>  Otherwise, if the pn-provider SIP URI parameter identifies a type of
>  PNS that the proxy does not support, or if the REGISTER request does
>  not contain all additional information required for the specific type
>  of PNS, the proxy MUST either forward the request (e.g., if the proxy
>  knows that another proxy that will receive the REGISTER request
>  supports the type of PNS)...

How would the proxy know this?

Features like suppressing PNS behavior when a "sip.pns" feature capability is
present in the REGISTER imply that the various nodes in the network discover
capabilities of their neighbors automatically (which is consistent with the way
SIP does features), while this provision seems to require provisioned knowledge.
This is going to be operationally very confusing.

At the very least, the document needs to call out how this "knowledge" is
obtained. In the more general sense, since a client cannot rely on the proxy
supporting *any* kind of PNS, the use of 555 in the way specified here is at
best an optimization -- and, since the configured information can conflict with
actual reality, it's an optimization that can actually break things unless
extreme care is exercised. (e.g., if the proxy is configured to "know" that the
next proxy cannot provide push service, but this knowledge is wrong, then the
network is unnecessarily broken.)

My rather strong recommendation is to remove this code, and let the client rely
on the lack of indication of support in the response indicate that the feature
is not supported.

---------------------------------------------------------------------------

§5.3.1:

>  o  if the proxy received a 'sip.pnsreg' media feature tag in the
>     REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature-
>     capability indicator with an indicator value bigger than 120 in
>     the response, unless the proxy always want to request push

Nit: "...wants..."

---------------------------------------------------------------------------

§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 seems to be a very strong requirement ("MUST") when, e.g., many or most
networks may want to return a 480 instead of a 404. I think what you want to say
is something like "...MUST reject the SIP request. Response codes of either
404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but other
appropriate codes may be used as well."

---------------------------------------------------------------------------

§5.3.2:

>  The reason the proxy needs to wait for the REGISTER response before
>  forwarding the SIP request is to make sure that the REGISTER request
>  has been accepted by the registrar, and that the UA which initiated

Nit: "...the UA that initiated..."

---------------------------------------------------------------------------

§5.3.2:

>  In case of non-2xx response to the REGISTER request, the proxy MUST
>  reject the SIP request with a 404 (Not Found) response.
>
>  If the push notification request fails (see PNS-specific
>  documentation for details), the proxy MUST reject the SIP request
>  with a 480 (Temporarily Unavailable) response.
>
>  If the proxy does not receive the REGISTER request from the UA within
>  a given time after the proxy has requested the push notification, the
>  proxy MUST reject the request with a 480 (Temporarily Unavailable)
>  response.  The time value is set based on local policy.

As above, this seems way too restrictive in terms of mandating specific error
codes. It may well be the case that a network would want to treat these
situations identically from the perspective of the calling party.

---------------------------------------------------------------------------

§5.3.2:

>  Otherwise the
>  proxy MUST reject the SIP request with a 480 (Temporarily
>  Unavailable) response.

Same comment as above.

---------------------------------------------------------------------------

§6.1.1:

>  When the UA sends in initial request for a dialog, or a 2xx response

Nit: "...sends an initial request..."

>  purr' SIP URI parameter in the Contact header of the request or

Nit: "...Contact header field..."

>  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

Nit: "...given dialog..."

>  dialog, the UA needs to include a 'pn-purr' parameter in the Contact
>  header of the request or response for each dialog in which the UA is

Nit: "...Contact header field..."

---------------------------------------------------------------------------

§6.1.1:

>  The UA MUST include a parameter value identical to the the
>  last 'sip.pnspurr' feature-capability indicator that it received in a
>  REGISTER response.

This is incredibly confusing, as the "sip.pnspurr" indicator has not been
mentioned in the document so far. Please revise as something along the lines of:

>  The UA MUST include a parameter value identical to the the last
>  'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it
>  received in a REGISTER response.

Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR
concept is properly introduced before protocol procedures are defined for it.

---------------------------------------------------------------------------

§6.1.1:

>  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
>  header of the request or response for each dialog in which the UA is
>  willing to receive push notifications triggered by incoming mid-
>  dialog requests.

Similar to the above, this is a very confusing introduction of the "pn-purr" URI
parameter.

---------------------------------------------------------------------------

§6.2.2:

>  Contact header field with a PURR value that the proxy has generated
>  Section 6.2.2, the proxy MUST add a Record-Route header to the
>  request, to insert itself in the dialog route [RFC3261].

This "Section 6.2.2" makes the sentence impossible to read. Is it intended to be
in parentheses?

---------------------------------------------------------------------------

§6.2.3:

>  As described in Section 5.3.2, while waiting for the push
>  notification request to succeed, and the associated REGISTER request
>  to arrive from the SIP UA, the proxy needs to take into consideration
>  that the transaction associated with the NOTIFY request will
>  eventually time out at the sender of the request (UAC), and the
>  sender will consider the transaction a failure.

I think this needs some discussion about the impact of the error codes selected
by the proxy on the dialog and its usages. For example:

* If the proxy sends a 404 to prevent a transaction timeout, it will destroy the
  dialog and all of its usages

* If the proxy sends a 480 to prevent a transaction timeout, it will destroy the
  usage, but not other usages in the dialog (if any)

* If the proxy sends a 504 to prevent a transaction timeout, it will keep the
  dialog and the usage alive, and allow the client to re-try at a later time.
  Simply allowing the transaction to time out will have the same effect, albeit
  with more message retransmissions.

Pointing to RFC 5057 might be useful here.

---------------------------------------------------------------------------

§8.7:

>    Parameter value characters that are not part of pvalue needs to be
>    escaped, as defined in RFC 3261.

Nit: "...need to be escaped..."

---------------------------------------------------------------------------

§9:

>  When a new value is registered to the PNS Sub-registry, a reference
>  to a specification which describes the usage of the PNS associated

Nit: "...specification that describes..."

---------------------------------------------------------------------------

§§10-12:

Nit: It seems like these should all be subsections of section 9.

---------------------------------------------------------------------------

§10:

>  The Topic consists of the Bundle ID, which uniquelly identifies an
>  appliciation, and a service value that identifies a service

Nit: "uniquely"
Nit: "application"

---------------------------------------------------------------------------

§10:

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

Please use an RFC 2026 domain for this example; e.g.:

>  Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip

---------------------------------------------------------------------------

§11:

>  [RFC8292] defines a mechanism which allows a proxy to identity itself

Nit: "...mechanism that allows..."

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Mar 2019 21:31:40 +0000

Hi Adam,

Thank You!

Your issues have been addressed. In this reply I more or less copy/paste what I said in my previous reply to your review, and give some extra details on how issues were solved.

COMMENT:

>I really don't think this mechanism is feasibly deployable without a solution to

This has been addressed, and the text in section 4.1.1 now says:
 "This specification does not define a mechanism to explicitly request
   push notifications from the SIP network for usages other than
   triggering binding-refresh REGISTER requests (e.g., for sending
   periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does
   it describe how to distinguish push notifications associated with
   such usages from the push notifications used to trigger binding-
   refresh REGISTER requests.  If a SIP UA wants to use push
   notifications for other usages, the UA can perform actions associated
   with such usages (in addition to sending a binding-refresh REGISTER
   request) whenever it receives a push notification by using the same
   refresh interval that is used for the binding-refreshes."

>positive confirmation that it will not do so before allowing it to come into

This has been addressed, and the text now says:
 "For privacy and security reasons, a UA MUST NOT insert the SIP URI
   parameters (except for the pn-purr parameter) defined in this
   specification in non-REGISTER request in order to prevent the PNS
   information associated with the UA from reaching the remote peer.
   For example, the UA MUST NOT insert the pn-prid SIP URI parameter in
   the Contact header field URI of an INVITE request.  REGISTER requests
   will not reach the remote peer, as they will be terminated by the
   registrar of the UA.  However, the registrar MUST still ensure that
   the parameters are not sent to other users, e.g., using the SIP event
   package for registrations mechanism [RFC3680].  See Section 13 for
   more information."
Section 13 (Security Considerations) contains the following text:
"Operators MUST ensure that the PNS-related SIP URI parameters
   conveyed by a user in the Contact URI of a REGISTER request are not
   sent to other users, or to non-trusted network entities.  One way to
   convey contact information is by using the the SIP event package for
   registrations mechanism [RFC3680].  [RFC3680] defines generic
   security considerations for the SIP event package for registrations.
   As the PNS-related SIP URI parameters conveyed in the REGISTER
   request contain sensitive information, operators that support the
   event package MUST ensure that event package subscriptions are
   properly authenticated and authorized, and that the SIP URI
   parameters are not inserted in event notifications sent to other
   users, or to non-trusted network entities."

>a response, and the client chooses one to use in its next REGISTER message.

This has been addressed in section 4.1.5 (Query Network PNS Capabilities). The UA can now
choose to not include the pn-provider parameter, in which case the network will return all
PNS protocols supported.

>Message" (or similar), respectively.

This has been addressed as suggested in Section 1 (Introduction).

*

>Please be clear that these parameters appear in the Contact URI.

Eventhough the text above does no longer exist, it has now been generally clarified that the parameters appear in the Contact URI.

(I did note a bug in section 4.1.2. I says "UA MUST include", but it shall be "UA MUST NOT include")

>  SIPregistration event package mechanism [RFC3680].

Has been fixed.

>requirement, given everything else involved here.

When I previously replied to your COMMENT, I said the following:

"One way to implement the "retrieve the information from the registrar" could of course be using own timers.
But, I don't think we should specify such behavior.

Also, in some cases the proxy might be co-located with the "home proxy", or some other network node,
where the interface with the registrar already exists."

No changes were done based on the comment.

>How would the proxy know this?

In the previous reply, I said "local configuration".

It has been clarified in the text, and the text in section 5.6.1.1 now says:

"If the proxy knows (by means of local configuration)"

>on the lack of indication of support in the response indicate that the feature

In my previous reply I said:

"I would like to keep the code, because there are cases where one wants the register to be rejected
(rather than accepted, but without indication of supported PNS) if the PNS is not supported.

Also, there are already deployments of 555, so I'd prefer to keep it, as it doesn't break anything."

The 555 response code has been kept, and regarding the proxy knowing it was clarified that it is based on local configuration (see above).

>     the response, unless the proxy always want to request push

Has been fixed.

>appropriate codes may be used as well."

This has been addressed with the following text:

"It is RECOMMENDED that the proxy sends either a 404 (Not
 Found) response or a 480 (Temporarily Unavailable) response to the
 SIP request, but other response codes can be used as well."

>Nit: "...the UA that initiated..."

Has been fixed.

>situations identically from the perspective of the calling party.

Has been addressed (see above).

>  proxy MUST reject the SIP request with a 480 (Temporarily

Has been addressed (see above).

>Nit: "...sends an initial request..."

Has been fixed.

>Nit: "...Contact header field..."

Has been fixed.

>Nit: "...given dialog..."

Has been fixed.

>Nit: "...Contact header field..."

Has been fixed.

>concept is properly introduced before protocol procedures are defined for it.

This has been addressed, by adding a reference to Section 6.2.1.

*

>Similar to the above, this is a very confusing introduction of the "pn-purr" URI

I realized this has been fixed in the wrong section. I will fix that by adding a reference to Section 6.2.1.

Note, though, that the first occurrence of 'pn-purr' SIP URI parameter is in the first paragraph of section 6.1.1, so I will add the reference there.

>This "Section 6.2.2" makes the sentence impossible to read. Is it intended to be

Has been fixed.

> Pointing to RFC 5057 might be useful here.

This has been addressed. The text in Section 6.2.3 now says:

   "When a proxy sends an error response to a mid-dialog request (e.g.,
   due to a transaction time out), the proxy SHOULD select a response
   code that only impacts the transaction associated with the request
   ([RFC5079])."

>Nit: "...need to be escaped..."

Has been fixed.

>Nit: "...specification that describes..."

Has been fixed.

>Nit: It seems like these should all be subsections of section 9.

In my previous reply I said:

"The idea was that the PNS registrations are in separate main sections, as they could even be in a separate document."

No changes were done based on this comment.

>  appliciation, and a service value that identifies a service

This has been fixed.

>  Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip

Has been fixed.

> Nit: "...mechanism that allows..."

Has been fixed.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Fri, 1 Mar 2019 15:46:59 -0600

HI! I apologize if it was unclear from my preamble, but the original 
comments were only included because I wanted the document ballot to 
retain them for historical purposes. No reply was necessary.

/a

On 3/1/19 15:31, Christer Holmberg wrote:
>
> Hi Adam,
>
>
> Thank You!
>
>
> Your issues have been addressed. In this reply I more or less 
> copy/paste what I said in my previous reply to your review, and give 
> some extra details on how issues were solved.
>
>
>    the Contact header field URI of an INVITE request.  REGISTER 
> requests    will not reach the remote peer, as they will be terminated 
> by the    registrar of the UA.  However, the registrar MUST still 
> ensure that    the parameters are not sent to other users, e.g., using 
> the SIP event    package for registrations mechanism [RFC3680].  See 
> Section 13 for    more information."
>    convey contact information is by using the the SIP event package 
> for    registrations mechanism [RFC3680].  [RFC3680] defines generic 
>    security considerations for the SIP event package for 
> registrations.    As the PNS-related SIP URI parameters conveyed in 
> the REGISTER    request contain sensitive information, operators that 
> support the    event package MUST ensure that event package 
> subscriptions are    properly authenticated and authorized, and that 
> the SIP URI    parameters are not inserted in event notifications sent 
> to other    users, or to non-trusted network entities."
>
> >FCM, and APN (cf 
> https://firebase.google.com/docs/cloud-messaging/ios/client).
> Eventhough the text above does no longer exist, it has now been 
> generally clarified that the parameters appear in the Contact URI.
>
> "One way to implement the "retrieve the information from the 
> registrar" could of course be using own timers.
> The 555 response code has been kept, and regarding the proxy knowing 
> it was clarified that it is based on local configuration (see above).
>
> Note, though, that the first occurrence of 'pn-purr' SIP URI parameter 
> is in the first paragraph of section 6.1.1, so I will add the 
> reference there.
>
>    "When a proxy sends an error response to a mid-dialog request 
> (e.g.,    due to a transaction time out), the proxy SHOULD select a 
> response    code that only impacts the transaction associated with the 
> request    ([RFC5079])."
>
> "The idea was that the PNS registrations are in separate main 
> sections, as they could even be in a separate document."
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Mar 2019 21:55:58 +0000

Hi,

>HI! I apologize if it was unclear from my preamble, but the original comments were only
>included because I wanted the document ballot to retain them for historical purposes. No
>reply was necessary.

Well, when I went through version -26 to make sure your issues had been addressed I did find a couple of minor nits that I still need to fix, so it was not wasted time 😊

Regards,

Christer

Hi Adam,

Thank You!

COMMENT:

This has been addressed, and the text in section 4.1.1 now says:
 "This specification does not define a mechanism to explicitly request    push notifications from the SIP network for usages other than    triggering binding-refresh REGISTER requests (e.g., for sending    periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does    it describe how to distinguish push notifications associated with    such usages from the push notifications used to trigger binding-    refresh REGISTER requests.  If a SIP UA wants to use push    notifications for other usages, the UA can perform actions associated    with such usages (in addition to sending a binding-refresh REGISTER    request) whenever it receives a push notification by using the same    refresh interval that is used for the binding-refreshes."

This has been addressed, and the text now says:
 "For privacy and security reasons, a UA MUST NOT insert the SIP URI    parameters (except for the pn-purr parameter) defined in this    specification in non-REGISTER request in order to prevent the PNS    information associated with the UA from reaching the remote peer.    For example, the UA MUST NOT insert the pn-prid SIP URI parameter in    the Contact header field URI of an INVITE request.  REGISTER requests    will not reach the remote peer, as they will be terminated by the    registrar of the UA.  However, the registrar MUST still ensure that    the parameters are not sent to other users, e.g., using the SIP event    package for registrations mechanism [RFC3680].  See Section 13 for    more information."
Section 13 (Security Considerations) contains the following text:
"Operators MUST ensure that the PNS-related SIP URI parameters    conveyed by a user in the Contact URI of a REGISTER request are not    sent to other users, or to non-trusted network entities.  One way to    convey contact information is by using the the SIP event package for    registrations mechanism [RFC3680].  [RFC3680] defines generic    security considerations for the SIP event package for registrations.    As the PNS-related SIP URI parameters conveyed in the REGISTER    request contain sensitive information, operators that support the    event package MUST ensure that event package subscriptions are    properly authenticated and authorized, and that the SIP URI    parameters are not inserted in event notifications sent to other    users, or to non-trusted network entities."

Has been fixed.

Has been fixed.

Has been fixed.

Has been fixed.

Has been fixed.

Has been fixed.

Has been fixed.

Has been fixed.

   "When a proxy sends an error response to a mid-dialog request (e.g.,    due to a transaction time out), the proxy SHOULD select a response    code that only impacts the transaction associated with the request    ([RFC5079])."

Has been fixed.

Has been fixed.

This has been fixed.

Has been fixed.

Has been fixed.

Regards,

Christer