idnits 2.17.1 draft-holmberg-dispatch-received-realm-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 : ---------------------------------------------------------------------------- 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 (June 8, 2015) is 3238 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 (==), 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 J. Jiang 5 Expires: December 10, 2015 China Mobile 6 June 8, 2015 8 Via header field parameter to indicate received realm 9 draft-holmberg-dispatch-received-realm-00.txt 11 Abstract 13 This specification defines a new Session Initiation Protocol (SIP) 14 Via header field parameter, "received-realm", which allows a SIP 15 entity acting as an entry point to a transit network to indicate from 16 which adjacent upstream network a SIP request is received, using a 17 network realm value associated with the adjacent network. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 10, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.2. Use-Case: Transit Network Application Services . . . . . 3 56 1.3. Use-Case: Transit Network Routing . . . . . . . . . . . . 3 57 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4 61 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.2. Behavior of a SIP entity acting as a network entry point 4 63 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. 'received-realm' Via header field parameter . . . . . . . 6 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 12.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 1.1. General 81 When SIP sessions are established between networks belonging to 82 different operators, or between interconnected networks belonging to 83 the same operator (or enterprise), the SIP requests might traverse 84 transit network. 86 Such transit networks might provide different kind of services. In 87 order to do that, a transit network often needs to know to which 88 operator (or enterprise) the adjacent upstream network, from which 89 the SIP session initiation request is received, belongs. 91 This specification defines a new Session Initiation Protocol (SIP) 92 Via header field parameter, "received-realm", which allows a SIP 93 entity acting as an entry point to a transit network to indicate from 94 which adjacent upstream network a SIP request is received, using a 95 network realm value associated with the adjacent network. 97 NOTE: As the adjacent network can be an enterprise network, an Inter 98 Operator Identifier (IOI) cannot be used to identity the network, as 99 IOIs are not defined for enterprise networks. 101 The following sections describe use-case where the information is 102 needed. 104 1.2. Use-Case: Transit Network Application Services 106 The 3rd Generation Partnership Project (3GPP) TS 23.228 specifies how 107 an IP Multimedia Subsystem (IMS) network can be used to provide 108 transit functionality. An operator can use its IMS network to 109 provide transit functionality e.g. to non-IMS customers, to 110 enterprise networks, and to other network operators. 112 The transit network operator can provide application services to the 113 networks for which it is providing transit functionality. Transit 114 application services are typically not provided per user basis, as 115 the transit network does not have access to the user profiles of the 116 networks for which the application services are provided. Instead, 117 the application services are provided per served network. 119 When a SIP entity that provides application services (e.g. an 120 Application Server) within a transit network receives a SIP request, 121 in order to apply the correct services it needs to know the adjacent 122 upstream network from which the SIP request is received. 124 1.3. Use-Case: Transit Network Routing 126 A transit network operator normally interconnects to many diferent 127 operators, including other transit network operators, and provides 128 transit routing of SIP requests received from one operator network 129 towards the destination. The destination can be within an operator 130 network to which the transit network operator has a direct 131 interconnect, or within an operator network that only can be reached 132 via one or more interconnected transit operators. 134 For each customer, i.e. interconnected network operator for which, 135 the transit network operator routes SIP requests towards the 136 requested destination a set of transit routing polices are defined. 137 These policies are used to determine how a SIP request shall be 138 routed towards the requested destination to meet the agreement the 139 transit network operator has with its customer. 141 When a SIP entity that performs the transit routing functionality 142 receives a SIP request, in order to apply the correct set of transit 143 routing policies, it needs to know from which of its customers, i.e. 144 adjacent upstream network, the SIP request is received. 146 2. Applicability 148 The mechanism defined in this specification MUST only be used by SIP 149 entities that are able to verify from which adjacent upstream network 150 a SIP request is received. 152 The mechanism for verifying from which adjacent upstream network a 153 SIP request is received is outside the scope of this specification. 155 3. 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 BCP 14, RFC 2119 160 [RFC2119]. 162 4. Definitions 164 SIP entity: SIP User Agent (UA), or SIP proxy, as defined in RFC 165 3261. 167 Adjacent upstream SIP network: The adjacent SIP network in the 168 direction from which a SIP request is received. 170 Network entry point: A SIP entity on the border of network, which 171 receives SIP requests from adjacent upstream networks. 173 Inter Operator Identifier (IOI): A globally unique identifier to 174 correlate billing information generated within the IP Multimedia 175 Subsystem (IMS). 177 5. User Agent and Proxy behavior 179 5.1. General 181 This section describes how a SIP entity, acting as an entry point to 182 a network, uses the "received-realm" Via header field parameter. 184 5.2. Behavior of a SIP entity acting as a network entry point 186 When a SIP entity, acting as a network entry point, forwards a SIP 187 request, or initiates a SIP request on its own (e.g. a PSTN gateway), 188 the SIP entity adds a Via header field to the SIP request, according 189 to the procedures in RFC 3261 [RFC3261]. In addition, if the SIP 190 entity is able to assert the adjacent upstream network, and if the 191 SIP entity is aware of a network realm value defined for that 192 network, the SIP entity can add a "received-realm" Via header field 193 parameter, conveying the network realm value, to the Via header field 194 added to the SIP request. 196 When the SIP entity adds a "received-realm" Via header field 197 parameter to a SIP request, it MUST also calculate a Hash-based 198 message authentication code (HMAC) [RFC2104] value from the parameter 199 value, using a secret key which is shared between the SIP entity and 200 any SIP entity which will use the parameter value. The HMAC is then 201 added to the parameter. 203 6. Example 205 Operator 1 T_EP T_AS 207 - INVITE ------> 208 Via: IP_UA 209 - INVITE ----------------------------> 210 Via: IP_TEP; received-realm=operator_1.com: 211 Via: IP_UA; received=IP_UA 213 <- 200 OK ---------------------------- 214 Via: IP_TEP; received-realm=operator_1.com: 215 Via: IP_UA; received=IP_UA 217 <- 200 OK------ 218 Via: IP_UA; received=IP_UA 220 7. Syntax 222 7.1. General 224 This section describes the syntax extensions to the ABNF syntax 225 defined in RFC 3261 [RFC3261], by defining a new Via header field 226 parameter, "received-realm". The ABNF defined in this specification 227 is conformant to RFC 5234 [RFC5234]. "EQUAL", "COLON" and "hostname" 228 are defined in RFC 3261 [RFC3261]. "DIGIT" is defined in RFC 5234 229 [RFC5234] 231 7.2. ABNF 233 via-params =/ received-realm 235 received-realm = "received-realm" EQUAL hostname COLON hmac 237 hmac = TBD 239 8. IANA Considerations 241 8.1. 'received-realm' Via header field parameter 243 This specification defines a new Via header field parameter called 244 received-realm in the "Header Field Parameters and Parameter Values" 245 sub-registry as per the registry created by [RFC3968]. The syntax is 246 defined in Section 7. The required information is: 248 Predefined 249 Header Field Parameter Name Values Reference 250 ---------------------- --------------------- ---------- --------- 251 Via received-realm No RFCXXXX 253 9. Security Considerations 255 As the received-realm Via header field parameter can be used to 256 trigger applications, it is important to ensure that the parameter 257 has not been added to the SIP message by an unauthorized SIP entity. 259 The operator MUST change the key on a frequent basis. The operator 260 also needs to take great care in ensuring that the key used to 261 calculate the Hash-based message authentication code (HMAC) value is 262 only known by the network entry point adding the received-realm Via 263 header field parameter to a SIP message and the entities that use the 264 parameter value. 266 A SIP entity MUST NOT use the parameter value it does not match the 267 associated HMAC value. The SIP entity MUST trigger an alarm, or use 268 a similar mechanism, to inform the operator about the mismatch. 270 A SIP entity MUST use different key values for each parameter value 271 that it recognizes and use to trigger actions. 273 10. Acknowledgements 275 TBD 277 11. Change Log 279 [RFC EDITOR NOTE: Please remove this section when publishing] 281 Changes from draft-holmberg-received-realm-04 283 o Changed IETF WG from sipcore do dispatch. 285 o HMAC value added to the parameter. 287 Changes from draft-holmberg-received-realm-03 289 o New version due to expiration. 291 Changes from draft-holmberg-received-realm-02 293 o New version due to expiration. 295 Changes from draft-holmberg-received-realm-01 297 o New version due to expiration. 299 Changes from draft-holmberg-received-realm-00 301 o New version due to expiration. 303 12. References 305 12.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 311 A., Peterson, J., Sparks, R., Handley, M., and E. 312 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 313 June 2002. 315 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 316 Specifications: ABNF", STD 68, RFC 5234, January 2008. 318 12.2. Informative References 320 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 321 Hashing for Message Authentication", RFC 2104, February 322 1997. 324 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 325 (IANA) Header Field Parameter Registry for the Session 326 Initiation Protocol (SIP)", BCP 98, RFC 3968, December 327 2004. 329 Authors' Addresses 330 Christer Holmberg 331 Ericsson 332 Hirsalantie 11 333 Jorvas 02420 334 Finland 336 Email: christer.holmberg@ericsson.com 338 Yi Jiang 339 China Mobile 340 No.32 Xuanwumen West Street 341 Beijing Xicheng District 100053 342 P.R. China 344 Email: jiangyi@chinamobile.com