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

[Ben Campbell <[e-mail]>]

> On Aug 22, 2018, at 3:16 AM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
> ...
> 
>>>> - 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?
> 
> VAPID is used to restrict the push notifications the SIP UA will receive
> in the first place. But, once it does receive a push notification, there
> is no special behaviour. It will send a REGISTER etc, using the normal
> procedures.
> 

So the client doesn’t need to do anything with the value it gets in the capability indicator in SIP?

> ---
> 
>>> 
>>>> - " 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?
> 
> If the SIP UA has a good reason to send a non-push triggered REGISTER, it
> can do so. That¹s why it is a SHOULD :)
> 
> As you indicate, the only reason for not sending non-push triggered
> REGISTER requests is to avoid unnecessary requests, but nothing will break
> if they are sent.

SHOULD is still pretty strong. If there are non-exceptional circumstances where we expect a normal client to send non-triggered REGISTERs, then SHOULD is not appropriate. To push on one of my examples: If the client learns that its network configuration has changed in a way that invalidates an existing binding, would it be good or bad behavior to wait for a push notification?

> 
> ---
> 
>>> 
>>>> - ³ 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?
> 
> Yes. If you have multiple contacts (no matter whether they are for
> different services, different IP versions, or something else) associated
> with a single push notification subscription, a push notification will
> request them all to refresh.

Unless I missed text that said that, it would be good to say that :-)

I can imagine a somewhat cleaner solution that sends something in a push body to identify which service (or binding) to refresh, but that could be a later extension.

> 
> ---
> 
>>>> - ³ 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)
> 
> It is not a problem with push. The proxy will forward the request using
> the old contact, but that could happen also in non-push scenarios.
> 
> In a previous version of the draft, the proxy actually did check that the
> contacts match, but Robert commented that we can remove it: the proxy will
> forward the SIP request using normal proxy procedures.

Hmm. Version 13 has been updated to talk about matching “one of the contacts” and to check for expiration, but I don’t see where the requirement to match the contact has been removed.

> 
> ---
> 
>>> 
>>>> §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?
> 
> Ok, I will look into this.
> 
> ---
> 
>>>> §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.
> 
> What about:
> 
> ³Operators MUST ensure that the SIP signalling is properly secured, e.g.,
> using encryption, from malicious middlemen, unless they are sure that the
> signalling cannot be accessed and used maliciously (e.g., to trigger push
> notifications towards a deice) by a middleman.²
> 

WFM

> ---
> 
>>> 
>>>> §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.
> 
> There has to be some documentation for implementers. That could be a
> document or a webpage.
> 
> So, perhaps we should then change to ³Specification required² - assuming
> that also covers webpages.

The main thing that “specification required” requires is some form of spec that is publicly available and reasonably expected to be available well into the future. If those are not requirements, then “expert review” could still be appropriate.

> 
> ---
> 
>>> 
>>> 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²?
> 
> Perhaps.
> 
> So, ³awaken² is fine, but any instance of ³awake² should be ³wake²?

Pretty much. “wake” and “awaken” are verbs. “awake” is an adjective.

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