idnits 2.17.1 draft-ietf-sipcore-locparam-03.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 (September 16, 2019) is 1656 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: March 19, 2020 B. Chatras 7 Orange Labs 8 A. Hutton 9 Atos 10 September 16, 2019 12 Location Source Parameter for the SIP Geolocation Header Field 13 draft-ietf-sipcore-locparam-03.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. This document defines the 22 location-source parameter so that the entity adding the location 23 value to Geolocation header field can identify itself using its 24 hostname. 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 March 19, 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 location-source parameter for Geolocation 69 header field . . . . . . . . . . . . . . . . . . . . . . 6 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 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 location values to a SIP request 82 that already contains location value. [RFC6442] also states that if 83 a SIP intermediary adds location it is fully responsible for 84 addressing the concerns of any 424 (Bad Location Information) SIP 85 response it receives. However, some communications architectures, 86 such as 3GPP [TS23-167] and ETSI [M493], prefer to use information 87 provided by edge-proxies or acquired through the use of core-network 88 nodes, before using information provided solely by user equipment 89 (UE). These solutions don't preclude the use of UE provided location 90 but require a means of being able to distinguish the identity of the 91 node adding the location value to the SIP message from that provided 92 by the UE. 94 [RFC6442] stipulates that the order of location values 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 provide any indication of which 99 node actually added the location value. Knowing the identity of the 100 entity that added the location to the message allows the recipient to 101 choose which location to consider first rather than relying solely on 102 the order of the location values in the Geolocation header field. 104 This document extends the Geolocation header field, by allowing an 105 entity adding the location value to identity itself using a hostname. 106 This is done by defining a new geoloc-param header field parameter, 107 location-source."How the entity adding the location value 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 location-source parameter in this 122 specification is for use in emergency calling. There are various 123 architectures defined for providing emergency calling using SIP-based 124 messaging. Each has it own characteristics with corresponding pros 125 and cons. All of them allow the UE to provide location information, 126 however, many also attach other sources of location information to 127 support veracity checks, provide backup information, or to be used as 128 the primary location. 130 This document makes no attempt to comment on these various 131 architectures or the rationale for them wishing to include multiple 132 location values. It does recognize that these architectures exist 133 and that there is a need to identify the entity adding the location 134 information. 136 The location-source parameter adds the location source generating the 137 location value to increase the trustworthiness of the location 138 information. 140 The location-source 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 location-source parameter is not included in a SIP message sent 147 to another network if there is no trust relationship. The The 148 location-source parameter is not applicable if the administrative 149 domain manages emergency calls in a way that does not require any 150 generation of the location. 152 The functional architecture described within ETSI [M493] is an 153 example of architecture where this parameter makes sense to be used. 155 4. Mechanism 157 The mechanism employed adds a parameter to the location value defined 158 in [RFC6442] that identifies the hostname of the entity adding the 159 location value to the Geolocation header field. The Augmented BNF 160 (ABNF) [RFC5234] for this parameter is shown in Figure 1. 162 location-source = "loc-src" EQUAL hostname 163 hostname = 165 Figure 1: Location Source 167 Only a fully qualified host name is valid. The syntax does not 168 support IP addresses, and if an entity conforming to this 169 specification receives a Geolocation header field with a location- 170 source parameter containing an IP address then the parameter MUST be 171 removed. 173 A SIP intermediarity conformant to this specification adding a 174 location value to a Geolocation header field SHOULD also add a 175 location-source header field parameter so that it is clearly 176 identified as the node adding the location. A UA MUST NOT insert a 177 location-source header field parameter. If a SIP intermediarity 178 receives a message from an untrusted source with the location-source 179 parameter set then it MUST remove the location-source parameter 180 before passing the message into a trusted network. 182 5. Example 184 The following example shows a SIP INVITE message containing a 185 Geolocation header field with two location values. The first 186 location value points to a PIDF-LO in the SIP body using a content- 187 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 188 The second location value is an https URI the provided by a SIP 189 intermediarity which identifies itself using the location-source 190 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. 210 6. Privacy Considerations 212 This document doesn't change any of the privacy considerations 213 described in [RFC6442]. While the addition of the location-source 214 parameter does provide an indicator of the entity that added the 215 location in the signaling path this provides little more exposure 216 than a proxy identity being added to the record-route header field. 218 7. Security Considerations 220 This document introduces the ability of a SIP intermediarity to 221 insert a host name indicating that they added the specific location 222 value to the Geolocation header field. The intent is for this field 223 to be used by the location recipient in the event that the SIP 224 message contains multiple location values. As a consequence this 225 parameter should only be used by the location recipient in a trusted 226 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 location-source 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 multiples locations and loc-src may end in 239 compatibility issues. [RFC6442] already addresses the issue of 240 multiples locations. To avoid problems of wrong interpretation of 241 loc-src the value may be removed when passed to an other domain. 243 8. IANA Considerations 245 8.1. Registration of location-source parameter for Geolocation header 246 field 248 This document calls for IANA to register a new SIP header parameter 249 as per the guidelines in [RFC3261], which will be added to header 250 sub-registry under http://www.iana.org/assignments/sip-parameters. 252 Header Field: Geolocation 254 Parameter Name: loc-src 256 9. Acknowledgements 258 The authors would like to thank Dale Worley and Christer Holmberg for 259 their extensive review of the draft The authors would like to 260 acknowledge the constructive feedback provided by Paul Kyzivat and 261 Robert Sparks. 263 10. References 265 10.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, 270 . 272 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 273 A., Peterson, J., Sparks, R., Handley, M., and E. 274 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 275 DOI 10.17487/RFC3261, June 2002, 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 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 285 Specifications: ABNF", STD 68, RFC 5234, 286 DOI 10.17487/RFC5234, January 2008, 287 . 289 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 290 for the Session Initiation Protocol", RFC 6442, 291 DOI 10.17487/RFC6442, December 2011, 292 . 294 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 295 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 296 May 2017, . 298 10.2. Informative References 300 [M493] European Telecommunications Standards Institute, 301 "Functional architecture to support European requirements 302 on emergency caller location determination and transport", 303 ES 203 178, V 1.1.1, Februar 2015. 305 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 306 Session Initiation Protocol (SIP) Messages", RFC 4483, 307 DOI 10.17487/RFC4483, May 2006, 308 . 310 [TS23-167] 311 3rd Generation Partnership Project, "3rd Generation 312 Partnership Project; Technical Specification Group 313 Services and System Aspects; IP Multimedia Subsystem (IMS) 314 emergency sessions", TS 23.167, V 12.1.0, March 2015. 316 Authors' Addresses 318 James Winterbottom 319 Winterb Consulting Services 320 Gwynneville, NSW 2500 321 AU 323 Phone: +61 448 266004 324 Email: a.james.winterbottom@gmail.com 326 Roland Jesske 327 Deutsche Telekom 328 Heinrich-Hertz Str, 3-7 329 Darmstadt 64295 330 Germany 332 Email: r.jesske@telekom.de 333 URI: www.telekom.de 335 Bruno Chatras 336 Orange Labs 337 38-40 rue du General Leclerc 338 Issy Moulineaux Cedex 9 F-92794 339 France 341 Email: bruno.chatras@orange.com 343 Andrew Hutton 344 Atos 345 Mid City Place 346 London WC1V 6EA 347 UK 349 Email: andrew.hutton@atos.net