idnits 2.17.1 draft-ietf-sipping-location-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 3) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: E-7 The UA MUST not provide the (overwritten?) location information provided by a VPN (in lieu of the LI from the local network). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 414, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 417, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-02) exists of draft-ietf-sipping-session-policy-req-00 -- Possible downref: Normative reference to a draft: ref. '8' Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force James M. Polk 3 Internet Draft Cisco Systems 4 Expiration: Aug 9th, 2004 Brian Rosen 5 File: draft-ietf-sipping-location-requirements-00.txt Marconi 7 Requirements for 8 Session Initiation Protocol Location Conveyance 10 February 9th, 2003 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed 32 at http://www.ietf.org/shadow.html. 34 Abstract 36 This document presents the framework and requirements for an 37 extension to the Session Initiation Protocol (SIP) [1] for 38 conveyance of user location information from a Session Initiation 39 Protocol (SIP) user agent to another SIP entity. We consider cases 40 where location information is conveyed from end to end, as well as 41 cases where message routing by intermediaries is influenced by the 42 location of the session initiator. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 47 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.2 Changes from Individual Submission Versions . . . . . . . 3 49 2. In the Body or in a Header . . . . . . . . . . . . . . . . . 4 50 3. Scope of Location in a Message Body . . . . . . . . . . . . . 5 51 4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 5 52 5. Requirements for UA-to-Proxy Server Location Conveyance . . . 5 53 6. Additional Requirements for Emergency Calls . . . . . . . . . 6 54 7. Current Known Open issues . . . . . . . . . . . . . . . . . . 8 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 57 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 58 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 12. Author Information . . . . . . . . . . . . . . . . . . . . . 9 61 1. Introduction 63 This document presents the framework and requirements for an 64 extension to the Session Initiation Protocol (SIP) [1] for 65 conveyance of user location information object described by [7] from 66 a SIP User Agent to another SIP entity. 68 There are several situations in which it is appropriate for SIP to 69 be used to convey Location Information (LI) from one SIP entity to 70 another. This document specifies requirements when a SIP UAC knows 71 its location by some means not specified herein, and needs to inform 72 another SIP entity. One example is to reach your nearest pizza 73 parlor. A chain of pizza parlors may have a single well known uri 74 (sip:pizzaparlor.com), that is forwarded to the closest franchise by 75 the pizzaparlor.com proxy server. The receiving franchise UAS uses 76 the location information of the UAC to schedule your delivery. 78 Another important example is emergency calling. A call to 79 sip:sos@example.com is an emergency call as in [3]. The example.com 80 proxy server must route the call to the correct emergency response 81 center (ERC) determined by the location of the caller. At the ERC, 82 the UAS must determine the correct police/fire/ambulance/... 83 service, which is also based on your location. In many 84 jurisdictions, accurate location information of the caller in 85 distress is a required component of a call to an emergency center. 87 A third example is a direction service, which might give you verbal 88 directions to a venue from your present position. This is a case 89 where only the destination UAS needs to receive the location 90 information. 92 This document does not discuss how the UAC discovers or is 93 configured with its location (either coordinate or civil based). It 94 also does not discuss the contents of the Location Object (LO). It 95 does specify the requirements for the "using protocol" in [7]. 97 1.1 Conventions used in this document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 100 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described 102 in [2]. 104 1.2 Changes from Individual Submission Versions 106 This is a list of the changes that have been made from the -00 107 individual submission version of this ID: 109 - Brian Rosen was brought on as a co-author 111 - Requirements that a location header were negatively received in 112 the previous version of this document. AD and chair advice was to 113 move all location information into a message body (and stay away 114 from headers) 116 - Added a section of "emergency call" specific requirements 118 - Added an Open Issues section to mention what hasn't been resolved 119 yet in this effort 121 This is a list of the changes that have been made from the 122 individual submission version -01 124 - Added the IPR Statement section 126 - Adjusted a few requirements based on suggestions from the 127 Minneapolis meeting 129 - Added requirements that the UAC is to include from where it 130 learned its location in any transmission of its LI 132 - Distinguished the facts (known to date) that certain jurisdictions 133 relieve persons of their right to privacy when they call an ERC, 134 while other jurisdictions maintain a person's right to privacy, 135 while still others maintain a person's right to privacy - but only 136 if they ask that their service be set up that way. 138 - Made the decision that TLS is the security mechanism for location 139 conveyance in emergency communications (vs. S/MIME, which is still 140 the mechanism for UA-to-UA non-emergency location conveyance 141 cases). 143 - Added the Open Issue of whether a Proxy can insert location 144 information into an emergency SIP INVITE message, and some of the 145 open questions surrounding the implications of that action 147 - added a few names to the acknowledgements section 149 2. In the Body or in a Header 151 When one user agent wants to inform another user agent where they 152 are, it seems reasonable to have this accomplished by placing the 153 location information (coordinate or civil) in an S/MIME registered 154 and encoded message body, and sending it as part of a SIP request or 155 response. No routing of the request based on the location 156 information is required in this case; therefore no SIP Proxies 157 between these two UAs need to view the location information 158 contained in the SIP messages. 160 Although SIP [1} does not permit a proxy server to modify or delete 161 a body, there is no restriction on viewing bodies. However, S/MIME 162 protection implemented on bodies is only specified between UAS and 163 UAC, and if engaged, would render the location object opaque to a 164 proxy server for any desired modification if it is not correct or 165 precise enough from that proxy's point of view (were it to be able 166 to view it). This problem is similar to that raised in Session 167 Policy [8], where an intermediary may need information in a body, 168 such as IP address of media streams or codec choices to route a call 169 properly. Requirements in [8] are applicable to routing based on 170 location, and are incorporated in these requirements by reference. 172 It is conceivable to create a new header for location information. 173 However, [7] prefers S/MIME for security of Location Information, 174 and indeed S/MIME is preferable in SIP for protecting one part of a 175 message. Accordingly, these requirements specify location be 176 carried in a body. 178 It is the use of S/MIME however, that limits routing based on 179 location. Therefore, it seems appropriate to require that, where 180 routing is dependent on location, protection of the location 181 information object be accomplished by other mechanisms: here TLS 182 ("sips:" from [1]). It is envisioned that S/MIME SHOULD be used 183 when location information is not required by proxy servers, and TLS 184 MUST be used when it is. The UAC will need to know the difference 185 in the call's intent as to which security mechanism to engage for LI 186 conveyance. 188 This document does not address the behavior or configuration of SIP 189 Proxy Servers in these cases in order to accomplish location- 190 sensitive routing. That is out of scope, and left for further 191 (complementary) efforts. 193 3. Scope of Location in a Message Body 195 As concluded from the previous section, location information is to 196 be contained within a message body. If either another body (SDP for 197 example) is also to be sent in the message, or the LI is to be 198 protected with S/MIME, the rules stated in section 7 of [1] 199 regarding multipart MIME bodies MUST be followed. The format and 200 privacy/security rules of the location information SHOULD be defined 201 within the Geopriv WG. 203 4. Requirements for UA-to-UA Location Conveyance 205 The following are the requirements for UA-to-UA Location Conveyance 206 Situations where routing is not based on the LI of either UA: 208 U-U1 - MUST work with dialog-initiating SIP Requests and responses, 209 as well as the SIP MESSAGE method[4], and SHOULD work with 210 most SIP messages. 212 U-U2 - UAC Location information SHOULD remain confidential in route 213 to the destination UA. 215 U-U3 - The privacy and security rules established within the 216 Geopriv Working Group that would categorize SIP as a 'using 217 protocol' MUST be met [7]. 219 U-U4 - The UAC SHOULD indicate in the SIP message that includes 220 location information where the LI came from (IANA registered 221 codes for GPS, Cell Tower Triangulation, WiFi, DHCP, manual 222 entry - as examples). 224 5. Requirements for UA-to-Proxy Server Location Conveyance 226 The following are the requirements for UA-to-Proxy Server Location 227 Conveyance situations: 229 U-PS1 - MUST work with dialog-initiating SIP Requests and 230 responses, as well as the SIP MESSAGE method[4], and SHOULD 231 work with most SIP messages. 233 U-PS2 - UAC location information SHOULD remain confidential with 234 respect to entities to which the location information is 235 not addressed, but MUST be useable by intermediary proxy 236 servers. 238 U-PS3 - The privacy and security rules established within the 239 Geopriv Working Group which would categorize SIP as a 240 'using protocol' MUST be met [7]. 242 U-PS4 - Modification or removal of the LO by proxy servers MUST NOT 243 be required (as [1] currently forbids this). 245 U-PS5 - any mechanism used to prevent unwanted observation of this 246 Location Information CANNOT fail the SIP Request if not 247 understood by intermediary SIP entities or the destination 248 UAS. 250 U-PS6 - Proxy Servers that do not or cannot understand the Location 251 Information in the message body for routing purposes MUST 252 NOT fail the SIP Request. 254 U-PS7 � It MUST be possible for a proxy server to assert the 255 validity of the location information provided by the UA. 256 Alternatively, it is acceptable for there to be a mechanism 257 for a proxy server to assert a location object itself. 259 U-PS8 - The UAC SHOULD indicate in the SIP message that includes 260 location information where the LI came from (IANA 261 registered codes for GPS, Cell Tower Triangulation, WiFi, 262 DHCP, manual entry - as examples). 264 6. Additional Requirements for Emergency Calls 266 Emergency calls have requirements that are not generally important 267 to other uses for location in SIP: 269 Emergency calls presently have between 2 and 8-second call setup 270 times. There is ample evidence that the longer call setup end of 271 the range causes an unacceptable number of callers to abandon the 272 call before it is completed. Two-second call completion time is a 273 goal of many existing emergency call centers. Allocating 25% of the 274 call set up for processing privacy concerns seems reasonable; 1 275 second would be 50% of the goal, which seems unacceptable; less than 276 0.5 second seems unachievable, therefore: 278 E-1 - Privacy mechanisms MUST add no more than 0.5 second of call 279 setup time when implemented in present technology UAs and 280 Proxy Servers. 282 It may be acceptable for full privacy mechanisms related to the 283 location of the UAC (and it's user) to be tried on an initial 284 attempt to place a call, as long as the call attempt may be retried 285 without the mechanism if the first attempt fails. Abandoning 286 privacy in cases of failure of the privacy mechanism might be 287 subject to user preference, although such a feature would be within 288 the domain of a UA implementation and thus not subject to 289 standardization. It should be noted that some jurisdictions have 290 laws that explicitly deny any expectation of location privacy when 291 making an emergency call, while others grant the user the ability to 292 remain anonymous even when calling an ERC. So far, this has been 293 offered in some jurisdictions, but the user within that jurisdiction 294 must state this preference, as it is not the default configuration. 296 E-2 � Privacy mechanisms MUST NOT be mandatory for successful 297 conveyance of location during an (sos-type) emergency call. 299 E-3 - It MUST be possible to provide a privacy mechanism (that does 300 not violate the other requirements within this document) to a 301 user within a jurisdiction that gives that user the right to 302 choose not to reveal their location even when contacting an 303 ERC. 305 E-4 � The retention and retransmission policy of the ERC MUST be 306 able to be made available to the user, and override the 307 user's normal policy when local regulation governs such 308 retention and retransmission (but does not violate 309 requirement E-3). As in E-2 above, requiring the use of the 310 ERC's retention and/or retransmission policy may be subject 311 to user preference although in most jurisdictions, local laws 312 specify such policies and may not be overridden by user 313 preference. 315 Location information is considered so important during emergency 316 calls, that it is to be transmitted even when it is not considered 317 reliable, or might even be wrong. For example, some application 318 might know that the DHCP reply with location information was 319 overwritten recently (or exactly) when a VPN connection was 320 activated. This could, and likely will, provide any new location 321 information to the UA from somewhere far away from the UA (perhaps 322 the user's corporate facility). 324 E-5 Location information MUST be transmitted, if known to the UAC, 325 in all calls to an ERC, even in the case it is not considered 326 reliable. 328 E-6 The UAC SHOULD be able to inform the ERC that the location 329 information provided in the SIP message might be wrong. 331 Requirements U-U4 and U-PS8 stipulate the inclusion of how the UAC 332 learned its location. This can be especially useful to an ERC 333 operator attempting to learn all that is possible from this remote 334 person in distress. With that in mind, it is important to 335 distinguish the location information learned locally from LI learned 336 over a VPN; which in itself is useful additional information to that 337 ERC operator. 339 E-7 The UA MUST not provide the (overwritten?) location information 340 provided by a VPN (in lieu of the LI from the local network). 342 E-8 The UA SHOULD include within the location conveyance to the ERC 343 that it is (or recently was) connected to a VPN. 345 7. Current Known Open issues 347 This is a list of open issues that have not yet been addressed to 348 conclusion: 350 1) Whether SIP Proxies SHOULD be able to insert location information 351 into an emergency call set-up (the INVITE)? 353 1a) This has the additional implication of whether or not, or 354 regardless of the fact the UAC already inserted location into 355 the sos@localdomain INVITE. 357 1b) Should the Proxy somehow differentiate its location 358 information from that provided by the UAC (with each LI 359 having a SIP entity (type?) originator label? 361 1c) Should there be any behavior difference with respect to Open 362 Issue #1b if the Proxy does not know or cannot tell if the 363 UAC inserted location information (further emphasizing the 364 need for some form of originator label)? 366 2) Whether SIP Proxies SHOULD be able to return location information 367 in a Redirect message to the UAC making the emergency call? 369 3) If S/MIME is chosen as a SHOULD (in general, vs. TLS), this doc 370 might consider stipulating a special purpose Proxy (an "emergency 371 services" proxy) that can process location information (a Geopriv 372 LO) and route the message directly to the appropriate ERC. 374 At Issue: plain "vanilla" proxies probably won't have the 375 capabilities to route based on location information in the 376 near future, but should that timing be considered here? 378 8. Security Considerations 380 Conveyance of geo-location of a UAC is problematic for many reasons. 381 This document calls for that conveyance to normally be accomplished 382 through secure message body means (like S/MIME or TLS). In cases 383 where a session set-up is routed based on the location of the UAC 384 initiating the session or SIP MESSAGE, securing the location with an 385 end-to-end mechanism such as S/MIME is problematic. 387 9. IANA Considerations 389 There are no IANA considerations within this document at this time. 391 10. Acknowledgements 393 To Dave Oran for helping to shape this idea. To Jon Peterson and 394 Dean Willis on guidance of the effort. To Henning Schulzrinne, 395 Jonathan Rosenberg, Dick Knight, and Keith Drage for constructive 396 feedback. 398 11. References - Normative 400 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 401 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 402 Initiation Protocol ", RFC 3261, June 2002 404 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 405 levels," RFC 2119, Mar. 1997. 407 [3] H. Schulzrinne, "draft-schulzrinne-sipping-sos-04.txt", Internet 408 Draft, Jan 03, Work in progress 410 [4] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. 411 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 412 Messaging" , RFC 3428, December 2002 414 [5] J. Polk, J. Schnizlein, M. Linsner, " draft-ietf-geopriv-dhcp-lci- 415 option-03.txt", Internet Draft, Dec 2003, Work in progress 417 [6] H. Schulzrinne, "draft-schulzrinne-geopriv-dhcp-civil-01.txt", 418 Internet Draft, Feb 03, Work in progress 420 [7] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "draft- 421 ietf-geopriv-reqs-04.txt", Internet Draft, Oct 03, Work in 422 progress 424 [8] J. Rosenberg, "Requirements for Session Policy for the Session 425 Initiation Protocol�, draft-ietf-sipping-session-policy-req-00", 427 12. Author Information 429 James M. Polk 430 Cisco Systems 431 2200 East President George Bush Turnpike 432 Richardson, Texas 75082 USA 433 jmpolk@cisco.com 434 Brian Rosen 435 Marconi Communications, Inc. 436 2000 Marconi Drive 437 Warrendale, PA 15086 438 Brian.rosen@marconi.com 440 IPR Statement 442 The IETF takes no position regarding the validity or scope of any 443 intellectual property or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; neither does it represent that it 447 has made any effort to identify any such rights. Information on the 448 IETF's procedures with respect to rights in standards-track and 449 standards-related documentation can be found in BCP-11. Copies of 450 claims of rights made available for publication and any assurances 451 of licenses to be made available, or the result of an attempt made 452 to obtain a general license or permission for the use of such 453 proprietary rights by implementers or users of this specification 454 can be obtained from the IETF Secretariat. 456 The IETF invites any interested party to bring to its attention any 457 copyrights, patents or patent applications, or other proprietary 458 rights which may cover technology that may be required to practice 459 this standard. Please address the information to the IETF Executive 460 Director. 462 Full Copyright Statement 464 "Copyright (C) The Internet Society (February 23rd, 2001). 465 All Rights Reserved. 467 This document and translations of it may be copied and furnished to 468 others, and derivative works that comment on or otherwise explain it 469 or assist in its implementation may be prepared, copied, published 470 and distributed, in whole or in part, without restriction of any 471 kind, provided that the above copyright notice and this paragraph 472 are included on all such copies and derivative works. However, this 473 document itself may not be modified in any way, such as by removing 474 the copyright notice or references to the Internet Society or other 475 Internet organizations, except as needed for the purpose of 476 developing Internet standards in which case the procedures for 477 copyrights defined in the Internet Standards process must be 478 followed, or as required to translate it into languages other than 479 English. 481 The limited permissions granted above are perpetual and will not be 482 revoked by the Internet Society or its successors or assigns. 484 This document and the information contained herein is provided on an 485 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 486 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 487 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 488 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 489 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 491 The Expiration date for this Internet Draft is: 493 August 9th, 2004