idnits 2.17.1 draft-ietf-sipcore-locparam-02.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 (July 22, 2019) is 1737 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: January 23, 2020 B. Chatras 7 Orange Labs 8 A. Hutton 9 Atos 10 July 22, 2019 12 Location Source Parameter for the SIP Geolocation Header Field 13 draft-ietf-sipcore-locparam-02.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 January 23, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7 70 10.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 3. Rationale 114 The primary intent of the parameter defined in this specific is for 115 use in emergency calling. There are various architectures defined 116 for providing emergency calling using SIP-based messaging. Each has 117 it own characteristics with corresponding pros and cons. All of them 118 allow the UE to provide location information, however, many also 119 attach other sources of location information to support veracity 120 checks, provide backup information, or to be used as the primary 121 location. 123 This document makes no attempt to comment on these various 124 architectures or the rationale for them wishing to include multiple 125 location values. It does recognize that these architectures exist 126 and that there is a need to identify the entity adding the location 127 information. 129 The parameter defined in this specification adds the location source 130 generating the location value to increase the trustworthiness of the 131 location information. 133 The loc-src parameter is applicable within a single private 134 administrative domain or between different administrative domains 135 where there is a trust relationship between the domains. Thus it is 136 intended to use this parameter only in trust domains where Spec(T) as 137 described in [RFC3325] exists. 139 The loc-src parameter is not included in a SIP message sent to 140 another network if there is no trust relationship. The The loc-src 141 parameter is not applicable if the administrative domain manages 142 emergency calls in a way that does not require location source 143 generating the location. 145 The functional architecture described within ETSI [M493] is an 146 example of architecture where this parameter makes sense to be used. 148 4. Mechanism 150 The mechanism employed adds a parameter to the location value defined 151 in [RFC6442] that identifies the hostname of the entity adding the 152 location value to the geolocation header field. The Augmented BNF 153 (ABNF) [RFC5234] for this parameter is shown in Figure 1. 155 location-source = "loc-src=" (hostname ) 156 hostname = 158 Figure 1: Location Source 160 Only a fully qualified host name is valid, an IP address MUST NOT be 161 added by an entity conforming with this specification. If a node 162 conforming to this specification receives a geolocation header field 163 with a loc-src parameter containing an IP address then the parameter 164 MUST be removed. 166 Any proxy adding a location value to a geolocation header field 167 SHOULD also add its host name using the loc-src parameter so that it 168 is clearly identified as the node adding the location. A UE MUST NOT 169 provide a loc-src parameter value. If a proxy receives a message 170 from an untrusted source with the loc-src parameter set then it MUST 171 remove the loc-src parameter before passing the message into a 172 trusted network. 174 5. Example 176 The following example shows a SIP INVITE message containing a 177 geolocation header field with two location values. The first 178 location value points to a PIDF-LO in the SIP body using a content- 179 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 180 The second location value is an https URI the provided by a proxy 181 which identifies itself using the loc-src parameter. 183 INVITE sip:bob@biloxi.example.com SIP/2.0 184 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 185 Max-Forwards: 70 186 To: Bob 187 From: Alice ;tag=9fxced76sl 188 Call-ID: 3848276298220188511@atlanta.example.com 189 Geolocation: , 190 ; 191 loc-src=edgeproxy.example.com 192 Geolocation-Routing: yes 193 Accept: application/sdp, application/pidf+xml 194 CSeq: 31862 INVITE 195 Contact: 196 Content-Type: multipart/mixed; boundary=boundary1 197 Content-Length: ... 199 Figure 2: Example Location Request. 201 6. Privacy Considerations 203 This document doesn't change any of the privacy considerations 204 described in [RFC6442]. While the addition of the loc-src parameter 205 does provide an indicator of the entity that added the location in 206 the signaling path this provides little more exposure than a proxy 207 identity being added to the record-route header field. 209 7. Security Considerations 211 This document introduces the ability of a proxy or middle box to 212 insert a host name indicating the that they added the specific 213 location value to the geolocation header field. The intent is for 214 this field to be used by the location recipient in the event that the 215 SIP message contains multiple location values. As a consequence this 216 parameter should only be used by the location recipient in a trusted 217 network. 219 As already stated in [RFC6442] securing the location hop- by-hop, 220 using TLS, protects the message from eavesdropping and modification 221 in transit, but exposes the information to all proxies on the path as 222 well as the endpoint. The loc-src parameter is applicable within a 223 single private administrative domain or between different 224 administrative domains where there is a trust relationship between 225 the domains. If such trust domain is not given it is strongly 226 recommended to delete the location information. 228 The use of this parameter is not restricted to a specific 229 architecture but using multiples locations and loc-src may end in 230 compatibility issues. [RFC6442] already addresses the issue of 231 multiples locations. To avoid problems of wrong interpretation of 232 loc-src the value may be discarded when passed to an other domain. 234 8. IANA Considerations 236 8.1. Registration of loc-src Parameter for geolocation header field 238 This document calls for IANA to register a new SIP header parameter 239 as per the guidelines in [RFC3261], which will be added to header 240 sub-registry under http://www.iana.org/assignments/sip-parameters. 242 Header Field: geolocation 244 Parameter Name: loc-src 246 9. Acknowledgements 248 The authors would like to thank Dale Worley for his extensive review 249 of the draft The authors would like to acknowledge the constructive 250 feedback provided by Paul Kyziva and Christer Holmberg. 252 10. References 253 10.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 261 A., Peterson, J., Sparks, R., Handley, M., and E. 262 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 263 DOI 10.17487/RFC3261, June 2002, 264 . 266 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 267 Extensions to the Session Initiation Protocol (SIP) for 268 Asserted Identity within Trusted Networks", RFC 3325, 269 DOI 10.17487/RFC3325, November 2002, 270 . 272 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 273 Specifications: ABNF", STD 68, RFC 5234, 274 DOI 10.17487/RFC5234, January 2008, 275 . 277 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 278 for the Session Initiation Protocol", RFC 6442, 279 DOI 10.17487/RFC6442, December 2011, 280 . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 10.2. Informative References 288 [M493] European Telecommunications Standards Institute, 289 "Functional architecture to support European requirements 290 on emergency caller location determination and transport", 291 ES 203 178, V 1.1.1, Februar 2015. 293 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 294 Session Initiation Protocol (SIP) Messages", RFC 4483, 295 DOI 10.17487/RFC4483, May 2006, 296 . 298 [TS23-167] 299 3rd Generation Partnership Project, "3rd Generation 300 Partnership Project; Technical Specification Group 301 Services and System Aspects; IP Multimedia Subsystem (IMS) 302 emergency sessions", TS 23.167, V 12.1.0, March 2015. 304 Authors' Addresses 306 James Winterbottom 307 Winterb Consulting Services 308 Gwynneville, NSW 2500 309 AU 311 Phone: +61 448 266004 312 Email: a.james.winterbottom@gmail.com 314 Roland Jesske 315 Deutsche Telekom 316 Heinrich-Hertz Str, 3-7 317 Darmstadt 64295 318 Germany 320 Email: r.jesske@telekom.de 321 URI: www.telekom.de 323 Bruno Chatras 324 Orange Labs 325 38-40 rue du General Leclerc 326 Issy Moulineaux Cedex 9 F-92794 327 France 329 Email: bruno.chatras@orange.com 331 Andrew Hutton 332 Atos 333 Mid City Place 334 London WC1V 6EA 335 UK 337 Email: andrew.hutton@atos.net