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

[Christer Holmberg <[e-mail]>]

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?

The client includes vapid information when it registers with the push notification service, but the subscribe details are outside the scope of the document.

---

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

If we add the "non-exceptional circumstances" to the SHOULD?

Something like:

"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), or when there are
circumstances (e.g., if the UA is assigned new contact parameters
due to a network configuration change) that require an immediate 
REGISTER request to be sent."

---
  
>>>>> - "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 will add text.

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

There have been discussions about sending such "metadata" associated with the SIP request as push notification payload, but we decided to leave that outside the document. It could be a candidate for future work, though.

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

Sorry, my reply was misleading. The R-URI still has to match one of the contacts of the REGISTER, but what has been removed is the requirement that the proxy has to wait for the REGISTER response before forwarding the SIP request, if the proxy is able to authenticate the sender of the REGISTER request.

...

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

I think having a reference is good.

For example, the document defines some pn-provider values, and I think it would be good if the registry indicates that they are defined in the document.

...

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

I talked with the product people about the push-specific response codes. Currently they are used only for trouble shooting, and don't trigger any response code-specific behaviour.

Regards,

Christer