idnits 2.17.1 draft-holmberg-sipcore-sip-push-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2369 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC XXXX' is mentioned on line 414, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track October 30, 2017 5 Expires: May 3, 2018 7 Push Notification with the Session Initiation Protocol (SIP) 8 draft-holmberg-sipcore-sip-push-02 10 Abstract 12 This document describes how push notification mechanisms can be used 13 to wake up suspended Session Initiation Protocol (SIP) User Agents 14 (UAs), in order to be able to receive and generate SIP requests. The 15 document defines new SIP URI parameters, that can be used in a SIP 16 REGISTER request to provide push notification information from the 17 SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in 18 this document) that will send a push request to the push server in 19 order to trigger a push notification towards the SIP UA. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 3, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5 58 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 5 59 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6 60 6. Network Address Translator (NAT) Considerations . . . . . . . 6 61 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. PNS Registration Requirements . . . . . . . . . . . . . . . . 7 63 9. pn-prid and pn-type URI parameters for Apple Push 64 Notification service . . . . . . . . . . . . . . . . . . . . 7 65 10. pn-prid and pn-type URI parameters for Google Firebase Cloud 66 Messaging (FCM) push notification service . . . . . . . . . . 8 67 11. Security considerations . . . . . . . . . . . . . . . . . . . 8 68 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 69 12.1. pn-prid . . . . . . . . . . . . . . . . . . . . . . . . 9 70 12.2. pn-type . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12.3. pn-enckey . . . . . . . . . . . . . . . . . . . . . . . 9 72 12.4. pn-enccode . . . . . . . . . . . . . . . . . . . . . . . 9 73 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 10 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 13.1. Normative references . . . . . . . . . . . . . . . . . . 10 76 13.2. Informative references . . . . . . . . . . . . . . . . . 11 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 In order to save resources (e.g, battery life) some devices and 82 operating systems require suspended Session Initiation Protocol (SIP) 83 User Agents (UAs) [RFC3261] to be woken up using a push notification 84 service. Typically each operating system uses a dedicated push 85 notification service. For example, Apple iOS devices use the Apple 86 Push Notification service (APNs). 88 Due to the restriction above, applications can not be woken up by 89 non-push notification traffic. This means that a suspended SIP UA 90 will not be able to receive an incoming SIP request (e.g., a SIP 91 INVITE request). 93 This document describes how push notification mechanisms can be used 94 to wake up suspended SIP UAs, in order to be able to receive and 95 generate SIP requests. The document defines new SIP URI parameters, 96 that can be used in a SIP REGISTER request to provide push 97 notification information from the SIP UA to the SIP entity (realized 98 as a SIP proxy in this document) that will send a push request to the 99 push server in order to trigger a push notification towards the SIP 100 UA. 102 When a SIP UA registers to a push service, it will receive a unique 103 Push Resource ID (PRID) associated to that registration. The SIP UA 104 will provide the PRID to the SIP network in a SIP REGISTER request. 105 A SIP proxy (e.g., the SIP registrar) will store a mapping between 106 the registered contact and the PRID. 108 When the SIP proxy receives a SIP request for a new session, or a 109 stand-alone SIP request, addressed towards a SIP UA, the SIP proxy 110 will send a push request to the push notification service used by the 111 SIP UA, using the push resource ID associated with the registered 112 contact of the SIP UA, in order to trigger a push notification 113 towards the SIP UA. The SIP proxy will then forward the SIP request 114 towards the SIP UA using normal SIP routing procedures. Once the SIP 115 UA receives the push notification, it will be able to receive the SIP 116 request (and generate a SIP request itself, if needed). 118 Different push notification mechanisms exist today. Some are based 119 on there standardized mechanism defined in [RFC8030], while others 120 are proprietary (e.g., the Apple Push Notification service). 121 Figure 1 shows the generic push notification architecture supported 122 by the mechanism in this document. 124 +--------+ +--------------+ +-----------------+ 125 | SIP UA | | Push Service | | SIP Proxy | 126 +--------+ +--------------+ +-----------------+ 127 | | | 128 | Subscribe | | 129 |--------------------->| | 130 | | | 131 | Push Resource ID | | 132 |<---------------------| | 133 | | | 134 | SIP REGISTER (Push Resource ID) | 135 |===============================================>| 136 | | | 137 | | Push Message | 138 | | (Push Resource ID) | 139 | Push Message |<------------------------| 140 | (Push Resource ID) | | 141 |<---------------------| | 142 | | | 144 ------- Push Notification API 146 ======= SIP 148 REGISTER sip:alice@example.com SIP/2.0 149 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 150 Max-Forwards: 70 151 To: Alice 152 From: Alice ;tag=456248 153 Call-ID: 843817637684230@998sdasdh09 154 CSeq: 1826 REGISTER 155 Contact: 158 Expires: 7200 159 Content-Length: 0 161 Figure 1: SIP Push Notification Architecture 163 2. Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 3. Push Resource ID (PRID) 171 When an entity registers with a Push Notification Server (PNS) is 172 receives a unique Push Resource ID (PRID), which is a value 173 associated with the registration. 175 The format of the PRID may vary depending on the PNS provider. The 176 PRID may be part of a URI that can be used to retrieve the address 177 and port of the PNS when sending push requests to the PNS. The PRID 178 may also be a token value, in which case the address and port of the 179 PNS needs to be provided using other means. 181 The details regarding discovery of the PNS, and the procedures for 182 the push notification registration and maintenance are outside the 183 scope of this document. The information needed to contact the PNS is 184 typically pre-configured in the operating system (OS) of the device. 186 4. SIP User Agent (UA) Behavior 188 Once the SIP UA has registered with the PNS and received the PRID, 189 and when the UA wants to receive push notifications triggered by the 190 SIP proxy, the UA MUST send a SIP REGISTER using normal SIP 191 registration procedures. The UA MUST add a pn-prid URI parameter and 192 a pn-type URI parameter to the SIP Contact header field URI of the 193 request. The pn-prid URI parameter contains the PRID value. The pn- 194 type contains additional, PNS-specific, information. 196 As long as the UA wants the SIP proxy to continue sending push 197 requests, the UA MUST include the pn-prid and pn-type URI parameters 198 in every re-registration SIP REGISTER request sent towards the SIP 199 proxy. Note that, in some cases, the PNS might update the PRID 200 value, in which case the re-registration SIP REGISTER request will 201 contain the new value. 203 If the UA at some point wants to stop the SIP proxy from sending push 204 requests, the UA MUST send a SIP REGISTER request without the pn-prid 205 and pn-type URI parameters. 207 If the UA expects to receive payload in the push notification, the UA 208 MAY add a pn-enckey and a pn-encsec Contact header field URI 209 parameter, in order to allow encryption of the data using the 210 mechanism in [I-D.ietf-webpush-encryption]. The pn-enckey URI 211 parameter contains the public key, and the pn-encsec URI parameter 212 contains the authentication secret [I-D.ietf-webpush-encryption]. 214 NOTE: End-to-end encryption of the payload between the SIP proxy and 215 the SIP UA cannot be used if the push notification request payload 216 contains information that needs to be accessible by the push 217 notification server. 219 5. SIP Proxy Behavior 221 When the SIP proxy receives a SIP request for a new dialog (e.g., a 222 SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE 223 request) aimed for a SIP UA, if the Request-URI of the request 224 contains a pn-prid URI parameter, the SIP proxy triggers a push 225 request towards the push notification server associated with the 226 PRID. After that, the SIP proxy forwards the SIP request towards the 227 SIP UA using normal SIP procedures. 229 The SIP proxy MUST NOT transport the SIP request as push request 230 payload, instead of forwarding the request using normal SIP 231 procedures. 233 In some cases the push notification provider can be retrieved from 234 the pn-prid URI parameter. In other cases the pn-type URI parameter 235 is used to identity the push notification provider. 237 If the proxy is not able to contact the push notification provider, 238 or even determine which push notification provider to contact, it 239 SHOULD reject the SIP request. 241 The protocol and format used for the push request depends on the push 242 notification provider, and the details for constructing and sending 243 the messages are outside the scope of this specification. 245 6. Network Address Translator (NAT) Considerations 247 Whenever the UA receives a push notification, if the SIP UA is 248 located behind a Network Address Translator (NAT), the UA might need 249 to take actions in order to establish a binding in the NAT, in order 250 for an incoming SIP request to reach the UA. [RFC5626] and [RFC6223] 251 define such mechanisms. This document does not require usage of a 252 specific mechanism. 254 7. Grammar 256 The section defines new SIP URI parameters, by extending the grammar 257 for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: 259 uri-parameter =/ pn-prid / pn-type / pn-enccode / pn-enckey 260 pn-prid = "pn-prid" EQUAL pvalue 261 pn-type = "pn-type" EQUAL pns-provider COLON pns-param 262 pn-enccode = "pn-enccode" EQUAL pvalue 263 pn-enckey = "pn-enckey" EQUAL pvalue 265 pns-provider = pvalue ; Colon (":") characters MUST be escaped 266 pns-param = pvalue ; Colon (":") characters MUST be escaped 268 ; pvalue as defined in RFC 3261 269 ; EQUAL as defined in RFC 3261 270 ; COLON as defined in RFC 3261 272 The format and semantics of pns-param is specific to a given 273 pns-provider value. 275 8. PNS Registration Requirements 277 When a new value is registered to the PNS Sub-registry, a reference 278 to a specification which describes the push notification service 279 associated with the value is provided. That specification MUST 280 contain the following information: 282 o How the values for the pn-prid parameter is retrieved and set by 283 the SIP UA. 284 o The format of the pns-param part of the pns-type parameter, and 285 how the value of the pns-param part is retrieved and set by the 286 SIP UA. 287 o Whether there are any restrictions regarding usage of payload 288 encryption [I-D.ietf-webpush-encryption] with the associated push 289 notification service. 291 9. pn-prid and pn-type URI parameters for Apple Push Notification 292 service 294 When the Apple Push Notification service (APNs) is used, the value of 295 the pn-type URI parameter pns-provider parameter part is "apns". The 296 pns-param part contains the APNs App ID, which is encoded by two 297 values, separated by a period (.): Team ID and Bundle ID. The Team 298 ID is provided by Apple and is unique to a development team. The 299 Bundle ID is unique to a development team, and is a string that will 300 can match a single application or a group of applications. 302 Example: pn-type = apns:DEF123GHIJ.com.yourcompany.yourexampleapp 304 When the Apple Push Notification service (APNs) is used, pn-type URI 305 parameter pns-prid parameter part contains the device token, which is 306 a unique identifier assigned by Apple to a specific app on a specific 307 device. 309 Example: pn-prid = 00fc13adff78512 311 For more information on the APNs App ID: 313 https://developer.apple.com/library/content/documentation/General/ 314 Conceptual/DevPedia-CocoaCore/AppID.html 316 For more information on the APNs device token: 318 https://developer.apple.com/library/content/documentation/NetworkingI 319 nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re 320 f/doc/uid/TP40008194-CH8-SW13 322 10. pn-prid and pn-type URI parameters for Google Firebase Cloud 323 Messaging (FCM) push notification service 325 When Firebase Cloud Messaging (FCM) is used, the value of the pn-type 326 URI parameter pns-provider parameter part is "fcm". The pns-param 327 part contains the Sender ID. 329 When Firebase Cloud Messaging (FCM) is used, pn-type URI parameter 330 pns-prid parameter part contains the Registration token, which 331 generated by the FCM SDK for each client app instance. 333 For more information on the Sender ID and Registration token: 335 https://firebase.google.com/docs/cloud-messaging/concept-options 337 11. Security considerations 339 In addition to the information exchanged between a device and its PNS 340 in order to establish a push notification subscription, the mechanism 341 in this document does not require entities to provide any additional 342 information to the PNS. 344 Push notification mechanisms provide different methods to ensure that 345 malicious user cannot trigger push notifications to a device. Users 346 of the mechanism in this document MUST take measures to prevent push 347 notifications from being sent to a device from a malicious user. 349 In case entities do want to include payload in the push 350 notifications, this document defines the means for using end-to-end 351 payload encryption between the entity sending the push request and 352 the entity receiving the associated push notification. 354 12. IANA considerations 356 This specification defines new SIP URI parameters that extend the 357 registry created by [RFC3969]: 359 12.1. pn-prid 361 Parameter Name: pn-prid 363 Predefined Values: No 365 Reference: RFC XXXX 367 12.2. pn-type 369 Parameter Name: pn-type 371 Predefined Values: No 373 Reference: RFC XXXX 375 12.3. pn-enckey 377 Parameter Name: pn-enckey 379 Predefined Values: No 381 Reference: RFC XXXX 383 12.4. pn-enccode 385 Parameter Name: pn-enccode 387 Predefined Values: No 389 Reference: RFC XXXX 391 12.5. PNS Sub-registry Establishment 393 This section creates a new sub-registry, "PNS", under the sip- 394 parameters registry: http://www.iana.org/assignments/sip-parameters. 396 The purpose of the sub-registry is to register SIP URI pn-type 397 values. 399 This sub-registry is defined as a table that contains the following 400 three columns: 402 Value: The token under registration 404 Description: The name of the push notification service 406 Document: A reference to the document defining the registration 408 This specification registers the following values: 410 Value Description Document 411 ------- ---------------------------------- ---------- 413 apns Apple Push Notification service [RFC XXXX] 414 fcm Firebase Cloud Messaging [RFC XXXX] 416 13. References 418 13.1. Normative references 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, . 425 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 426 A., Peterson, J., Sparks, R., Handley, M., and E. 427 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 428 DOI 10.17487/RFC3261, June 2002, . 431 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 432 (IANA) Uniform Resource Identifier (URI) Parameter 433 Registry for the Session Initiation Protocol (SIP)", 434 BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, 435 . 437 [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic 438 Event Delivery Using HTTP Push", RFC 8030, 439 DOI 10.17487/RFC8030, December 2016, . 442 13.2. Informative references 444 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 445 "Managing Client-Initiated Connections in the Session 446 Initiation Protocol (SIP)", RFC 5626, 447 DOI 10.17487/RFC5626, October 2009, . 450 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 451 RFC 6223, DOI 10.17487/RFC6223, April 2011, 452 . 454 [I-D.ietf-webpush-encryption] 455 Thomson, M., "Message Encryption for Web Push", draft- 456 ietf-webpush-encryption-09 (work in progress), September 457 2017. 459 Author's Address 461 Christer Holmberg 462 Ericsson 463 Hirsalantie 11 464 Jorvas 02420 465 Finland 467 Email: christer.holmberg@ericsson.com