Re: [sipcore] Short WGLC on SIP Push

[Ben Campbell <[e-mail]>]

(As individual)

Hi,

I have reviewed version 24. I mainly reviewed the diff from version 21. For the most part, I am only making substantive comments in this email. However, I think that the new text needs more wordsmithing and proofreading.

§4.1.2: In the case where the UA cannot remove its registration, I assume this is all soft-state and will get cleaned up when the bindings expire. If correct, it would be worth mentioning that here. I agree the UA needs to remove the binding if it can

§5.2: Is this really a queue in the formal sense? That is, a given queued request doesn’t have to wait for other requests that are ahead in the queue, does it?

§5.3:

I think this section needs to be careful about URI matching for the purposes of generating a push request, and URI matching for the purposes of message routing.

The 3261 URI comparison rules say that a parameter that exists in one URI but not the other is ignored. That means a URI with the push-related parameters will match one without them. Is that the intent? For example, is an inbound request that has a request-URI that matches the registered contact for the push-enabled UA but does not have the push parameters expected to trigger a push request?

In the second paragraph, do I understand that we are saying that a URI that would not have matched if we weren’t using the PNS will now suddenly match for purposes of routing the request to the UA? What do we expect the UAS to do with a request that doesn’t match any of its bindings? Is it also allowed to match just on the push parameters? (I wonder if there are subtle security considerations here.)

That same race condition can occur in non-push networks, where a UAS changes a binding between the time a UAC sends an request and the time that request reaches the responsible proxy. We don’t expect that to work. Why do we expect this to be different for push-enabled networks? Is it because the window for the race condition is larger?  (It can’t be _much_ longer, or the user experience will be pretty bad.)

§5.6.2:

- “The proxy checks whether the SIP Request Push queue contains a SIP request associated with the REGISTER transaction”: Please be precise about what “associated” means in this context. I initially assumed it meant “has an R-URI that matches one of the contacts in the REGISTER request”, but the following step checks for that.

- In the paragraph about what happens if the push-triggered REGISTER does not show up in time, it’s not clear which transaction timer is being discussed. I think this means some special push-specific timer set by the proxy, not the UAC's normal SIP transaction timers? (If we are talking about the UAC’s timer, then it seems tardy for the proxy to send an error _after_ the UAC’s timer has expired.) If so, then some text mentioning the proxy needs to keep such timers in the first place would be helpful.

- " If the proxy is able to authorize the sender of the REGISTER…”
Does this mean “authenticate”? If you really mean “authorize”, then “is able to” doesn’t seem to make sense. Maybe “If the proxy is responsible for authorizing…”?

§6.2.3: Do I understand correctly that a mid-dialog request with an incorrect R-URI will still work if the PURR matches? What do we expect the UAS to do with a mid-dialog request with an incorrect r-uri?

§13:
- I suggest removing the language suggesting that malicious push-notifications have no security-related impacts.Running down batteries and triggering extra messaging can have their own security-related impacts.

- TLS doesn’t, by itself, secure the network from malicious _endpoints_, if you mean endpoint in the sense of a SIP UA. That requires authentication and authorization of the UA, which TLS does not do unless you want to require mutual-authentication.  I suspect you meant to talk about attacks from other parties?

Thanks!

Ben.


> On Jan 29, 2019, at 1:23 PM, Brian Rosen <[e-mail]> wrote:
> 
> As many substantive changes to SIP Push have been made, chairs have decided to rerun last call, but on a quick cycle.
> 
> This email starts a one week Working Group Last Call on draft-ietf-sipcore-sip-push
> 
> Please send comments to the list.  Statements from reviewers that their comments have been satisfactorily addressed would be helpful.
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore