idnits 2.17.1 draft-winterbottom-sipcore-locparam-00.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 (February 15, 2017) is 2619 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: August 19, 2017 B. Chatras 7 Orange Labs 8 A. Hutton 9 Unify 10 February 15, 2017 12 Location Source Parameter for the SIP Geolocation Header Field 13 draft-winterbottom-sipcore-locparam-00.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 http://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 August 19, 2017. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 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 a SIP header 76 field that is used to indicate that the SIP message is conveying 77 location information. The specification suggests that only one 78 location value should be conveyed. However, some communications 79 architectures, such as 3GPP [TS23-167] and ETSI [M493], prefer to use 80 information provided by edge-proxies or acquired through the use of 81 core-network nodes, before using information provided solely by user 82 equipment (UE). These solutions don't preclude the use of UE 83 provided location but require a means of being able to distinguish 84 the identity of the node adding the location value to the SIP message 85 from that provided by the UE. [RFC6442] stipulates that the order of 86 location values in the geolocation header field aligns with the order 87 in which they were added to the header field. Whilst this order 88 provides guidance to the recipient as to which values were added to 89 the message earlier in the communication chain, it does not provide 90 any indication of which node actually added the location value. 91 Knowing the identity of the entity that added the location to the 92 message allows the recipient to choose which location to consider 93 first rather than relying solely on the order of the location values 94 in the geolocation header field. 96 This document adds a location-source (loc-src) parameter to the 97 location values in [RFC6442] so that the entity adding the location 98 value to geolocation header field can identify itself using its 99 hostname. How the entity adding the location value to the header 100 field obtains the location information is out of scope of this 101 document. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Rationale 111 The primary intent of the parameter defined in this specific is for 112 use in emergency calling. There are various architectures defined 113 for providing emergency calling using SIP-based messaging. Each has 114 it own characteristics with corresponding pros and cons. All of them 115 allow the UE to provide location information, however, many also 116 attach other sources of location information to support veracity 117 checks, provide backup information, or to be used as the primary 118 location. This document makes no attempt to comment on these various 119 architectures or the rationale for them wishing to include multiple 120 location values. It does recognize that these architectures exist 121 and that there is a need to identify the entity adding the location 122 information. 124 The parameter defined in this specification adds the location source 125 generating the location value to increase the trustworthiness of the 126 location information. Thus it is intended to use this parameter in 127 trust domains where Spec(T) as described in [RFC3325] exists only. 128 The functional architecture described within ETSI [M493] is an 129 example of architecture where this parameter makes sense to be used. 131 4. Mechanism 133 The mechanism employed adds a parameter to the location value defined 134 in [RFC6442] that identifies the hostname of the entity adding the 135 location value to the geolocation header field. The Augmented BNF 136 (ABNF) [RFC5234] for this parameter is shown in Figure 1. 138 location-source = "loc-src=" (host / other-loc-src) 139 other-loc-src = token 141 Figure 1: Location Source 143 Only a fully qualified host name is valid, an IP address MUST NOT be 144 added by an entity conforming with this specification. If a node 145 conforming to this specification receives a geolocation header field 146 with a loc-src parameter containing an IP address then the parameter 147 MUST be removed. 149 Any proxy adding a location value to a geolocation header field 150 SHOULD also add its host name using the loc-src parameter so that it 151 is clearly identified as the node adding the location. A UE MUST NOT 152 provide a loc-src parameter value. If a proxy receives a message 153 from an untrusted source with the loc-src parameter set then it MUST 154 remove the loc-src parameter before passing the message into a 155 trusted network. 157 5. Example 159 The following example shows a SIP INVITE message containing a 160 geolocation header field with two location values. The first 161 location value points to a PIDF-LO in the SIP body using a content- 162 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 163 The second location value is an https URI the provided by a proxy 164 which identifies itself using the loc-src parameter. 166 INVITE sips:bob@biloxi.example.com SIP/2.0 167 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 168 Max-Forwards: 70 169 To: Bob 170 From: Alice ;tag=9fxced76sl 171 Call-ID: 3848276298220188511@atlanta.example.com 172 Geolocation: , 173 ; 174 loc-src=edgeproxy.example.com 175 Geolocation-Routing: yes 176 Accept: application/sdp, application/pidf+xml 177 CSeq: 31862 INVITE 178 Contact: 179 Content-Type: multipart/mixed; boundary=boundary1 180 Content-Length: ... 182 Figure 2: Example Location Request. 184 6. Privacy Considerations 186 This document doesn't change any of the privacy considerations 187 described in [RFC6442]. While the addition of the loc-src parameter 188 does provide an indicator of the entity that added the location in 189 the signaling path this provides little more exposure than a proxy 190 identity being added to the record-route header field. 192 7. Security Considerations 194 This document introduces the ability of a proxy or middle box to 195 insert a host name indicating the that they added the specific 196 location value to the geolocation header field. The intent is for 197 this field to be used by the location recipient in the event that the 198 SIP message contains multiple location values. As a consequence this 199 parameter should only be used by the location recipient in a trusted 200 network. 202 The use of this parameter is not restricted to a specific 203 architecture but using multiples locations and loc-src may end in 204 compatibility issues. [RFC6442] already addresses the issue of 205 multiples locations. To avoid problems of wrong interpretation of 206 loc-src the value may be discarded when passed to an other domain. 208 8. IANA Considerations 209 8.1. Registration of loc-src Parameter for geolocation header field 211 This document calls for IANA to register a new SIP header parameter 212 as per the guidelines in [RFC3261], which will be added to header 213 sub-registry under http://www.iana.org/assignments/sip-parameters. 215 Header Field: geolocation 217 Parameter Name: loc-src 219 9. Acknowledgements 221 NONE 223 10. References 225 10.1. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, 229 DOI 10.17487/RFC2119, March 1997, 230 . 232 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 233 A., Peterson, J., Sparks, R., Handley, M., and E. 234 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 235 DOI 10.17487/RFC3261, June 2002, 236 . 238 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 239 Extensions to the Session Initiation Protocol (SIP) for 240 Asserted Identity within Trusted Networks", RFC 3325, 241 DOI 10.17487/RFC3325, November 2002, 242 . 244 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 245 Specifications: ABNF", STD 68, RFC 5234, 246 DOI 10.17487/RFC5234, January 2008, 247 . 249 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 250 for the Session Initiation Protocol", RFC 6442, 251 DOI 10.17487/RFC6442, December 2011, 252 . 254 10.2. Informative References 256 [M493] European Telecommunications Standards Institute, 257 "Functional architecture to support European requirements 258 on emergency caller location determination and transport", 259 ES 203 178, V 1.1.1, Februar 2015. 261 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 262 Session Initiation Protocol (SIP) Messages", RFC 4483, 263 DOI 10.17487/RFC4483, May 2006, 264 . 266 [TS23-167] 267 3rd Generation Partnership Project, "3rd Generation 268 Partnership Project; Technical Specification Group 269 Services and System Aspects; IP Multimedia Subsystem (IMS) 270 emergency sessions", TS 23.167, V 12.1.0, March 2015. 272 Authors' Addresses 274 James Winterbottom 275 Winterb Consulting Services 276 Gwynneville, NSW 2500 277 AU 279 Phone: +61 448 266004 280 Email: a.james.winterbottom@gmail.com 282 Roland Jesske 283 Deutsche Telekom 284 Heinrich-Hertz Str, 3-7 285 Darmstadt 64295 286 Germany 288 Email: r.jesske@telekom.de 289 URI: www.telekom.de 291 Bruno Chatras 292 Orange Labs 293 38-40 rue du General Leclerc 294 Issy Moulineaux Cedex 9 F-92794 295 France 297 Email: bruno.chatras@orange.com 298 Andrew Hutton 299 Unify 300 Technology Drive 301 Nottingham NG9 1LA 302 UK 304 Email: andrew.hutton@unify.com