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

[Christer Holmberg <[e-mail]>]

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



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.


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

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

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

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


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

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

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

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

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

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.

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

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

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

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

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")

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

§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"

Has been fixed.

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

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.

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

§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?

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

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

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

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

Has been fixed.

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

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

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

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

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

Has been fixed.

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

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

Has been addressed (see above).

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

§5.3.2:

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

Has been addressed (see above).

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

§6.1.1:

>  When the UA sends in initial request for a dialog, or a 2xx response
>
>Nit: "...sends an initial request..."

Has been fixed.

>  purr' SIP URI parameter in the Contact header of the request or
>
>Nit: "...Contact header field..."

Has been fixed.

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

Has been fixed.

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

Has been fixed.

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

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

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

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

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.

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

§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?

Has been fixed.

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

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

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])."

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

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

Has been fixed.

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

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

Has been fixed.

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

§§10-12:

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

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

§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"

This has been fixed.

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

§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

Has been fixed.

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

§11:

>  [RFC8292] defines a mechanism which allows a proxy to identity itself
>
> Nit: "...mechanism that allows..."

Has been fixed.

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

Regards,

Christer