[sipcore] AD Evaluation of draft-ietf-sipcore-sip-push-11

[Ben Campbell <[e-mail]>]

(Apologies if this is a duplicate—my MUA crashed in the middle of sending the first time.)

Hi,

This is my AD evaluation of  draft-ietf-sipcore-sip-push-11.

In summary, I don’t think this draft is ready for IETF last call. There are significant issues that I think need further attention from the working group before this can progress. I am returning the draft to the working group, and will change the state to “AD is Watching”.

Major Issues:

1. The mechanism makes SIP transactions pend for an indeterminate period of time while the push notification is processed, the recipient wakes up and sends a REGISTER request, and the registrar processes that request. This is a problem for non-INVITE transactions, and is not optimal for any transaction. (The issues with doing this to a non-INVITE transaction are best described in RFC 4321.)

At least for the non-INVITE case, has the working group considered a model where the transaction completes and the UAC resends it at some point in the future? (For example, a 4XX response with retry-after)

2. The architectural assumptions are unclear. In particular, the role of the proxy in the SIP network is unclear. In some parts of the draft, it appears the proxy must be co-located with the registrar, but others talk about a proxy that is on the path between the UA and the registrar. Along the same lines, the draft needs to clarify assumptions  about proxy’s role for inbound SIP requests. (For example, the R-URI in an inbound request may or may not match the registered contact depending on whether the request has been retargeted—the R-URI could be an AoR rather than a registered contact.)

3. The mechanism seems to assume a single contact binding exists at any one time, and that any given REGISTER request relates to that binding. How is this expected to work if multiple bindings exist at the same time, perhaps with different expiration times? What if the user has multiple clients that are creating bindings, some supporting this mechanism and others not supporting it?


Other Substantive Comments:

§1
-  Does this draft claim compatibility with APNS and FCM? Can you offer citations for those?

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

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

§2: Please use the new boilerplate from RFC 8174.

§4.1: 
- Please cite RFC 6809 on the first mention of feature-caps. 

- Please elaborate on the practical effect of supporting VAPID.

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

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

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

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

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

§5.3.2: 
-"When the proxy receives (or, in case the proxy is the registrar, creates) a SIP request for a new dialog…”
Why would a registrar create a SIP request for a new dialog?

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

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

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

§12.5: The template contains a “document” field, but the registration policy is “expert review”. Should this be “specification required”?


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.

- Abstract: s/awake/wake ; (or awaken)  (“awake” is not a verb. This repeats elsewhere in the draft. .)

§1,
- first paragraph: 
-- Saying push notification is the only way to solve these issues seems overstated. It’s one way; there might be others.
-- when you talk about “each operating” system, you are talking about popular mobile operating system vendors, right? The assertion seems less true for operating systems in general.
- 4th paragraph: The usual term for re-registration is “binding refresh”.
-4th paragraph: “battery life etc”? What else?

- figure 1: The page break is unfortunate; can the ladder diagram be kept all on the same page?

§5.1, heading: Should “PNS Identifier” be “PNS Provider” (since that is what the section talks about.)

§5.2: 
- “...the SIP proxy MUST have information” - the MUST seems like a statement of fact, not a normative requirements.
- “ If the proxy receives information that a registration has expired,…” - Bindings expire, not registrations. (Much of the draft uses the word “registration” when the common term is “binding"

§5.3, heading: s/Request/Requests

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

§5.3.2: “ The proxy MUST NOT include the SIP request as payload in the
   requested push message.”
Wasn’t there already text forbidding payloads in general?

§6.7: "  Parameter value chapters that are not part of pvalue needs to be escaped, as defined in RFC 3261.”

What is a parameter value chapter? Should “chapters” be “characters”?

§7: This information belongs in the IANA considerations section.

§11: “ [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."
I can’t parse the first clause. Are there missing words?