idnits 2.17.1 draft-holmberg-sipcore-sip-push-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4028, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4028, updated by this document, for RFC5378 checks: 1999-10-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 9, 2017) is 2390 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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 Updates: 4028 (if approved) October 9, 2017 5 Intended status: Standards Track 6 Expires: April 12, 2018 8 Push Notification with the Session Initiation Protocol (SIP) 9 draft-holmberg-sipcore-sip-push-00 11 Abstract 13 This document describes how push notification mechanisms can be used 14 to wake up idle Session Initiation Protocol (SIP) applications, in 15 order to be able to receive and process SIP requests. The document 16 defines new SIP URI parameters, that can be used in a SIP REGISTER 17 request to provide push notification information from the SIP User 18 Agent (UA) to the SIP entity (realized as a SIP proxy in this 19 document) that will send a push request to the push server in order 20 to trigger a push notification towards the SIP UA. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 12, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5 59 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 5 60 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6 61 6. Network Address Translator (NAT) Considerations . . . . . . . 6 62 7. Security considerations . . . . . . . . . . . . . . . . . . . 6 63 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. pn-token . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.2. pn-type . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.3. pn-enckey . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.4. pn-enccode . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative references . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative references . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 In order to save resources (e.g, battery life) some devices and 76 operating systems require idle applications to be woken up using a 77 push notification service. Typically each operating system uses a 78 dedicated push notification service. For example, Apple iOS devices 79 use the Apple Push Notification Service (APNS). 81 Due to the restriction above, applications can not be woken up by 82 non-push notification traffic. This means that an idle Session 83 Initiation Protocol (SIP) [RFC3261] User Agent (UA) will not be able 84 to receive an incoming SIP request, e.g., an SIP INVITE request 85 initiating a new SIP session. 87 This document describes how push notification mechanisms can be used 88 to wake up idle SIP applications, in order to be able to receive and 89 process SIP requests. The document defines new SIP URI parameters, 90 that can be used in a SIP REGISTER request to provide push 91 notification information from the SIP UA to the SIP entity (realized 92 as a SIP proxy in this document) that will send a push request to the 93 push server in order to trigger a push notification towards the SIP 94 UA. 96 When a SIP UA registers to a push service, it will receive a unique 97 Push Resource ID (PRID) associated to that registration. The SIP UA 98 will provide the PRID to the SIP network in a SIP REGISTER request. 99 A SIP proxy (e.g., the SIP registrar) will store a mapping between 100 the registered contact and the PRID. 102 When the SIP entity receives a SIP request for a new session, or a 103 stand-alone SIP request, addressed towards a SIP UA, the SIP entity 104 will send a push request to the push service used by the SIP UA, 105 using the push resource ID associated with the registered contact of 106 the SIP UA, in order to trigger a push notification towards the SIP 107 UA. The SIP entity will then forward the SIP request towards the SIP 108 UA using normal SIP routing procedures. Once the SIP UA receives the 109 push notification, it will be able to receive and process the SIP 110 request. 112 Different push notification mechanisms exist today. Some are based 113 on there standardized mechanism defined in [RFC8030], while others 114 are proprietary (e.g., the Apple Push Notification Service). 115 Figure 1 shows the generic push notification architecture supported 116 by the mechanism in this document. 118 +--------+ +--------------+ +-----------------+ 119 | SIP UA | | Push Service | | SIP Proxy | 120 +--------+ +--------------+ +-----------------+ 121 | | | 122 | Subscribe | | 123 |--------------------->| | 124 | | | 125 | Push Resource ID | | 126 |<---------------------| | 127 | | | 128 | SIP REGISTER (Push Resource ID) | 129 |===============================================>| 130 | | | 131 | | Push Message | 132 | Push Message |<------------------------| 133 |<---------------------| | 134 | | | 136 ------- Push Notification API 138 ======= SIP 140 REGISTER sip:alice@example.com SIP/2.0 141 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 142 Max-Forwards: 70 143 To: Alice 144 From: Alice ;tag=456248 145 Call-ID: 843817637684230@998sdasdh09 146 CSeq: 1826 REGISTER 147 Contact: 150 Expires: 7200 151 Content-Length: 0 153 Figure 1: SIP Push Notification Architecture 155 2. Conventions 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. Push Resource ID (PRID) 163 When an entity registers with a Push Notification Server (PNS) is 164 receives a unique Push Resource ID (PRID), which is a value 165 associated with the registration. 167 The format of the PRID may vary depending on the PNS provider. The 168 PRID may be part of a URI that can be used to retrieve the address 169 and port of the PNS when sending push requests to the PNS. The PRID 170 may also be a token value, in which case the address and port of the 171 PNS needs to be provided using other means. 173 The details regarding discovery of the PNS, and the procedures for 174 the push notification registration and maintenance are outside the 175 scope of this document. The information needed to contact the PNS is 176 typically pre-configured in the operating system (OS) of the device. 178 4. SIP User Agent (UA) Behavior 180 Once the SIP UA has registered with the PNS received the PRID, when 181 then UA wants to receive push notifications triggered by the SIP 182 proxy, the UA MUST send a SIP REGISTER using normal SIP registration 183 procedures. The UA MUST add a pn-token URI parameter, and MAY add a 184 pn-type URI parameter, to the SIP Contact header field URI of the 185 request. 187 As long as the UA wants the SIP proxy to continue sending push 188 requests, the UA MUST include the pn-token Contact header field URI 189 parameter in every re-registration SIP REGISTER request sent towards 190 the SIP proxy. 192 If the UA at some point wants to stop the SIP proxy from sending push 193 requests, the UA MUST send a SIP REGISTER request without the pn- 194 token Contact header field URI parameter. 196 If the UA expects to receive payload in the push notification, the UA 197 MAY add a pn-enckey and a pn-encsec Contact header field URI 198 parameter, in order to allow encryption of the data using the 199 mechanism in [I-D.ietf-webpush-encryption]. The pn-enckey URI 200 parameter contains the public key, and the pn-encsec URI parameter 201 contains the authentication secret [I-D.ietf-webpush-encryption]. 203 Whenever the UA receives a push notification request, it MUST assume 204 that it is about to receive a SIP request. 206 5. SIP Proxy Behavior 208 When the SIP proxy receives a SIP request for a new dialog (e.g., a 209 SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE 210 request) aimed for a SIP UA, if the Request-URI of the request 211 contains a pn-token URI parameter, the SIP proxy triggers a push 212 request towards the push notification server associated with the 213 PRID. After that, the SIP proxy forwards the SIP request towards the 214 SIP UA using normal SIP procedures. 216 The SIP proxy MUST NOT transport the SIP request as push request 217 payload, instead of forwarding the request using normal SIP 218 procedures. 220 In some cases the push notification provider can be retrieved from 221 the pn-token URI parameter. In other cases the pn-type URI parameter 222 is used to identity the push notification provider. 224 If the proxy is not able to contact the push notification provider, 225 or even determine which push notification provider to contact, it 226 SHOULD reject the SIP request. 228 The protocol and format used for the push request depends on the push 229 notification provider, and the details for constructing and sending 230 the messages are outside the scope of this specification. 232 6. Network Address Translator (NAT) Considerations 234 Whenever the UA receives a push notification, if the SIP UA is 235 located behind a Network Address Translator (NAT), the UA might need 236 to take actions in order to establish a binding in the NAT, in order 237 for an incoming SIP request to reach the UA. [RFC5626] and [RFC6223] 238 define such mechanisms. This document does not require usage of a 239 specific mechanism. 241 7. Security considerations 243 In addition to the information exchanged between a device and its PNS 244 in order to esatblish a push notification subscription, the mechanism 245 in this document does not require entities to provide any additional 246 information to the PNS. 248 Push notification mechanisms provide different methods to ensure that 249 malicious user cannot trigger push notifications to a device. Users 250 of the mechanism in this document MUST take measures to prevent push 251 notifications from being sent to a device from a malicious user. 253 In case entities do want to include payload in the push 254 notifications, this document defines the means for using end-to-end 255 paylod encryption between the entity sending the push request and the 256 entity receiving the associated push notification. 258 8. IANA considerations 260 This specification defines new SIP URI parameters that extend the 261 registry created by [RFC3969]: 263 8.1. pn-token 265 The "pn-token" parameter contains a push notification provider- 266 specific value that was provided by the push notification Provider to 267 the UA. The value uniquely identifies the UA's push notification 268 subscription. 270 8.2. pn-type 272 The "pn-type" parameter identifies the push notification provider and 273 can be used in combination with "pn-token". It is up to the specific 274 push notification provider to make use of this parameter. 276 8.3. pn-enckey 278 The "pn-enckey" parameter contains a public key, as defined in 279 [I-D.ietf-webpush-encryption]. 281 8.4. pn-enccode 283 The "pn-encsec" parameter contains an authentication secret, as 284 defined in [I-D.ietf-webpush-encryption]. 286 9. References 288 9.1. Normative references 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, . 295 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 296 A., Peterson, J., Sparks, R., Handley, M., and E. 297 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 298 DOI 10.17487/RFC3261, June 2002, . 301 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 302 (IANA) Uniform Resource Identifier (URI) Parameter 303 Registry for the Session Initiation Protocol (SIP)", 304 BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, 305 . 307 [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic 308 Event Delivery Using HTTP Push", RFC 8030, 309 DOI 10.17487/RFC8030, December 2016, . 312 9.2. Informative references 314 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 315 "Managing Client-Initiated Connections in the Session 316 Initiation Protocol (SIP)", RFC 5626, 317 DOI 10.17487/RFC5626, October 2009, . 320 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 321 RFC 6223, DOI 10.17487/RFC6223, April 2011, 322 . 324 [I-D.ietf-webpush-encryption] 325 Thomson, M., "Message Encryption for Web Push", draft- 326 ietf-webpush-encryption-09 (work in progress), September 327 2017. 329 Author's Address 331 Christer Holmberg 332 Ericsson 333 Hirsalantie 11 334 Jorvas 02420 335 Finland 337 Email: christer.holmberg@ericsson.com