Re: [sipcore] AD Evaluation of draft-ietf-sipcore-sip-push-11 - Other issues

[Ben Campbell <[e-mail]>]

Hi, apologies for the delay in responding. My last couple of weeks have been crazy busy.  Please see inline; I’ve removed sections that do not seem to need further discussion. I’ve read the list discussion and version 13 of the draft, and am responding from that context (but forgive me if I missed a change that addresses any of them.)


> On Aug 8, 2018, at 5:27 AM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi Ben,
> 
> In this reply I address your other issues.
> 
> Other Substantive Comments:
> 
> ---
> 
>> §1
>> -  Does this draft claim compatibility with APNS and FCM? Can you offer citations for those?
> 
> I am not exactly sure what you mean. Sections 8 and 9 describe how the mechanism can be used with APNS and FCM.

Right. I guess I was reviewing linearly :-)

> 
>> - " When the proxy receives (or, if the proxy is the SIP registrar[RFC3261], initiates) a SIP request for a new dialog”
>> I don’t understand the intent here; registrars do not normally initiate SIP requests for new dialogs.
> 
> This is related to your major issue #2. It is the "home proxy of the UA", not the registrar. And, it does not initiate requests, it forwards them.

Okay

> 
>> “Different PNSs exist today.  Some are based on the standardized mechanism defined in [ RFC8030 ], while others are
>> proprietary (e.g., the Apple Push Notification service).”
>> 
>> Is there an assumption that they are all similar enough that this mechanism can work with all of them? If so, please say that explicitly.
> 
> I could modify the following sentence:
> 
> "Figure 1 shows the generic push notification architecture supported by the mechanism in this document. The mechanism in this document can be used with any push notification mechanism that is based on that architecture, and where the SIP UA is able to provide the information needed for the SIP proxy to request push notifications towards the UA.”
> 

WFM


[...]


>> - Please elaborate on the practical effect of supporting VAPID.
> 
> I am not sure how much information this document should contain. There is already a reference, and the Security Considerations contains the following paragraph:
> 
>   "[RFC8292] defines a mechanism which allows a proxy to create a
>   identity itself to a PNS, by signing a JWT sent to the PNS using a
>   key pair.  The public key serves as an identifier of the proxy, and
>   can be used by devices to restrict push notifications to the proxy
>   associated with the key."
> 
> (Later you have a comment on this paragraph, but it is editorial)

I was asking about the impact on the SIP behavior. Do we expect the SIP client to do something with the capability indicator value? Maybe record the value pass it to the “push" client? Only send a new register when the right VAPID related things happens in the push protocol?

> 
>> - " If the REGISTER response does not contain a a ’sip.pnsreg’ feature- 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).”
>> 
>> Why? That’s normal SIP behavior for UAs that do not support this mechanism, so the registrar must be able to handle it.
>> (If there’s a good reason, please explain it in the draft.)
> 
> The registrar will for sure be able to handle it, but if the proxy is anyway going to trigger REGISTER requests using push notifications, I see no reason for the UA to trigger REGISTER requests "on its own”.

So the concern is additional unnecessary REGISTER requests?

What happens if a binding is about to expire, but the client hasn’t gotten a push notification? What if the clients network configuration changes in a way that forces adding or removing contacts; should it wait for a push notification to send a new REGISTER request? Can it terminate a binding proactively, or does it need to wait for that, too?

> 
> ---
> 
>> - “ NOTE: If the SIP UA application wants to use push notifications for
>>  other purposes than to trigger re-registration requests, it needs to
>>  be able to distinguish between the different purposes when receiving
>>  push notifications.  Mechanisms for doing that are outside the scope
>>  of this specification."
>> 
>> I can see keeping how you distinguish between SIP related notifications and other kinds of notifications. But what if the UA uses
>> more than one SIP services that supports push notifications?
> 
> Each UA application will have a separate push notification subscription, use separate registrations etc.
> 
> (Now, if a single UA handles multiple SIP services I see no reason from a non-push scenario: when the UA receives a request it needs to figure out to which service the request is "dispatched”.)

I was thinking in terms of a single UA application. Let’s say it has successfully registered with service FOO and service BAR. They both support push. If it gets a push notification, how does it know which binding to refresh? Should it refresh both?


> ---
> 
>> §5.2: “ It is RECOMMENDED that the proxy requests the push notification at least 120 seconds before the registration
>> expires.” - We usually recommend refreshing bindings at when half of the expiration time has passed. Is there a reason
>> to do this differently? If so, why 120 seconds in particular; has there been analysis of push notification latency?
> 
> I believe 120 seconds was suggested by Dale. We haven't done any further analysis within the WG.
> 
> Regarding sending when half of the expiration time as passed, in deployments the registration expiration timers are normally pretty long, so I am not sure there is a need to send at "half time”.


Okay


>> §5.3.1:
>> -  “ If the proxy considers the requested registration expiration interval
>>  [RFC3261] to be too short, the proxy MUST either send a 423 (Interval
>>  Too Brief) response to the REGISTER request, or skip the rest of the
>>  procedures in this section and process the REGISTER request using
>>  normal SIP procedures. "
>> 
>> That _is_ normal SIP procedure. What do you mean to be different?
> 
> Nothing :)
> 
> I can remove the text, or simply re-write it as an informative "As defined in RFC 3261, if the proxy..." statement.

Okay

> 
>> - " if the proxy received a ’sip.pnsreg’ media feature tag in theREGISTER request, the proxy SHOULD include a ’sip.pnsreg’
>> feature-capability indicator with an indicator value bigger than 120 inthe response, unless the proxy always want to request
>> push notifications to trigger the UA to send a REGISTER request.”
>> 
>> It’s not clear to me why the proxy should be able to override the UAs choice.
> 
> Again, I believe this is based on Dale's comment that we should make sure that REGISTER requests (no matter what triggers them) are sent at least 120 seconds before expiration.

Nevermind, I misread the text :-)

[...]

>> - “ If the contact of the most recent REGISTER
>>  2xx response and Request-URI do not match, the proxy MUST reject the
>>  SIP request with a 404 (Not Found) response.  This can happen if the
>>  UA sends a re-registration REGISTER request with a new contact at the
>>  same time the registrar forwards a SIP request towards a UA using the
>>  previously registered contact in the Request-URI.”
>> 
>> Why doesn’t the proxy forward using normal SIP procedures? It’s entirely possible that an UAS address changes during an inbound transaction
>> in normal SIP. Why is that different with push notifications? (this section seems to replace normal SIP request routing. That shouldn’t happen
>> without a really good reason. If normal SIP procedures are inadequate, please explain why.
> 
> In order for the proxy to forward the SIP request, it needs to be able to match the R-URI of the request with the contact in the REGISTER request/response.
> 
> Now, the proxy could of course not wait for the REGISTER response, and simply forward the request when it receives a REGISTER request with a contact that matches the R-URI. But, if the registrar for whatever reason no longer accepts the registered contact, the proxy have forwarded the request before the REGISTER response informs it about the not-accepted contact.
> 
> But, as you say, that could happen with any proxy, so we could say that the proxy forwards the request as soon as it receives a REGISTER request with a matching contact. That would also be better from the non-invite-transaction-timeout perspective, as the proxy does not need to wait for the REGISTER response before it forwards the request.

I see there’s been some discussion of this, but for the record, my question was not about waiting for the response, it was about requiring the R-URI to match the contact from that particular REGISTER.

For normal SIP, there’s always the chance a client may change it’s contact between the time the home proxy retargets the request and it arrives (or fails to arrive) at the client. Is that problem worse with push? (Maybe it is, if we assume that push clients do not proactively send new REGISTER requests when their contacts change)

> 
> ---
> 
>> §6.2: Why does the UAC need to know the failure was due to push notification? What would it do differently than for other kinds of
>> failures? (This seems like a privacy leak; does the recipient want the sender to know he or she is on a mobile
>> device?)
> 
> I am not sure whether the information is very useful for the UAC, but the "home proxy" may perhaps trigger different actions depending on what response it receives.
> 
> Push can also be used on non-mobile devices, e.g., on tablets where one wants to save battery.

Regardless, it tells the sender something about the client’s device that it did not already know. I think we need better justification than just saying the home proxy might need it; are there expected scenarios where it _will_ need it?


> 
> ---
> 
>> §11: “ If the push notification related information carried in SIP could be
>>  used by a malicious middleman to trigger push notifications towards a
>>  device, operators MUST ensure that the SIP signalling is properly
>>  secured from malicious middlemen, e.g., using encryption.”
>> 
>> This could use some elaboration. I think the sense of this is backwards. That is, the signaling MUST be secured unless
>> there are factors that make it impossible for an active attacker to use the informaiton.
> 
> Isn't that what the text says? :)
> 

It changes the burden of proof. The original text suggests that they only need to secure the signaling if they think they the information could be used maliciously. My suggestion is to say they need to secure the signaling unless they are sure it cannot be used maliciously. These are not the same thing.


> ---
> 
>> §12.5: The template contains a “document” field, but the registration policy is “expert review”. Should this be “specification required”?
> 
> "Document" (or "Reference") is used also for "expert review", isn't it?

“Expert Review” does not necessarily require a document. “Specification required” does.

> 
> ===
> 
> Editorial Comments:
> 
>> - General:
>> — The draft has some readability issues. In particular, it pervasively uses long, convoluted sentences, lots of imbedded parenthetical
>> phrases, improper comma placement, etc.
>> — The draft pervasively mixes registration procedures with the handling of inbound SIP requests. Please consider separating those into
>> different sections. I realize there are interdependencies, but it’s hard to follow as is.
> 
> I will look into it, but when it comes to comma placements etc it would be very useful with input from an English speaker on how to fix it.
> 
>> - Abstract: s/awake/wake ; (or awaken)  (“awake” is not a verb. This repeats elsewhere in the draft. .)
> 
> Someone told me to use "awake". But, I can change it.

Maybe they meant “awaken”?

[...]

> 
>> §5.3.1: “ If the proxy sends a SIP 555 (Push Notification Service Not Supported) response”
>> It would be helpful to describe 555 before this.
> 
> Are you suggesting to move section 6 (Grammar) up?

Not necessarily; just a brief mention that it’s defined in this document. Or just a forward reference.

[...]