idnits 2.17.1 draft-winterbottom-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 (October 18, 2017) is 2379 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: April 21, 2018 B. Chatras 7 Orange Labs 8 A. Hutton 9 Unify 10 October 18, 2017 12 Location Source Parameter for the SIP Geolocation Header Field 13 draft-winterbottom-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 April 21, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 / other-loc-src) 154 hostname = 155 other-loc-src = token 157 Figure 1: Location Source 159 Only a fully qualified host name is valid, an IP address MUST NOT be 160 added by an entity conforming with this specification. If a node 161 conforming to this specification receives a geolocation header field 162 with a loc-src parameter containing an IP address then the parameter 163 MUST be removed. 165 Any proxy adding a location value to a geolocation header field 166 SHOULD also add its host name using the loc-src parameter so that it 167 is clearly identified as the node adding the location. A UE MUST NOT 168 provide a loc-src parameter value. If a proxy receives a message 169 from an untrusted source with the loc-src parameter set then it MUST 170 remove the loc-src parameter before passing the message into a 171 trusted network. 173 5. Example 175 The following example shows a SIP INVITE message containing a 176 geolocation header field with two location values. The first 177 location value points to a PIDF-LO in the SIP body using a content- 178 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 179 The second location value is an https URI the provided by a proxy 180 which identifies itself using the loc-src parameter. 182 INVITE sips:bob@biloxi.example.com SIP/2.0 183 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 184 Max-Forwards: 70 185 To: Bob 186 From: Alice ;tag=9fxced76sl 187 Call-ID: 3848276298220188511@atlanta.example.com 188 Geolocation: , 189 ; 190 loc-src=edgeproxy.example.com 191 Geolocation-Routing: yes 192 Accept: application/sdp, application/pidf+xml 193 CSeq: 31862 INVITE 194 Contact: 195 Content-Type: multipart/mixed; boundary=boundary1 196 Content-Length: ... 198 Figure 2: Example Location Request. 200 6. Privacy Considerations 202 This document doesn't change any of the privacy considerations 203 described in [RFC6442]. While the addition of the loc-src parameter 204 does provide an indicator of the entity that added the location in 205 the signaling path this provides little more exposure than a proxy 206 identity being added to the record-route header field. 208 7. Security Considerations 210 This document introduces the ability of a proxy or middle box to 211 insert a host name indicating the that they added the specific 212 location value to the geolocation header field. The intent is for 213 this field to be used by the location recipient in the event that the 214 SIP message contains multiple location values. As a consequence this 215 parameter should only be used by the location recipient in a trusted 216 network. 218 The use of this parameter is not restricted to a specific 219 architecture but using multiples locations and loc-src may end in 220 compatibility issues. [RFC6442] already addresses the issue of 221 multiples locations. To avoid problems of wrong interpretation of 222 loc-src the value may be discarded when passed to an other domain. 224 8. IANA Considerations 226 8.1. Registration of loc-src Parameter for geolocation header field 228 This document calls for IANA to register a new SIP header parameter 229 as per the guidelines in [RFC3261], which will be added to header 230 sub-registry under http://www.iana.org/assignments/sip-parameters. 232 Header Field: geolocation 234 Parameter Name: loc-src 236 9. Acknowledgements 238 The authors would like to thank Dale Worley for his extensive review 239 of the draft The authors would like to acknowledge the constructive 240 feedback provided by Paul Kyziva and Christer Holmberg. 242 10. References 244 10.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 252 A., Peterson, J., Sparks, R., Handley, M., and E. 253 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 254 DOI 10.17487/RFC3261, June 2002, 255 . 257 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 258 Extensions to the Session Initiation Protocol (SIP) for 259 Asserted Identity within Trusted Networks", RFC 3325, 260 DOI 10.17487/RFC3325, November 2002, 261 . 263 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 264 Specifications: ABNF", STD 68, RFC 5234, 265 DOI 10.17487/RFC5234, January 2008, 266 . 268 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 269 for the Session Initiation Protocol", RFC 6442, 270 DOI 10.17487/RFC6442, December 2011, 271 . 273 10.2. Informative References 275 [M493] European Telecommunications Standards Institute, 276 "Functional architecture to support European requirements 277 on emergency caller location determination and transport", 278 ES 203 178, V 1.1.1, Februar 2015. 280 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 281 Session Initiation Protocol (SIP) Messages", RFC 4483, 282 DOI 10.17487/RFC4483, May 2006, 283 . 285 [TS23-167] 286 3rd Generation Partnership Project, "3rd Generation 287 Partnership Project; Technical Specification Group 288 Services and System Aspects; IP Multimedia Subsystem (IMS) 289 emergency sessions", TS 23.167, V 12.1.0, March 2015. 291 Authors' Addresses 293 James Winterbottom 294 Winterb Consulting Services 295 Gwynneville, NSW 2500 296 AU 298 Phone: +61 448 266004 299 Email: a.james.winterbottom@gmail.com 300 Roland Jesske 301 Deutsche Telekom 302 Heinrich-Hertz Str, 3-7 303 Darmstadt 64295 304 Germany 306 Email: r.jesske@telekom.de 307 URI: www.telekom.de 309 Bruno Chatras 310 Orange Labs 311 38-40 rue du General Leclerc 312 Issy Moulineaux Cedex 9 F-92794 313 France 315 Email: bruno.chatras@orange.com 317 Andrew Hutton 318 Unify 319 Technology Drive 320 Nottingham NG9 1LA 321 UK 323 Email: andrew.hutton@unify.com