idnits 2.17.1 draft-ietf-sipcore-locparam-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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2018) is 2094 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) ** Downref: Normative reference to an Informational RFC: RFC 3325 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE J. Winterbottom 3 Internet-Draft Winterb Consulting Services 4 Updates: RFC6442 (if approved) R. Jesske 5 Intended status: Standards Track Deutsche Telekom 6 Expires: February 3, 2019 B. Chatras 7 Orange Labs 8 A. Hutton 9 Unify 10 August 2, 2018 12 Location Source Parameter for the SIP Geolocation Header Field 13 draft-ietf-sipcore-locparam-00.txt 15 Abstract 17 There are some circumstances where a geolocation header field may 18 contain more than one location value. Knowing the identity of the 19 node adding the location value allows the recipient more freedom in 20 selecting the value to look at first rather than relying solely on 21 the order of the location values. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 3, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Registration of loc-src Parameter for geolocation header 66 field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 10.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The SIP geolocation specification [RFC6442] describes the 76 "Geolocation" SIP header field which is used to indicate that the SIP 77 message is conveying location information. The specification 78 suggests that only one location value should be conveyed. However, 79 some communications architectures, such as 3GPP [TS23-167] and ETSI 80 [M493], prefer to use information provided by edge-proxies or 81 acquired through the use of core-network nodes, before using 82 information provided solely by user equipment (UE). These solutions 83 don't preclude the use of UE provided location but require a means of 84 being able to distinguish the identity of the node adding the 85 location value to the SIP message from that provided by the UE. 87 [RFC6442] stipulates that the order of location values in the 88 geolocation header field is the same as the order in which they were 89 added to the header field. Whilst this order provides guidance to 90 the recipient as to which values were added to the message earlier in 91 the communication chain, it does not provide any indication of which 92 node actually added the location value. Knowing the identity of the 93 entity that added the location to the message allows the recipient to 94 choose which location to consider first rather than relying solely on 95 the order of the location values in the geolocation header field. 97 This document adds a location-source (loc-src) parameter to the 98 location values in [RFC6442] so that the entity adding the location 99 value to geolocation header field can identify itself using its 100 hostname. How the entity adding the location value to the header 101 field obtains the location information is out of scope of this 102 document. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Rationale 112 The primary intent of the parameter defined in this specific is for 113 use in emergency calling. There are various architectures defined 114 for providing emergency calling using SIP-based messaging. Each has 115 it own characteristics with corresponding pros and cons. All of them 116 allow the UE to provide location information, however, many also 117 attach other sources of location information to support veracity 118 checks, provide backup information, or to be used as the primary 119 location. 121 This document makes no attempt to comment on these various 122 architectures or the rationale for them wishing to include multiple 123 location values. It does recognize that these architectures exist 124 and that there is a need to identify the entity adding the location 125 information. 127 The parameter defined in this specification adds the location source 128 generating the location value to increase the trustworthiness of the 129 location information. 131 The loc-src parameter is applicable within a single private 132 administrative domain or between different administrative domains 133 where there is a trust relationship between the domains. Thus it is 134 intended to use this parameter only in trust domains where Spec(T) as 135 described in [RFC3325] exists. 137 The loc-src parameter is not included in a SIP message sent to 138 another network if there is no trust relationship. The The loc-src 139 parameter is not applicable if the administrative domain manages 140 emergency calls in a way that does not require location source 141 generating the location. 143 The functional architecture described within ETSI [M493] is an 144 example of architecture where this parameter makes sense to be used. 146 4. Mechanism 148 The mechanism employed adds a parameter to the location value defined 149 in [RFC6442] that identifies the hostname of the entity adding the 150 location value to the geolocation header field. The Augmented BNF 151 (ABNF) [RFC5234] for this parameter is shown in Figure 1. 153 location-source = "loc-src=" (hostname ) 154 hostname = 156 Figure 1: Location Source 158 Only a fully qualified host name is valid, an IP address MUST NOT be 159 added by an entity conforming with this specification. If a node 160 conforming to this specification receives a geolocation header field 161 with a loc-src parameter containing an IP address then the parameter 162 MUST be removed. 164 Any proxy adding a location value to a geolocation header field 165 SHOULD also add its host name using the loc-src parameter so that it 166 is clearly identified as the node adding the location. A UE MUST NOT 167 provide a loc-src parameter value. If a proxy receives a message 168 from an untrusted source with the loc-src parameter set then it MUST 169 remove the loc-src parameter before passing the message into a 170 trusted network. 172 5. Example 174 The following example shows a SIP INVITE message containing a 175 geolocation header field with two location values. The first 176 location value points to a PIDF-LO in the SIP body using a content- 177 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 178 The second location value is an https URI the provided by a proxy 179 which identifies itself using the loc-src parameter. 181 INVITE sips:bob@biloxi.example.com SIP/2.0 182 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 183 Max-Forwards: 70 184 To: Bob 185 From: Alice ;tag=9fxced76sl 186 Call-ID: 3848276298220188511@atlanta.example.com 187 Geolocation: , 188 ; 189 loc-src=edgeproxy.example.com 190 Geolocation-Routing: yes 191 Accept: application/sdp, application/pidf+xml 192 CSeq: 31862 INVITE 193 Contact: 194 Content-Type: multipart/mixed; boundary=boundary1 195 Content-Length: ... 197 Figure 2: Example Location Request. 199 6. Privacy Considerations 201 This document doesn't change any of the privacy considerations 202 described in [RFC6442]. While the addition of the loc-src parameter 203 does provide an indicator of the entity that added the location in 204 the signaling path this provides little more exposure than a proxy 205 identity being added to the record-route header field. 207 7. Security Considerations 209 This document introduces the ability of a proxy or middle box to 210 insert a host name indicating the that they added the specific 211 location value to the geolocation header field. The intent is for 212 this field to be used by the location recipient in the event that the 213 SIP message contains multiple location values. As a consequence this 214 parameter should only be used by the location recipient in a trusted 215 network. 217 The use of this parameter is not restricted to a specific 218 architecture but using multiples locations and loc-src may end in 219 compatibility issues. [RFC6442] already addresses the issue of 220 multiples locations. To avoid problems of wrong interpretation of 221 loc-src the value may be discarded when passed to an other domain. 223 8. IANA Considerations 225 8.1. Registration of loc-src Parameter for geolocation header field 227 This document calls for IANA to register a new SIP header parameter 228 as per the guidelines in [RFC3261], which will be added to header 229 sub-registry under http://www.iana.org/assignments/sip-parameters. 231 Header Field: geolocation 233 Parameter Name: loc-src 235 9. Acknowledgements 237 The authors would like to thank Dale Worley for his extensive review 238 of the draft The authors would like to acknowledge the constructive 239 feedback provided by Paul Kyziva and Christer Holmberg. 241 10. References 243 10.1. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 251 A., Peterson, J., Sparks, R., Handley, M., and E. 252 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 253 DOI 10.17487/RFC3261, June 2002, 254 . 256 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 257 Extensions to the Session Initiation Protocol (SIP) for 258 Asserted Identity within Trusted Networks", RFC 3325, 259 DOI 10.17487/RFC3325, November 2002, 260 . 262 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 263 Specifications: ABNF", STD 68, RFC 5234, 264 DOI 10.17487/RFC5234, January 2008, 265 . 267 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 268 for the Session Initiation Protocol", RFC 6442, 269 DOI 10.17487/RFC6442, December 2011, 270 . 272 10.2. Informative References 274 [M493] European Telecommunications Standards Institute, 275 "Functional architecture to support European requirements 276 on emergency caller location determination and transport", 277 ES 203 178, V 1.1.1, Februar 2015. 279 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 280 Session Initiation Protocol (SIP) Messages", RFC 4483, 281 DOI 10.17487/RFC4483, May 2006, 282 . 284 [TS23-167] 285 3rd Generation Partnership Project, "3rd Generation 286 Partnership Project; Technical Specification Group 287 Services and System Aspects; IP Multimedia Subsystem (IMS) 288 emergency sessions", TS 23.167, V 12.1.0, March 2015. 290 Authors' Addresses 292 James Winterbottom 293 Winterb Consulting Services 294 Gwynneville, NSW 2500 295 AU 297 Phone: +61 448 266004 298 Email: a.james.winterbottom@gmail.com 299 Roland Jesske 300 Deutsche Telekom 301 Heinrich-Hertz Str, 3-7 302 Darmstadt 64295 303 Germany 305 Email: r.jesske@telekom.de 306 URI: www.telekom.de 308 Bruno Chatras 309 Orange Labs 310 38-40 rue du General Leclerc 311 Issy Moulineaux Cedex 9 F-92794 312 France 314 Email: bruno.chatras@orange.com 316 Andrew Hutton 317 Unify 318 Technology Drive 319 Nottingham NG9 1LA 320 UK 322 Email: andrew.hutton@unify.com