idnits 2.17.1 draft-ietf-sipcore-locparam-05.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 (January 28, 2020) is 1542 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 (~~), 1 warning (==), 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: 6442 (if approved) R. Jesske 5 Intended status: Standards Track Deutsche Telekom 6 Expires: July 31, 2020 B. Chatras 7 Orange Labs 8 A. Hutton 9 Atos 10 January 28, 2020 12 Location Source Parameter for the SIP Geolocation Header Field 13 draft-ietf-sipcore-locparam-05 15 Abstract 17 There are some circumstances where a Geolocation header field may 18 contain more than one locationValue. Knowing the identity of the 19 node adding the locationValue allows the recipient more freedom in 20 selecting the value to look at first rather than relying solely on 21 the order of the locationValues. This document defines the "loc-src" 22 parameter so that the entity adding the locationValue to Geolocation 23 header field can identify itself using its hostname. This document 24 updates RFC 6442. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 31, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Registration of loc-src parameter for Geolocation header 69 field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 10.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The SIP Geolocation specification [RFC6442] describes the 79 "Geolocation" SIP header field which is used to indicate that the SIP 80 message is conveying location information. [RFC6442] specifies that 81 SIP intermediaries should not add locationValues to a SIP request 82 that already contains locationValue. [RFC6442] also states that if a 83 SIP intermediary adds location it is fully responsible for addressing 84 the concerns of any 424 (Bad Location Information) SIP response it 85 receives. However, some communications architectures, such as 3GPP 86 [TS23-167] and ETSI [M493], prefer to use information provided by 87 edge proxies or acquired through the use of core-network nodes, 88 before using information provided solely by user equipment (UE). 89 These solutions don't preclude the use of UE-provided location but 90 require a means of being able to distinguish the identity of the node 91 adding the locationValue to the SIP message from that provided by the 92 UE. 94 [RFC6442] stipulates that the order of locationValues in the 95 Geolocation header field is the same as the order in which they were 96 added to the header field. Whilst this order provides guidance to 97 the recipient as to which values were added to the message earlier in 98 the communication chain, it does not identify which node added the 99 locationValue. Knowing the identity of the entity that added the 100 location to the message allows the recipient to choose which location 101 to consider first rather than relying solely on the order of the 102 locationValues in the Geolocation header field. 104 This document extends the Geolocation header field of [RFC6442], by 105 allowing an entity adding the locationValue to identity itself using 106 a hostname. This is done by defining a new geoloc-param header field 107 parameter, "loc-src". How the entity adding the locationValue to the 108 header field obtains the location information is out of scope of this 109 document. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. Rationale 121 The primary intent of the "loc-src" parameter in this specification 122 is for use in emergency calling. There are various architectures 123 defined for providing emergency calling using SIP-based messaging. 125 Each has it own characteristics with corresponding pros and cons. 126 All of them allow the UE to provide location information; however, 127 many also attach other sources of location information to support 128 veracity checks, provide backup information, or to be used as the 129 primary location. 131 This document does not comment on these various architectures or on 132 the rationale for including multiple locationValues. It does 133 recognize that these architectures exist and that there is a need to 134 identify the entity adding the location information. 136 The "loc-src" parameter adds the location source generating the 137 locationValue to allow recipients to make informed decisions about 138 which of multiple values to use. 140 The "loc-src" parameter is applicable within a single private 141 administrative domain or between different administrative domains 142 where there is a trust relationship between the domains. Thus it is 143 intended to use this parameter only in trust domains where Spec(T) as 144 described in [RFC3325] exists. 146 The "loc-src" parameter is not included in a SIP message sent to 147 another network if there is no trust relationship. The "loc-src" 148 parameter is not applicable if the administrative domain manages 149 emergency calls in a way that does not require any generation of the 150 location. 152 The functional architecture described within ETSI [M493] is an 153 example of an architecture where it makes sense to use this 154 parameter. 156 4. Mechanism 158 The mechanism adds a geoloc-param parameter to the locationValue 159 defined in [RFC6442] that identifies the hostname of the entity 160 adding the locationValue to the Geolocation header field. The 161 Augmented BNF (ABNF) [RFC5234] for this parameter is shown in 162 Figure 1. 164 location-source = "loc-src" EQUAL hostname 165 hostname = 167 Figure 1: Location Source 169 Only a fully qualified host name is valid. The syntax does not 170 support IP addresses, and if an entity conforming to this 171 specification receives a Geolocation header field with a "loc-src" 172 parameter containing an IP address then the parameter MUST be 173 removed. 175 A SIP intermediary conformant to this specification adding a 176 locationValue to a Geolocation header field SHOULD also add a "loc- 177 src" header field parameter so that it is clearly identified as the 178 node adding the location. A User Agent (UA) MUST NOT insert a "loc- 179 src" header field parameter. If a SIP intermediary receives a 180 message from an untrusted source with the "loc-src" parameter set 181 then it MUST remove the "loc-src" parameter before passing the 182 message into a trusted network. 184 5. Example 186 The following example shows a SIP INVITE message containing a 187 Geolocation header field with two locationValues. The first 188 locationValue points to a PIDF-LO in the SIP body using a content- 189 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 190 The second locationValue is an https URI provided by a SIP 191 intermediary which identifies itself using the "loc-src" parameter. 193 INVITE sip:bob@biloxi.example.com SIP/2.0 194 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 195 Max-Forwards: 70 196 To: Bob 197 From: Alice ;tag=9fxced76sl 198 Call-ID: 3848276298220188511@atlanta.example.com 199 Geolocation: , 200 ; 201 loc-src=edgeproxy.example.com 202 Geolocation-Routing: yes 203 Accept: application/sdp, application/pidf+xml 204 CSeq: 31862 INVITE 205 Contact: 206 Content-Type: multipart/mixed; boundary=boundary1 207 Content-Length: ... 209 Figure 2: Example Location Request. 211 6. Privacy Considerations 213 This document doesn't change any of the privacy considerations 214 described in [RFC6442]. While the addition of the "loc-src" 215 parameter identifies the entity that added the location in the 216 signaling path, this addition provides little more exposure than 217 adding a proxy identity to the Record-Route header field. 219 7. Security Considerations 221 This document introduces the ability of a SIP intermediary to insert 222 a host name indicating that they added the specific locationValue to 223 the Geolocation header field. The intent is for this field to be 224 used by the location recipient in the event that the SIP message 225 contains multiple locationValues. As a consequence this parameter 226 should only be used by the location recipient in a trusted network. 228 As already stated in [RFC6442], securing the location hop-by-hop, 229 using TLS, protects the message from eavesdropping and modification 230 in transit, but exposes the information to all SIP intermediaries on 231 the path as well as the endpoint. The "loc-src" parameter is 232 applicable within a single private administrative domain or between 233 different administrative domains where there is a trust relationship 234 between the domains. If such trust domain is not given, it is 235 strongly recommended to delete the location information. 237 The use of this parameter is not restricted to a specific 238 architecture but using multiple locations and loc-src may end in 239 compatibility issues. [RFC6442] already addresses the issue of 240 multiple locations. To avoid problems with misinterpretation of the 241 "loc-src" parameter, the value may be removed when passed to another 242 domain. 244 8. IANA Considerations 246 8.1. Registration of loc-src parameter for Geolocation header field 248 The IANA is asked to add a new SIP header field parameter for the 249 Geolocation header field in the "Header Field Parameters and 250 Parameter Values" subregistry (created by [RFC3968]) of the "Session 251 Initiation Protocol (SIP) Parameters" registry found at 252 https://www.iana.org/assignments/sip-parameters/. 254 Header Field: Geolocation 256 Parameter Name: loc-src 258 Predefined Values: No 260 Reference: this RFC 262 9. Acknowledgements 264 The authors would like to thank Dale Worley, Christer Holmberg and 265 Jean Mahoney for their extensive review of the draft. The authors 266 would like to acknowledge the constructive feedback provided by Paul 267 Kyzivat and Robert Sparks. 269 10. References 271 10.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 279 Extensions to the Session Initiation Protocol (SIP) for 280 Asserted Identity within Trusted Networks", RFC 3325, 281 DOI 10.17487/RFC3325, November 2002, 282 . 284 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 285 (IANA) Header Field Parameter Registry for the Session 286 Initiation Protocol (SIP)", BCP 98, RFC 3968, 287 DOI 10.17487/RFC3968, December 2004, 288 . 290 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 291 Specifications: ABNF", STD 68, RFC 5234, 292 DOI 10.17487/RFC5234, January 2008, 293 . 295 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 296 for the Session Initiation Protocol", RFC 6442, 297 DOI 10.17487/RFC6442, December 2011, 298 . 300 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 301 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 302 May 2017, . 304 10.2. Informative References 306 [M493] European Telecommunications Standards Institute, 307 "Functional architecture to support European requirements 308 on emergency caller location determination and transport", 309 ES 203 178, V 1.1.1, Februar 2015. 311 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 312 Session Initiation Protocol (SIP) Messages", RFC 4483, 313 DOI 10.17487/RFC4483, May 2006, 314 . 316 [TS23-167] 317 3rd Generation Partnership Project, "3rd Generation 318 Partnership Project; Technical Specification Group 319 Services and System Aspects; IP Multimedia Subsystem (IMS) 320 emergency sessions", TS 23.167, V 12.1.0, March 2015. 322 Authors' Addresses 324 James Winterbottom 325 Winterb Consulting Services 326 Gwynneville, NSW 2500 327 AU 329 Phone: +61 448 266004 330 Email: a.james.winterbottom@gmail.com 332 Roland Jesske 333 Deutsche Telekom 334 Heinrich-Hertz Str, 3-7 335 Darmstadt 64295 336 Germany 338 Email: r.jesske@telekom.de 339 URI: www.telekom.de 341 Bruno Chatras 342 Orange Labs 343 44, avenue de la Republique 344 Chatillon F-92320 345 France 347 Email: bruno.chatras@orange.com 349 Andrew Hutton 350 Atos 351 Mid City Place 352 London WC1V 6EA 353 UK 355 Email: andrew.hutton@atos.net