GeoPriv R. Marshall, Ed. Internet-Draft TCSExpires: August 9,Intended status: Standards Track March 4, 2007FebruaryExpires: September 5, 2007 Requirements for a Location-by-Reference Mechanism used in Location Configuration and Conveyancedraft-marshall-geopriv-lbyr-requirements-00draft-marshall-geopriv-lbyr-requirements-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onAugust 9,September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines terminology and enumerates requirements for a location-by-reference approach to location configuration and conveyance interactions useful for emergency call routing for voice- over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . .45 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .56 3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . .5 3.2. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.Basic Actors . . . . . . . . .Examples of various LRI Model . . . . . . . . . . . . . . . .78 5. High-Level Requirements . . . . . . . . . . . . . . . . . . .912 6. Security Considerations . . . . . . . . . . . . . . . . . . .1114 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .1215 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .1316 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .1417 10. References . . . . . . . . . . . . . . . . . . . . . . . . . .1518 10.1. Normative References . . . . . . . . . . . . . . . . . . .1518 10.2. Informative References . . . . . . . . . . . . . . . . . .1518 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .1720 Intellectual Property and Copyright Statements . . . . . . . . . .1821 1. Introduction This document identifies the individual requirements underlying how a Location-by-Reference (LbyR) mechanism is to be used over the Internet, applied to either a Conveyance protocol or to a Configuration protocol. The LbyR approach is in contrast to the Location-by-Value (LbyV) model, which uses a "location object" (e.g., PIDF-LO) exclusively. Examples using the Location-by-Value method are beyond the scope of this document. A mechanism for either (or both) location configuration and location conveyance may rely on either a location-by-value approach, containing and transporting location information along every leg of the signaling path, or alternatively, a different approach, using a location-by-reference technique, which may be used to reference a location with some identifier, and to de-reference the location when needed for a location-based decision. [http://www.ietf.org/internet-drafts/ draft-ietf-sip-location-conveyance-07.txt] For an application of LbyR Conveyance, we choose to use the example of SIP signaling within an emergency services context, though we also talk about LbyR in a more general sense. In this case, a SIP user agent, or SIP proxy server acting on behalf of a user agent, to another user agent via the SIP protocol [RFC3261]. In place of the actual value for a "Location", a Location Reference ID (LRI) is used to represent the "value" of the location, stored in some Internet-connected host, which we call a location server. For a LbyR Configuration protocol mechanism, even for the emergency service context mentioned, many different protocol choices exist. These include DHCP, LLDP-MED, and several Layer 7 protocols being considered for standardization. Regardless of the variety of choices, the general concept of how LbyR is used for configuration, is not specific to any particular protocol choice. A Location which is referenced can be either Geographic location [RFC 3693] (e.g., lat/lon), or a Civic location (e.g., street address). We reintroduce a few basic entities [RFC3693] into the Location-by- Reference discussion. These include a "target" as the entity whose location is being transmitted, (e.g., a user agent's (UA) location. A "using protocol", defined as how a "location server" transmits a "location reference identifier" to a "location recipient". Privacy of a target's location, with repect to identity is important to protect, hence all examples shown assume that any user identity associated with the target is not included with location. Location can be pushed from one host to another, as part of a signaling protocol, in order to be used for location-based routing (or other purposes, outside the scope here), or it can alternatively be queried via a client request to a server which provides location [ref. drafft-sip-conveyance- TBD]. In the case of LbyR Conveyance, the actual location (i.e., location object) never gets pushed along, but is replaced by a Location Reference Identifier. In the case of a client which queries a server for location, the query is either to obtain a Location Reference Identifier, or to obtain an actual Location (e.g., location object) based the input of an LRI in the query. The draft-sip-conveyance- document details how SIP proxies treat LbyV or LbyR scenarios for conveying location via the SIP protocol. Whereas location objects are readily consumable by the hosts that using protocols deliver to, a Location Reference ID must first go through a dereference step in order to be useful. In our SIP example, for LbyR, instead of having a content identifier (cid:) pointing to a location object within a SIP body, the LRI is carried in the Geolocation header of a SIP message which is used to get a location via a dereference. A common example use case is the "emergency services call" case, where an request for emergency services is initiated over the Internet via the SIP protocol (i.e., a '9-1-1' or '1-1-2' call). In order to route the call to the appropriate PSAP, the UA client location is required. This document uses as a baselinecondition,scenario, theprimaryexample of an emergency call,which includes awhere an request for emergency servicesvia a SIP-enabled end device, connecting throughis initiated over the Internet using the SIP protocol (e.g., a '9-1-1' or '1-1-2' call). In order toan IP- enabled PSAP (Public Service Answering Point).route the call to the appropriate PSAP, since PSAPs are divided regionally, the UA client location is required. We first define terminology in Section 3. The document then outlines baseline requirements (Section 5), around the referencing and dereferencing of location via some location identifier in lieu of the emergency caller's actual location. Identification of the caller, as associated information to location or location reference, either in conveyance or configuration, is out of scope in this document. Location-by-reference is a mechanism which is in use in VoIP 9-1-1 systems at the time of this writing, and justified based on the requirements listed in this document. 2. Requirements Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[1], with the qualification that unless otherwise stated these words apply to the design of the location-by-reference mechanism, and not its implementation or application.[RFC2119]. 3. Terminology 3.1. Terms Several of the terms presented below are based on RFC3693, and in some cases, extended to include additional language to support the Location-by-Reference model. Dereference Protocol: A protocol which is used to query a Location server based on an LRI as input. Location Reference Identifier (LRI): An identifier(could be of the form of any(e.g., URI) which isdesigneda pointer torepresenta target's locationobject.record on a remote host (e.g., location server), and is used by a dereferencing protocol for retrieval of that specific location. Location Server (LS): A network host which is designed to store location and to provide that same location to appropriate location client requests.Location-toMay also be referred to as a Location Information Server (LIS). LoST Mapping Server (LMS): A network host which provides a URImapping serviceresponse based onaninput of a location and serviceidentifier. Call Server/Proxy (CS/P):identifier [ref. draft-ecrit-lost-]. Using Protocol: Anetwork host which plays the role of a SIP Proxy. 3.2. Actors de-referenceprotocolclient: The term to describe the entity requestingthat carries a Location Objectin exchange for aor an Location Reference Identifierprovided. de-reference protocol server:(i.e., LRI). Target: A person or other entity whose location is communicated by a Geopriv Location Object. Location Recipient (LR): Thetermentity that receives location information. It may have asked for this location explicitly (by sending a query containing an LRI todescribea location server), or it may receive this location asynchronously. Also may be referred to as a Dereference client within this document, in the context of the Location-by-Reference model. Location Server (LS): The entityprovidingto which aLocation ObjectLG publishes location objects, the recipient of queries from location receivers, and the entity that applies rules designed by the rule maker. Also may be referred to asan output based onaLocation Reference Identifier input. 3.3. LocationDereference server within this document, in the context of the Location-by-Reference model. Location: A geographic identification assigned to a region or feature based on a specific coordinate system, or by other precise information such as a street number and name. It can be either a civic or geographic location. Civic location: A described location based on some reference system, such a jurisdictions or postal delivery. A street address is a common example. Geographic location: A reference to a point which is able to be located as described by a set of defined coordinates within a geographic coordinate system, such as latitude and longitude within the WGS-84 datum. For example, 2-D geographic location is defined as an (x,y) coordinate value pair according to the distance north or south of the equator and east or west of the prime meridian. Location-by-Value: The mechanism of representing location either in conveyance protocols or configuration protocols as fully specified, (i.e., including the actual location value itself). Location-by-Reference: The mechanism of representing location either in conveyance protocols or configuration protocols as an identifier which refers to a fully specified location, (i.e., including a pointer to the actual location value itself). 4.Basic ActorsExamples of various LRI Model To support the referencing or de-referencing of a location, it is appropriate to describe a diagram consisting of network elements around which this might be done. These elements include, the UA (User Agent),CS/P (Call Server/Proxy), aP (Proxy), LS (Location Server), and a UA at the PSAPUA.(UA2). This section outlines which entities will be considered in thereferernce de-referencereferernce/dereference scenarios discussed.+-------+<t> <figure anchor="LRI Indirection" title="LRI query/response - where Target = Location Recipient."> <artwork><![CDATA[ +--------+ +--------+ | Target |<---------response w/LO-------| ||-------------------------------|LMS |---|---------------- \== | ||--- \ \ +-------+ \ \ \ \ \ \ \ \ \ \ \ \ +-------+ +-------+ +-------+ +-------+LS | | LR |-----------query w/LRI------->| | +--------+ +--------+ Figure 1: Framework for referencing or de-referencing location in a SIP session. Above figure shows simplest LRI interaction, when target happens to also be the Location Recipient [ref. RFC3693 terms] +--------+ +--------+ +--------+ | | | | | |UA1 |------| P1 |------| P2 |------| UA2| Target |<----------acquire LO---------| LS |<--deref--| LR | | | | | LRI | | +--------+ +--------+ +--------+ |+-------+ +-------+ +-------+ +-------+|/ / /+----------------convey LRI--------------------------------->+ Figure 2: Setup showing LRI indirection. The above interaction reduces to two basic interactions: 1. Location provision from LS/LIS to target by reference (LRI). 2. Location indirection by the LS/LIS, at the request of the Target. Location updates, are possible in either case. +--------+ +--------+ +--------+ |/ / /|/ / / +-------+ / / /| ||-- /| |-------LO------+ | Target |<........>| LG |--LI/LO-->| LS/DS | | | | | | | |<---LRI---+ | +--------+ +--------+ +--------+ | | | | | v +--------+ +--------+ +--------+ | | | | | | | LRG |---LRI--->| LT |--LRI-->| LR/DC | | | | | | | +--------+ +--------+ +--------+ Figure 3: General Setup - LG interaction. Definitions: Target, LG, LR, LI, LO as in RFC 3693. LRG = Location Reference Generator (creates reference) LT = Location Transmitter (one party to Conveyance Protocol) DS/DC = Dereference Server / Client Protocols: Dereference Protocol is between DS and DC Conveyance Protocol is between LT and LR +--------+ | | +--------------| LS|---|---------------- /|-----------------------------------+ | | | | | + -------+ | LCP ^ LDP | LDP | V V V +--------+ +--------+ +--------+ +--------+ | | | | | | | | | UA1 |--------->| P1 |--------->| P2 |--------->| UA2 | | | | | | | | | +--------+ +--------+ +--------+ +--------+ ^ LMP V +--------+ | | ||------------------------------ +-------+LMS | | | +--------+ Figure1: Framework for referencing or de-referencing location in4: Example of a SIPsession.call. Definitions: LS = Location Server (as in RFC 3693) LCP = Location Configuration Protocol LDP = Location Dereference Protocol LMP = Location Mapping Protocol Sequence: 1. UA1 acquires LRI from its LS (acting as LRG) 2. UA1 sends an INVITE to a service URN via P1 3. P1 dereferences the LRI and uses it to get a URI from the LMS 4. UA2 may also wish to dereference the LRI, e.g., to get the current location of UA1. Figure 1 shows the interaction between the entities involved in the call, as to how location is referenced and subsequently de- referenced. The figure proposes that location reference is conveyed from the endpoint-to-endpoint via each middlebox (SIP Proxy), and undergoes a de-referencing operation at each step. The figure also depicts a LMS (Location-to-Mapping Server) element which is used to determine the next target destination, based on the de-referenced location. At the PSAP, the end device also receives a location reference, (as indicated in this figure), and executes a de-reference quiery. Various potential interactions between the entities depicted in Figure 1 are described below: 1. Location information might be generated by the end host itself, in which case it may then request reference identifier based on the location that it generated and provided to the LS. 2. Alternately, location information might be either generated, provisioned, or stored by the LS (Location Server), and represented to the end device as a location reference, via a location configuration protocol (e.g., using DHCP or some L7LCP (Layer 7 Location Configuration Protocol). 3. The location reference is only useful to mask the actual location, but must be de-referenced in order to be useful for location-based routing. Once the location is de-referenced at the LS and returned to the requestor, it can then be used as input to a location-to-mapping service (e.g., LoST). The mapping server returns a URI which can be used to establish the signaling to the next target destination. This returned target identifier may be the URI of the next SIP Proxy (or any other element along the routing path), or may be the URI of the appropriate IP-based PSAP. 4. The PSAP, consistent with the figure, may choose to de-reference the location identifier, once it is received, in order to view the location, and to request subsequent location-based actions. 5. High-Level Requirements Below, we summarize high-level design requirements needed for a location-by-reference mechanism. Rq1. LocationConveyance By Value (LbyV):Reference Identifier as a URI: Theconveyancedereferencing protocol MUST supportthe conveyance of location informationan LRI inits fully- containedURI form,i.e., a PIDF-LO. (I know this isn't a requirement for LbyR, but is included for balance.)and may support other non-URI forms. Rq2.Location Conveyance By Reference (LbyR):Dereference Protocol Confidentiality: Theconveyancedereferencing protocolMAYMUST support mechanisms for encrypting messages sent between client (Location recipient) and server (Location server). Rq3. Dereference Protocol Transparancy: The dereferencing protocol MUST support theconveyanceexchange ofa location information reference identifier,messages without encryption (i.e., in plaintext). Motivation: In theform of 'any URI', which cancase where encrypted message exchange is unsuccessful, there must beuseda way tode-reference the location into its fully-contained form, (e.g.,try to dereference aPIDF-LO). Rq3. Location Conveyance Duality: The location conveyance protocol MAY support both location value andlocation reference identifier with less restriction (e..g., in thesame message.emergency service case, where every call always needs answered). Rq4.PrivateLocation ReferenceId.:Expiry: Thedereferencingdereference protocol MUST supportthe encryptionspecification of alocation reference identifier. Rq5. Public Location Reference Id.: The dereferencing protocol MAY convey a location reference identifier in plaintext. Rq6. Location Reference Expiry: There MUST exist, a location reference uri format that includes a specified,finite period ofvalidity.validity for the LRI. Motivation: Location references are not intended to represent a location forever, and the identifier eventually may need to be recycled, or may be subject to a specific window of validity, after which the location reference fails to yield a location, or the location is determined to be kept confidential. An expiry timer for a location reference ensures that the location reference becomes invalid based on configuration.Rq7. de-referenceRq5. Dereference Protocol Transport: The de-reference protocol MUST support TCP/IP and MAY support UDP/IP.Rq8. LRI Distribution: The location reference standard MUST allow construction of location references that can be distributed to and de-referenced by multiple parties, and MAY support references that are restricted to a single de-referencer" Rq9''. de-referenceMotivation: Practical, near-term deployment issues may make TCP/IP implementations unachievable. Rq6''. Dereference Protocol Authentication: The dereferencing protocol MUST support both client-side and server-side authentication. Motivation: It is reasonable to expect implementations of authentication to vary. Some implementations may choose to support both client-side and server-side authentication, might support one only, or may support neither.Rq10.Rq7. Location Privacy: Thede-referencedereference protocol MUST support the application of privacy rules to the dissemination of a requested location object.The entity that receives requests through the de-reference protocol MUST obey all privacy rules that apply to a requested location object. Rq11. De-referencedRq8. Dereferenced PIDF-LO Result: The dereferencing of an LRI MUST result in a well-formed PIDF-LO. Motivation: This is in order to ensure adequate privacy rules can be adhered to, since the PIDF-LO format comprises the necessary structures to maintain location privacy.Rq12. Expiry of de-referenced Location: The de-referenced location, in PIDF-LO format, MUST include a configurable expiry timer6. Security Considerations Considerations for security tosignala Location-by-Reference model for thepoint after whichdereference protocol, include, 1. Privacy Privacy of thePIDF-LO containedLRI itself Privacy of the dereferenced locationis no longer considered usable. Motivation: Onceobject 2. Expiry Expiry of the LRI. Expiry of the dereferenced locationis de-referenced, it would be difficult to keep it from being passed around further 'asobject. 3. Theft Theft of aplain old PIDF-LO', henceLRI. Theft of atimer expiry is specified. (This technique does not prevent would-be 'black-hats' from reusing the PIDF-LO, but provides some additional functionality withindereferenced location object. 4. Replay/Reuse Replay of aproper use context. Rq13. De-reference Protocol Selection:stolen LRI to perform a dereference operation. Reuse using the dereference location object. 5. Impact of the two forms of location reference. Location provision from LIS byreference systems MUST supportreference. Location indirection by the LIS, atleast one, and MAY support multiple dereferencing protocols. 6. Security Considerations Threats andthe request of the Target. May also reference securityrequirements are discussed in a separate documentconsiderations found within document[11].[I-D.ietf-geopriv-l7-lcp-ps]. 7. IANA Considerations This document does not require actions by the IANA. 8. Contributors[TBD]Andrew Newton, James Polk, Martin Thompson, Richard Barnes, Barbara Stark, James Winterbottom, Hannes Tschofenig The contributors can be reached at: Name user@example.com 9. Acknowledgments [TBD] 10. References 10.1. Normative References[1][RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References[2][I-D.hardie-ecrit-lost] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-hardie-ecrit-lost-00 (work in progress), March 2006. [I-D.ietf-ecrit-requirements] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-12 (work in progress), August 2006. [I-D.ietf-ecrit-security-threats] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 (work in progress), July 2006. [I-D.ietf-geopriv-dhcp-civil] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-00 (work in progress), January 2007. [I-D.ietf-sipping-toip] Wijk, A. and G. Gybels, "Framework for real-time text over IP using the Session Initiation Protocol (SIP)", draft-ietf-sipping-toip-07 (work in progress), August 2006. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[3][RFC3351] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.[4][RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.[5][RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.[6][RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.[7][RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.[8][RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.[9][RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.[10][RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February2006. [11] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 (work in progress), July 2006. [12] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-12 (work in progress), August 2006. [13] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-hardie-ecrit-lost-00 (work in progress), March 2006. [14] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. [15] Wijk, A. and G. Gybels, "Framework for real-time text over IP using the Session Initiation Protocol (SIP)", draft-ietf-sipping-toip-07 (work in progress), August2006. Author's Address Roger Marshall (editor) TeleCommunication Systems, Inc. 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 US Phone: +1 206 792 2424 Email: rmarshall@telecomsys.com URI: http://www.telecomsys.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).