idnits 2.17.1 draft-winterbottom-dispatch-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 (December 30, 2016) is 2673 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 Dispatch J. Winterbottom 3 Internet-Draft Winterb Consulting Services 4 Updates: RFC6442 (if approved) R. Roland 5 Intended status: Standards Track L. Liess 6 Expires: July 3, 2017 Deutsche Telekom 7 B. Chatras 8 Orange Labs 9 A. Hutton 10 Unify 11 December 30, 2016 13 Location Source Parameter for the SIP Geolocation Header Field 14 draft-winterbottom-dispatch-locparam-02.txt 16 Abstract 18 There are some circumstances where a geolocation header field may 19 contain more than one location value. Knowing the identity of the 20 node adding the location value allows the recipient more freedom in 21 selecting the value to look at first rather than relying solely on 22 the order of the location values. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 3, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Registration of loc-src Parameter for geolocation header 67 field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 10.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The SIP geolocation specification [RFC6442] describes a SIP header 77 field that is used to indicate that the SIP message is conveying 78 location information. The specification suggests that only one 79 location value should be conveyed. However, some communications 80 architectures, such as 3GPP [TS23-167] and ETSI [M493], prefer to use 81 information provided by edge-proxies or acquired through the use of 82 core-network nodes, before using information provided solely by user 83 equipment (UE). These solutions don't preclude the use of UE 84 provided location but require a means of being able to distinguish 85 the identity of the node adding the location value to the SIP message 86 from that provided by the UE. [RFC6442] stipulates that the order of 87 location values in the geolocation header field aligns with the order 88 in which they were added to the header field. Whilst this order 89 provides guidance to the recipient as to which values were added to 90 the message earlier in the communication chain, it does not provide 91 any indication of which node actually added the location value. 92 Knowing the identity of the entity that added the location to the 93 message allows the recipient to choose which location to consider 94 first rather than relying solely on the order of the location values 95 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. This document makes no attempt to comment on these various 120 architectures or the rationale for them wishing to include multiple 121 location values. It does recognize that these architectures exist 122 and that there is a need to identify the entity adding the location 123 information. 125 The parameter defined in this specification adds the location source 126 generating the location value to increase the trustworthiness of the 127 location information. Thus it is intended to use this parameter in 128 trust domains where Spec(T) as described in [RFC3325] exists only. 129 The functional architecture described within ETSI [M493] is an 130 example of architecture where this parameter makes sense to be used. 132 4. Mechanism 134 The mechanism employed adds a parameter to the location value defined 135 in [RFC6442] that identifies the hostname of the entity adding the 136 location value to the geolocation header field. The Augmented BNF 137 (ABNF) [RFC5234] for this parameter is shown in Figure 1. 139 location-source = "loc-src=" (host / other-loc-src) 140 other-loc-src = token 142 Figure 1: Location Source 144 Only a fully qualified host name is valid, an IP address MUST NOT be 145 added by an entity conforming with this specification. If a node 146 conforming to this specification receives a geolocation header field 147 with a loc-src parameter containing an IP address then the parameter 148 MUST be removed. 150 Any proxy adding a location value to a geolocation header field 151 SHOULD also add its host name using the loc-src parameter so that it 152 is clearly identified as the node adding the location. A UE MUST NOT 153 provide a loc-src parameter value. If a proxy receives a message 154 from an untrusted source with the loc-src parameter set then it MUST 155 remove the loc-src parameter before passing the message into a 156 trusted network. 158 5. Example 160 The following example shows a SIP INVITE message containing a 161 geolocation header field with two location values. The first 162 location value points to a PIDF-LO in the SIP body using a content- 163 indirection (cid:) URI per [RFC4483] and this is provided by the UE. 164 The second location value is an https URI the provided by a proxy 165 which identifies itself using the loc-src parameter. 167 INVITE sips:bob@biloxi.example.com SIP/2.0 168 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 169 Max-Forwards: 70 170 To: Bob 171 From: Alice ;tag=9fxced76sl 172 Call-ID: 3848276298220188511@atlanta.example.com 173 Geolocation: , 174 ; 175 loc-src=edgeproxy.example.com 176 Geolocation-Routing: yes 177 Accept: application/sdp, application/pidf+xml 178 CSeq: 31862 INVITE 179 Contact: 180 Content-Type: multipart/mixed; boundary=boundary1 181 Content-Length: ... 183 Figure 2: Example Location Request. 185 6. Privacy Considerations 187 This document doesn't change any of the privacy considerations 188 described in [RFC6442]. While the addition of the loc-src parameter 189 does provide an indicator of the entity that added the location in 190 the signaling path this provides little more exposure than a proxy 191 identity being added to the record-route header field. 193 7. Security Considerations 195 This document introduces the ability of a proxy or middle box to 196 insert a host name indicating the that they added the specific 197 location value to the geolocation header field. The intent is for 198 this field to be used by the location recipient in the event that the 199 SIP message contains multiple location values. As a consequence this 200 parameter should only be used by the location recipient in a trusted 201 network. 203 The use of this parameter is not restricted to a specific 204 architecture but using multiples locations and loc-src may end in 205 compatibility issues. [RFC6442] already addresses the issue of 206 multiples locations. To avoid problems of wrong interpretation of 207 loc-src the value may be discarded when passed to an other domain. 209 8. IANA Considerations 210 8.1. Registration of loc-src Parameter for geolocation header field 212 This document calls for IANA to register a new SIP header parameter 213 as per the guidelines in [RFC3261], which will be added to header 214 sub-registry under http://www.iana.org/assignments/sip-parameters. 216 Header Field: geolocation 218 Parameter Name: loc-src 220 9. Acknowledgements 222 NONE 224 10. References 226 10.1. Normative References 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, 230 DOI 10.17487/RFC2119, March 1997, 231 . 233 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 234 A., Peterson, J., Sparks, R., Handley, M., and E. 235 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 236 DOI 10.17487/RFC3261, June 2002, 237 . 239 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 240 Extensions to the Session Initiation Protocol (SIP) for 241 Asserted Identity within Trusted Networks", RFC 3325, 242 DOI 10.17487/RFC3325, November 2002, 243 . 245 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 246 Specifications: ABNF", STD 68, RFC 5234, 247 DOI 10.17487/RFC5234, January 2008, 248 . 250 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 251 for the Session Initiation Protocol", RFC 6442, 252 DOI 10.17487/RFC6442, December 2011, 253 . 255 10.2. Informative References 257 [M493] European Telecommunications Standards Institute, 258 "Functional architecture to support European requirements 259 on emergency caller location determination and transport", 260 ES 203 178, V 1.1.1, Februar 2015. 262 [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in 263 Session Initiation Protocol (SIP) Messages", RFC 4483, 264 DOI 10.17487/RFC4483, May 2006, 265 . 267 [TS23-167] 268 3rd Generation Partnership Project, "3rd Generation 269 Partnership Project; Technical Specification Group 270 Services and System Aspects; IP Multimedia Subsystem (IMS) 271 emergency sessions", TS 23.167, V 12.1.0, March 2015. 273 Authors' Addresses 275 James Winterbottom 276 Winterb Consulting Services 277 Gwynneville, NSW 2500 278 AU 280 Phone: +61 448 266004 281 Email: a.james.winterbottom@gmail.com 283 Roland Jesske 284 Deutsche Telekom 285 Heinrich-Hertz Str, 3-7 286 Darmstadt 64295 287 Germany 289 Email: r.jesske@telekom.de 290 URI: www.telekom.de 292 Laura Liess 293 Deutsche Telekom 294 Heinrich-Hertz Str, 3-7 295 Darmstadt 64295 296 Germany 298 Email: l.liess@gmail.com 299 Bruno Chatras 300 Orange Labs 301 38-40 rue du General Leclerc 302 Issy Moulineaux Cedex 9 F-92794 303 France 305 Email: bruno.chatras@orange.com 307 Andrew Hutton 308 Unify 309 Technology Drive 310 Nottingham NG9 1LA 311 UK 313 Email: andrew.hutton@unify.com