Network Working Group James Polk Internet-Draft Cisco Systems Expires: December 19th, 2006 June 19th, 2006 Learning the Initial Location-to-Service Translation (LoST) Uniform Resource Identifier (URI) During Session Initiation Protocol (SIP) Registration draft-polk-ecrit-lost-server-uri-00 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 December 19th, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract A Location-to-Service Translation protocol (LoST) Server is used to resolve or map a given location with an appropriate Public Safety Answering Point (PSAP) Uniform Resource Identifier (URI) for that location. This query is conceivably performed on two occasions: prior to making an emergency call, and during an emergency call. This document specifies a new Session Initiation Protocol (SIP) header, returned in a SIP Registration transaction, indicating to a SIP user agent the appropriate LoST Server's URI to send this query to. Polk Expires December, 2006 [Page 1] Internet-Draft Learning the Backup LoST URI in SIP June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 3 2. Basic Overview of Learning LoST Server URI . . . . . . . . . 3 3. New LoST-Server-URI Header in SIP . . . . . . . . . . . . . . 4 4. New LoST-Server-URI Option-Tag . . . . . . . . . . . . . . . 4 5. Rules of the LoST Server URI Extension in SIP . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1 Normative References . . . . . . . . . . . . . . . . . . 6 9.2 Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . 7 1. Introduction The Location-to-Service Translation (LoST) protocol [ID-LOST] is the resolution protocol tasked with determining the appropriate PSAP SIP(S)-URI from a given location value representing where a phone is located. A SIP user agent (UA) can learn the URI of a LoST server to query through one or more of a least three ways: o Through manual configuration o During boot time through a device configuration protocol such as DHCP (or LLDP-MED) o During SIP Registration It is envisioned that a Voice Service Provider (VSP) will want or be required, perhaps by law, to control the actions taken when one of its (SIP) registered phones places an emergency call. Of the three choices listed, only the third choice: during SIP/device Registration involves the VSP; therefore this is the focus of this document. This document specifies a new SIP header to allow a SIP user agent to learn the appropriate LoST Server URI for resolving where to send a LoST Query seeking an appropriate Public Safety Answering Point (PSAP) SIP(S)-URI. This header is used during the SIP Registration transaction, defined in [RFC3261]. It is conceivable that this extension could be applied to/utilized in a SUBSCRIBE/NOTIFY pair of transactions, but that is not detailed here. Polk Expires December, 2006 [Page 2] Internet-Draft Learning the Backup LoST URI in SIP June 2006 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 [RFC2119]. 2. Basic Overview of Learning LoST Server URI As scoped in [ID-ECRIT-FW], once a SIP device boots, communicates with a configuration server to learn its IP address, default gateway, and other aspects to communicate, including learning its location, likely from [RFC3825] or [ID-CIVIC], this device will register with a Voice Service Provider. This last part is a SIP REGISTER transaction. SIP REGISTER is RECOMMENDED to be transmitted using TLS for confidentiality and integrity in [RFC3261]. Location can be conveyed by-reference, meaning in a URI in a header of a SIP message, or by-value, meaning the location itself is contained within the SIP message in the form of a Presence Information Date Format - Location Object (PIDF-LO) as defined in [RFC4119]. SIP location conveyance is specified in [ID-SIP-LOC]. That document specifies how a location can be included in a SIP REGISTER message. That function is necessary for this extension. In order for a UA to learn a LoST URI to query for a PSAP SIP(S)-URI, the UA will follow this basic message flow: UA Alice SIP Registrar | [M1] REGISTER (w/ Location) | |---------------------------------------->| | [M2] Response (w/LoST Server URI) | |<----------------------------------------| | | Figure 1. Learning a LoST Server URI Through SIP Registration In message [M1], the SIP REGISTER message, Alice would include a new LoST-Server-URI option tag in either a Supported or Require header, and include her location by-reference in a Location header, or by-value in a PIDF-LO message body (part). The VSP's Registrar server would receive this request message. During processing this message, the Registrar would understand that Alice either wants or requires a LoST Server URI be returned in a successful response back. Having Alice's location is a MUST. The 200 OK response message would contain a LoST-Server-URI header with the URI of the LoST server to be queried by Alice to learn her PSAP SIP(S)-URI. This SIP(S)-URI is meant to be used as a backup URI to the appropriate PSAP for Alice's given location at registration time. Polk Expires December, 2006 [Page 3] Internet-Draft Learning the Backup LoST URI in SIP June 2006 [ID-LOST] and [ID-ECRIT-FW] specify how this PSAP URI is a fallback, to be used if the active mapping of a location to a PSAP-URI fails during the emergency call. More than one URI MAY be included in this new header. Each is to be considered equal in importance. Two URIs pointing at the same LoST server defeats the purpose of a UA being able to contact a secondary server if one is unreachable, for whatever reason. 3. New LoST-Server-URI Header in SIP The new "LoST-Server-URI" header has the following BNF syntax: LoST-Server-URI = "LoST-Server-URI" HCOLON (LostServerURI *(COMMA LostServerURI)) LostServerURI = SIP-URI / SIPS-URI / absoluteURI SIP-URI and SIPS-URI are defined in RFC 3261 [RFC3261]. The following table extends the values in Table 2&3 of RFC3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- LoST-Server-URI r r - - - - o - - Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- LoST-Server-URI r r - - - - - - - The LoST-Server-URI header MAY be read by a proxy in transit if present in a REGISTER request message. A proxy MUST NOT add the LoST-Server-URI header in transit if one is not present. More than one LoST-Server-URI header or header value MAY be in a message. Each is to be considered of equal importance, and MUST NOT be pointing at the same server. This creates multi-server redundancy in case one LoST server is unreachable, the secondary URI does not attempt to contact that same (unreachable) server. 4. New LoST-Server-URI Option-Tag This extension creates a new option tag: lost-server-uri. This option tag is to be used in SIP headers such as Supported, Require and Unsupported. This option tag MUST NOT be used in the Proxy-Require header, as the purpose of this extension is orthogonal to the operation of a SIP Proxy, therefore a UAC should not assume any Proxy understands this Polk Expires December, 2006 [Page 4] Internet-Draft Learning the Backup LoST URI in SIP June 2006 extension in order for the extension to work properly. 5. Rules of the LoST Server URI Extension in SIP The following are the rules of operation for this SIP extension for emergency calling: - A SIP REGISTER request message with a Supported header containing the lost-server-uri option tag means a UAC wants to learn its LoST Server URI during SIP registration, or registration refresh. The presence of this header MUST NOT prevent SIP registration from continuing if this Registrar does not support this extension. - A SIP REGISTER request message with a Require header containing the lost-server-uri option tag means a UAC needs to learn its LoST Server URI during SIP registration, or registration refresh. The presence of this header MUST prevent SIP registration from continuing if this Registrar does not support this extension. In this case, if this extension is not understood by the Registrar server, a 420 (Bad Extension) is the appropriate response message, containing an Unsupported header with a lost-server-uri option tag. - The UAC's Location MUST be by-value or by-reference in the REGISTER message to invoke this extension. If location is not in the message, a 424 (Bad Location Information) response is the appropriate response. This response SHOULD include both the lost-server-uri and location option tags in a Supported header to indicate to the UAC the Registrar can comply with this extension/feature if provided the appropriate information. - If a Registrar supports this extension, and receives a REGISTER request message containing lost-server-uri and location option tags in a Supported header, and detects location by-value or by-reference, the Registrar SHOULD include a LoST-Server-URI header with an appropriate URI as a header value in the 200 OK response message. - More than one LostServerURI header value MAY be in the "LoST-Server-URI" header, with no preferential ordering assigned if more than one value is present in this new header. Each additional header value SHOULD be considered another contact point for a mapping. - Each LoST URI in this message MUST point at unique LoST servers, enabling redundant servers to be included in a response message. 6. IANA Considerations This document adds one new SIP Header and one new option tag to the Polk Expires December, 2006 [Page 5] Internet-Draft Learning the Backup LoST URI in SIP June 2006 sip-parameters section of the IANA registry. 6.1 LoST-Server-URI Header Registry The SIP "LoST-Server-URI" header is created by this document, with its definition in Section 3 of this document, and rules in Section 5. 6.2 lost-server-uri Option Tag Registry The SIP option tag "lost-server-uri" is created by this document, with the definition in Section 4 of this document, and rules in Section 5. 7. Security Considerations This extension is a backup or fallback mechanism to learning and including a URI of a PSAP in an emergency call. The primary means of learning this URI is during call processing in a special Proxy Server called an Emergency Services Routing Proxy (ESRP). If this ESRP, which queries the LoST Server for a PSAP SIP(S)-URI fails, the back-up URI, enabled by this extension is used. This failure should be an highly unlikely event. Therefore it is not foreseen that this has many advantages of corrupting. The SIP REGISTER transaction should use TLS already, thus this extension is protected for confidentiality and integrity already through normal operation within SIP. This extension should add no new security concerns to SIP. 8. Acknowledgements Your name here.... or, if you contribute a fair amount of text, you can become a co-author 9. References 9.1 Normative References [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 [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. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Polk Expires December, 2006 [Page 6] Internet-Draft Learning the Backup LoST URI in SIP June 2006 Requirement Levels", RFC 2119, March 1997 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf- sip-location-conveyance-03.txt, "work in progress", June 2006 9.2 Informative References [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 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Fax: none Email: jmpolk@cisco.com 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 Polk Expires December, 2006 [Page 7] Internet-Draft Learning the Backup LoST URI in SIP June 2006 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 December, 2006 [Page 8]