DHC Working Group James Polk Internet Draft Cisco Systems Expiration: Dec 19th, 2006 June 19th, 2006 File: draft-polk-dhc-ecrit-lost-server-uri-00.txt A Dynamic Host Configuration Protocol Option for Requesting and Receiving a Uniform Resource Identifier for a Location-to-Service Translation (LoST) Server 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 on Dec 19th, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a new Dynamic Host Configuration Protocol (DHC) Option to deliver a Location-to-Service Translation (LoST) Protocol URI to a client. This SIP(S)-URI will be become the destination URI in any call set-up message to a Public Safety Answering Point (PSAP) in times of an emergency. Polk Expires Dec, 2006 [Page 1] Internet-Draft DHC Option for LoST Server URI June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 4 1.2 Terms, Acronyms and Definitions . . . . . . . . . . . . . 4 2. Solution Message Flow Example . . . . . . . . . . . . . . . . 4 3. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 5 3.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1 Normative References . . . . . . . . . . . . . . . . . . 6 7.2 Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . 7 1. Introduction In IP communications, destination addressing can be to an IP address directly, or to a Uniform Resource Identifier (URI), where the service at the URI is resolved to a destination IP address by the source system or along the path. In Voice over IP communications, the destination IP address is infrequently used by the calling device; rather, a URI is used. The burden is on call servers along the path to resolve this URI to IP address to determine where to route the packet(s) to. Understanding the decomposed nature of voice communications, quite pronounced with peer-to-peer protocols potentially having servers 100s and 1000s of miles away from the calling device, call signaling at a higher layer may lack the local knowledge to appropriately provide the client with what is necessary to make a local emergency call. In emergency communications, the act of calling for help is a highly localized event, requiring knowledge of where the caller is. The destination of that emergency call will also be local in nature. This document defines a new Dynamic Host Configuration Protocol (DHC) Option [RFC2131] to deliver a specific type of URI requested by a client of a server, and transmitted unrequested from a server to a client. The type of URI is that of a Location-to-Service Translation (LoST) Protocol mapping server [ID-LOST]. A Public Safety Answering Point (PSAP) is an emergency call center; most likely the first point of contact when a caller dials 911 or 112 (or another locally significant number) for emergency help. These numbers are not routable, therefore the service within a given jurisdiction cannot be accessed from outside a local area. Each PSAP will have a unique URI. At issue is how an IP device conveys Polk Expires Dec, 2006 [Page 2] Internet-Draft DHC Option for LoST Server URI June 2006 where it is to get to its appropriate PSAP. A local configuration network can provide a LoST server URI to a client to request map of that client's location to a PSAP URI. LoST mapping servers will likely have the necessary ability (horsepower, memory, database, etc) to increase granularity within the region's access networks to provide exactly which PSAP a caller needs to contact, given their location. In a Voice over IP system, an emergency URI is an essential part of configuration information necessary for usage by an client for the particular purpose of contacting what is at that local URI. Having access to a mapping server that can provide this URI to a client is critical. Using SIP [RFC3261] as the application layer call message flow example protocol, emergency calling wants the following message flow to occur when Alice is in trouble: Alice PSAP [M1] INVITE (sos & location) --------------------------> [M2] 200 OK <-------------------------- [M3] ACK --------------------------> Media Session Established <=========================> Figure 1. Basic Emergency Message Flow SIP uses an INVITE message as its initial call set-up message. All relevant addressing and other information can be in this one message, including the destination URI (address) for Alice's appropriate PSAP, given where she is. Where Alice's voice device, called a user agent (UA) by SIP, learned the destination URI is what this document solves for some network topologies. In Figure 1., Message-1 contains Alice's location, defined in [ID-SIP-LOC], perhaps learned from the UA requesting DHC Option 123 [RFC3825] or the Option that results from [ID-CIVIC] at boot time. This location information, which is vital to an emergency call because it informs the PSAP where to send first responders, is encoded inside the INVITE's message body in the form of an XML document PIDF-LO [RFC4119]. The destination URI of this message can be learned by the UA requesting a DHCP server do the mapping query in certain circumstances or, the UA performing a LoST Polk Expires Dec, 2006 [Page 3] Internet-Draft DHC Option for LoST Server URI June 2006 [ID-LoST] mapping request itself. This document defines how the client learns the URI of its LoST mapping server. Section 2 provides an example message flow of what this document achieves. Section 3 shows the DHC Relay Option Format. Section 3.1 discusses the rules of usage of this Option. Section 4 is the IANA Considerations section of this DHCP Option. 1.1 Conventions used 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.2 Terms, Acronyms and Definitions The following terms and acronyms are used within this document: Emergency Services Routing Proxy - a special instance of a SIP Proxy that understands emergency routing to a PSAP based on the location of the caller ESRP - Emergency Services Routing Proxy Location-to-Service Translation - A mapping function that takes a given location and determines the PSAP URI for a user who calls from that location. LoST - Location-to-Service Translation PSAP - Public Safety Answering Point Public Safety Answering Point - the emergency response call center talking the local emergency calls from people in distress. This facility can be logical, and can transfer (reroute) any request sent to it to another facility deemed more appropriate to receive the request. 2. Solution Message Flow Example Figure 2. what can occur prior to the flow in Figure 1., showing where Alice's client learns the essential configuration information to place an emergency call. Omitted is SIP registration step, which may or may not be necessary, depending on location policy. In Message-3, Alice's client requests both Location and her LoST server URI. The server acquires Alice's location (not explained here) and looks up the appropriate LoST mapping server, and generates Message-4. Message-5 is the LoST query to a Mapping server for the appropriate PSAP SIP(S)-URI. Message-6 is the Polk Expires Dec, 2006 [Page 4] Internet-Draft DHC Option for LoST Server URI June 2006 mapping response providing Alice's client with her current PSAP URI. Alice DHCP Server Mapping Server PSAP [M1] DHCP DISCOVER (IP add, Subnet, Default GW, etc) ----------------> [M2] DHCP OFFER <---------------- [M3] DHCP REQUEST or INFORM (Location, LoST-URI) ----------------> [M4] DHCP ACK (contains location & LoST-URI) <---------------- [M5] LoST Query (contains Location) -------------------------------------> [M6] LoST Response (contains PSAP-URI) <------------------------------------- Emergency Call set-up initiated to LoST supplied URI ----------..........----------........-------........------> Figure 2. Location-to-URI Mapping Requested by DHCP Server Using this LoST URI, a client can contact the LoST server when a user calls for emergency help, ensuring the PSAP URI retrieved is the freshest it can be for the emergency call. The details of emergency calling are out of scope for this Option, and are included here to give applicability and justification to the Option. 3. DHC Relay Option Format The format for this Option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code XXX | Length | URI of LoST Server + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI of LoST Server (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI of LoST Server (cont'd to a maximum of 253 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. The URI Option Format Code = The IANA Assigned Option number Length = one octet providing a variable length value of the number of bytes in the Option, including this length field Polk Expires Dec, 2006 [Page 5] Internet-Draft DHC Option for LoST Server URI June 2006 URI = This is a variable length field containing the URI being transmitted, to a maximum of 253 bytes in length 3.1 Rules of Usage The following are the rules of usage of this DHCP Option: - a LoST mapping server URI MUST NOT have a Length field of more than 253 (bytes), complying with [RFC2131] - Clients making a request for one this URI, using a [REQUEST] message, will send this message to the Server with URI length field set to zero - The URI schema of the LoST URI has not been decided yet, as the protocol transport is still up in the air. A future version of this document will specify this schema. 4. IANA Considerations IANA has assigned a DHCP option code of [XXX] for the LoST Mapping Server URI option defined in this document. 5. Security Considerations Where critical decisions might be based on the value of this URI option, DHCP authentication in [RFC3118] SHOULD be used to protect the integrity of the DHCP options. Since there is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the client and destination DHCP server to capture any URIs in transit. When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks. 6. Acknowledgements Your name here... or you can contribute a fair amount of text and become a co-author. 7. References 7.1 Normative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Polk Expires Dec, 2006 [Page 6] Internet-Draft DHC Option for LoST Server URI June 2006 March 1997. [ID-LoST] T. Hardie, H. Schulzrinne, A. Newton, H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", draft-hardie-ecrit-lost-00.txt, "work in progress", February 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 7.2 Informative References [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf- sip-location-conveyance-03.txt, "work in progress", June 2006 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", draft-ietf-geopriv-dhcp-civil-09, "work in progress", January 2006 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2006 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Fax: none Email: jmpolk@cisco.com Polk Expires Dec, 2006 [Page 7] Internet-Draft DHC Option for LoST Server URI June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Polk Expires Dec, 2006 [Page 8]