idnits 2.17.1 draft-ietf-sipcore-locparam-06.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 (February 14, 2020) is 1533 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: August 17, 2020 B. Chatras 7 Orange Labs 8 A. Hutton 9 Atos 10 February 14, 2020 12 Location Source Parameter for the SIP Geolocation Header Field 13 draft-ietf-sipcore-locparam-06 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 August 17, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 8 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 identify 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. Please note that the "loc-src" parameter field does not 110 alter the subject of the locationValue. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. Rationale 122 The primary intent of the "loc-src" parameter in this specification 123 is for use in emergency calling. There are various architectures 124 defined for providing emergency calling using SIP-based messaging. 125 Each has its 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 to support emergency caller location 153 described within ETSI [M493] is an example of an architecture where 154 it makes sense to use this 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, it MUST remove the parameter. 174 A SIP intermediary conformant to this specification adding a 175 locationValue to a Geolocation header field SHOULD also add a "loc- 176 src" header field parameter so that it is clearly identified as the 177 node adding the location. A User Agent (UA) MUST NOT insert a "loc- 178 src" header field parameter. If a SIP intermediary receives a 179 message from an untrusted source with the "loc-src" parameter set 180 then it MUST remove the "loc-src" parameter before passing the 181 message into a trusted network. 183 5. Example 185 The following example shows a SIP INVITE message containing a 186 Geolocation header field with two locationValues. The first 187 locationValue points to a PIDF-LO in the SIP body using a content- 188 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 189 The second locationValue is an https URI provided by a SIP 190 intermediary which identifies itself using the "loc-src" parameter. 192 INVITE sip:bob@biloxi.example.com SIP/2.0 193 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 194 Max-Forwards: 70 195 To: Bob 196 From: Alice ;tag=9fxced76sl 197 Call-ID: 3848276298220188511@atlanta.example.com 198 Geolocation: , 199 ; 200 loc-src=edgeproxy.example.com 201 Geolocation-Routing: yes 202 Accept: application/sdp, application/pidf+xml 203 CSeq: 31862 INVITE 204 Contact: 205 Content-Type: multipart/mixed; boundary=boundary1 206 Content-Length: ... 208 Figure 2: Example Location Request (in trust domain) 210 6. Privacy Considerations 212 This document doesn't change any of the privacy considerations 213 described in [RFC6442]. While the addition of the "loc-src" 214 parameter identifies the entity that added the location in the 215 signaling path, this addition provides little more exposure than 216 adding a proxy identity to the Record-Route header field (privacy 217 defined in [RFC3323]). 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. 227 Adding this parameter in an untrusted network serves solely to give 228 location information to untrusted parties, and is NOT RECOMMENDED. 230 As already stated in [RFC6442], securing the location hop-by-hop, 231 using TLS, protects the message from eavesdropping and modification 232 in transit, but exposes the information to all SIP intermediaries on 233 the path as well as the endpoint. The "loc-src" parameter is 234 applicable within a single private administrative domain or between 235 different administrative domains where there is a relationship 236 between the domains. If such trust relationship is not given, it is 237 strongly recommended to delete the location information. 239 The use of this parameter is not restricted to a specific 240 architecture but using multiple locations and loc-src may end in 241 compatibility issues. [RFC6442] already addresses the issue of 242 multiple locations. To avoid problems of a possible corruption of 243 the location information including the "loc-src" parameter when using 244 a untrusted relationship, it is strongly recommended to delete 245 location information when passed to another domain out of the trust 246 domain. 248 8. IANA Considerations 250 8.1. Registration of loc-src parameter for Geolocation header field 252 The IANA is asked to add a new SIP header field parameter for the 253 Geolocation header field in the "Header Field Parameters and 254 Parameter Values" subregistry (created by [RFC3968]) of the "Session 255 Initiation Protocol (SIP) Parameters" registry found at 256 https://www.iana.org/assignments/sip-parameters/. 258 Header Field: Geolocation 260 Parameter Name: loc-src 262 Predefined Values: No 264 Reference: this RFC 266 9. Acknowledgements 268 The authors would like to thank Dale Worley, Christer Holmberg and 269 Jean Mahoney for their extensive review of the draft. The authors 270 would like to acknowledge the constructive feedback provided by Paul 271 Kyzivat and Robert Sparks. 273 10. References 275 10.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 283 Initiation Protocol (SIP)", RFC 3323, 284 DOI 10.17487/RFC3323, November 2002, 285 . 287 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 288 Extensions to the Session Initiation Protocol (SIP) for 289 Asserted Identity within Trusted Networks", RFC 3325, 290 DOI 10.17487/RFC3325, November 2002, 291 . 293 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 294 (IANA) Header Field Parameter Registry for the Session 295 Initiation Protocol (SIP)", BCP 98, RFC 3968, 296 DOI 10.17487/RFC3968, December 2004, 297 . 299 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 300 Specifications: ABNF", STD 68, RFC 5234, 301 DOI 10.17487/RFC5234, January 2008, 302 . 304 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 305 for the Session Initiation Protocol", RFC 6442, 306 DOI 10.17487/RFC6442, December 2011, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 10.2. Informative References 315 [M493] European Telecommunications Standards Institute, 316 "Functional architecture to support European requirements 317 on emergency caller location determination and transport", 318 ES 203 178, V 1.1.1, February 2015. 320 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 321 Session Initiation Protocol (SIP) Messages", RFC 4483, 322 DOI 10.17487/RFC4483, May 2006, 323 . 325 [TS23-167] 326 3rd Generation Partnership Project, "3rd Generation 327 Partnership Project; Technical Specification Group 328 Services and System Aspects; IP Multimedia Subsystem (IMS) 329 emergency sessions", TS 23.167, V 12.1.0, March 2015. 331 Authors' Addresses 333 James Winterbottom 334 Winterb Consulting Services 335 Gwynneville, NSW 2500 336 AU 338 Phone: +61 448 266004 339 Email: a.james.winterbottom@gmail.com 341 Roland Jesske 342 Deutsche Telekom 343 Heinrich-Hertz Str, 3-7 344 Darmstadt 64295 345 Germany 347 Email: r.jesske@telekom.de 348 URI: www.telekom.de 349 Bruno Chatras 350 Orange Labs 351 44, avenue de la Republique 352 Chatillon F-92320 353 France 355 Email: bruno.chatras@orange.com 357 Andrew Hutton 358 Atos 359 Mid City Place 360 London WC1V 6EA 361 UK 363 Email: andrew.hutton@atos.net