Network Working Group T. Creighton Internet-Draft Comcast Cable Communications Intended status: Informational J-F. Mule Expires: August 21, 2008 CableLabs February 18, 2008 Provisioning Protocol Requirements for ENUM-SIP Addressing Servers draft-mule-peppermint-espp-requirements-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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Creighton & Mule Expires August 21, 2008 [Page 1] Internet-Draft espp-requirements February 2008 Abstract This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by an addressing server to return part of the session establishment data to SIP entities so that they can route SIP sessions to the target destinations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations and Use Cases Examples . . . . . . . . . . . . . . 5 3.1. Separation of Responsibility . . . . . . . . . . . . . . . 5 3.2. File-based Distribution and Bootstrapping . . . . . . . . 7 3.3. Backward Compatibility to Legacy Switch Translations . . . 7 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 8 4.1. Connection-Oriented Operation . . . . . . . . . . . . . . 8 4.2. File Oriented Operation . . . . . . . . . . . . . . . . . 8 4.3. Security Requirements: Authentication, Integrity and Confidentiality . . . . . . . . . . . . . . . . . . . . . 9 4.4. Data Model Requirements . . . . . . . . . . . . . . . . . 9 4.5. Data Presentation Requirements . . . . . . . . . . . . . . 9 4.6. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 4.7. Versioning, Capability Exchange, and Extensibility Requirements . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Creighton & Mule Expires August 21, 2008 [Page 2] Internet-Draft espp-requirements February 2008 1. Introduction This document presents a set of use cases and protocol requirements for an ENUM-SIP addressing Server Provisioning Protocol (ESPP). An ENUM-SIP addressing server is a session routing server which resolves telephone numbers or any type of public user addresses into routable Uniform Resource Identifiers (URIs) based on various rules and routing logic. The data provisioned into an ENUM-SIP addressing server is queried by SIP entities using ENUM [RFC3761] or Session Establishment Protocol (SIP) [RFC3261]. It is intended to provide the necessary information for a querying SIP entity to route a call to the target destination. In order to perform address resolution, the addressing server often receives configuration data from various data sources. These data sources may reside in a service provider or enterprise network (intra-office or intra-company back-office systems), or in a peer's network in the case of bilateral session peering agreements, or in a session peering registry shared by a group of SIP Service Providers (SSPs). These data sources advertise the public user identities they serve (SIP user addresses, telephone numbers, and other types of Uniform Resource Identifiers) along with other data elements like the Signaling path Border Elements (SBE) to use to reach those user identities. A provisioning protocol has been defined based on the requirements summarized in this document ([CableLabs-ESPP]) and it is presented in [I-D.espp-protocol]. A number of vendors have client and server implementations of this protocol and two interoperability testing events have been conducted to date. This document is organized as follows: Section 3 presents some motivations and use cases, and Section 4 defines protocol requirements for ESPP. The intent of the authors and participants in the CableLabs focus team is to provide this document as input for discussion in the IETF. Creighton & Mule Expires August 21, 2008 [Page 3] Internet-Draft espp-requirements February 2008 2. Terminology 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]. This document also reuses the SIP terminology defined in [RFC3261] and [I-D.ietf-speermint-terminology]. Creighton & Mule Expires August 21, 2008 [Page 4] Internet-Draft espp-requirements February 2008 3. Motivations and Use Cases Examples The main motivations for defining an open provisioning protocol for ENUM-SIP addressing servers are to allow multiple server vendors to accept provisioning data from multiple data sources (some internal to a SIP service provider, some controlled by one or more session peers), and to define a common and flexible data model for the data elements that may need to be provisioned. The remaining of this section provides a couple of use cases. 3.1. Separation of Responsibility A SIP Service Provider's business practices may impose a separation of roles and responsibilities such that: (a) network engineering and planning personnel are responsible for establishing points-of-interconnect (at layer 3 for IP internetworking and layer 5 for SBEs), (b) telephony personnel are responsible for provisioning telephone numbers, location routing numbers (LRNs), (c) other personnel or back-office systems are responsible for provisioning other forms of resolvable addresses (email, instant messaging, etc.). For example, two SIP service providers that respectively service the New York-Manhattan and New-York Queens metropolitan areas agree to peer. In unison, the network engineering personnel of each company establish physical inter-connect in the New York City 60 Hudson Street facility. Each SIP service provider commissions redundant Signaling path Border Elements that are used to secure the interconnect located at 60 Hudson Street. Then through the use of the ESPP protocol, the network engineering departments publish IP addressing information to each other's ENUM-SIP addressing servers - provisioning NAPTRs for each Ingress SBE and through Route objects associating them with the telephony address space (Service Area) of each metropolitan area. Once the Service Areas and Routes are established, the telephony personnel manage the telephony addressing by adding telephone numbers or LRNs to the respective Services Areas. Some of the session establishment data (SBEs, Service Areas, Routes) is usually provisioned once for each cable operator with occasional subsequent updates as interconnect points are added or changed. It is provisioned independently from the provisioning of the elements contained in Service Areas (TNs, TN Ranges, LRNs, or public Creighton & Mule Expires August 21, 2008 [Page 5] Internet-Draft espp-requirements February 2008 identities such as IM identifiers). This allows the rare process of provisioning SBEs, service areas, etc. to be distinctly separate from the continuous process of adding subscribers. Note that the exchange of this information may be done directly between peers or via an entity representing a group of SIP service providers. Today, in some VoIP networks, this information is often exchanged in a static manner using email and spreadsheets. Figure 1 illustrates how telephone numbers may be grouped logically into service areas (which may not necessarily be based on geographical boundaries). It also shows how each service area may be reachable via signaling path border elements. Service Areas: +------------------------------------+ |Service Area Name| TN or TN Ranges | +-----------------+------------------+ |Manhattan |212-203-0000 -> | | |212-203-9999 | ,---. |Bronx |347-876-1000 -> | / \ | |347-876-1999 | / \ |Queens |347-354-6000 -> | ( Bronx ) | |347-354-6999 | \ / +------------------------------------+ ,-----. \ / Routes: / \ `---' +------------------------------------+ / \ |Route Name|Nodes |Service Areas | ( Manhattan ) ,---. +----------+---------+---------------+ ,-. / / \ |118th Ave |NYC-SBE-1|Manhattan/Bronx|-->(SBE) / / \ |60 Hudson |NYC-SBE-2|Queens |-+ `-'-----' ( Queens ) +----------+--------++---------------+ | ,+. / +------------>(SBE) / Nodes: `-''---' +-----------------------------------+ |Node Name| Host/Domain Name | +---------+-------------------------+ |NYC-SBE-1|sbe-1.nyc-sp1.example.com| |NYC-SBE-2|sbe-2.nyc-sp2.example.com| +---------+-------------------------+ Figure 1: Protocol Data Elements Creighton & Mule Expires August 21, 2008 [Page 6] Internet-Draft espp-requirements February 2008 3.2. File-based Distribution and Bootstrapping The process of downloading large quantities of data to an ENUM-SIP addressing server should be carried out as quickly as possible with minimum resources. It involves the generation and transfer of a bulk file between the client and server. It may be used in cases where the loading a newly commissioned ENUM-SIP addressing server or reloading an existing server data due to a complete shutdown or loss of memory has occurred. For example, a SIP service provider has decided to opt into a federation of service providers that collectively service over one hundred million (100M) subscribers, choosing to establish interconnections with every member of the federation. Once commissioned the operator's ENUM-SIP addressing server needs to immediately receive with all 100M registered telephone numbers (TNs). Rather than stream the 100M TNs over a network connection in real- time, the administrator of the federation registry and operator choose to utilize the file-based distribution mechanism (as described in [I-D.espp-protocol]). 3.3. Backward Compatibility to Legacy Switch Translations The underlying data schema used to provision ENUM-SIP addressing servers should be backward compatible with today's VoIP server translations and legacy PSTN. This requirement arises from the fact that some SIP service providers may wish to utilize the same number translation data employed by their SIP servers or Call Management Servers (CMS). For example, a SIP service provider's switch translation personnel, who are responsible for managing CMS translations, are given responsibility for managing the operator's ENUM data. Rather than provisioning complete 10-digit numbers to a peer's ENUM server some may choose to provision Location Routing Numbers (LRNs). This decision is, in large part, due to the fact that, in some networks, the trunk selection algorithm of the operator's CMS are based on LRNs (NPA-NXX). The switch translation personnel choose to reuse LRNs rather than taking responsibility for keeping a complete set of the operator's numbers up to date. Creighton & Mule Expires August 21, 2008 [Page 7] Internet-Draft espp-requirements February 2008 4. Protocol Requirements This section describes the high-level requirements for the ENUM-SIP server provisioning protocol. 4.1. Connection-Oriented Operation o The protocol MUST support a file-based, bulk delivery mechanism where the ESPP Client writes one or more update requests to one or more files and the file(s) are delivered to and consumed by the ESPP Server. o All ESPP Clients and Servers MUST use HTTP 1.1 as defined in [RFC2616] for the transport mechanism. o All ESPP Clients and Servers SHOULD support HTTP Keep-Alive to allow long lived connections, where multiple request and response pairs are exchanged across a single network connection. 4.2. File Oriented Operation o The protocol MUST support a file-based mechanism (bulk load) where the ESPP Client writes one or more requests to a file and the file is delivered to and consumed by the ESPP Server. o The delivery or transmission of bulk files MAY be triggered by a manual process out-of-band of the protocol. o During bulk loading the ESPP Server SHOULD NOT accept new records through the real-time, connection-oriented interface. o The maximum size of a bulk load file MUST NOT exceed 500 MB. o The name of a bulk file SHOULD identify the ESPP Client, ESPP Server, file sequence number, and transaction ID(s) for which the bulk file was generated. o The bulk load interface MUST be capable of supporting the download of an entire address space of the order of the PSTN. o The format of the bulk load file MUST be compatible with the XML definitions of the real-time interface. o The ESPP Server MUST maintain an error log that identifies transactions that resulted in an error when being applied to the database of the ESPP Server. The errors codes of the bulk load interface SHOULD comply with the error codes of the real-time interface. Creighton & Mule Expires August 21, 2008 [Page 8] Internet-Draft espp-requirements February 2008 4.3. Security Requirements: Authentication, Integrity and Confidentiality o All ESPP Clients and Servers MUST support Transport Layer Security (TLS) as defined in [RFC4346] as the secure transport mechanism. o All ESPP Clients and Servers MUST use HTTP Digest Authentication as defined in [RFC2617] as the secure authentication mechanism. o Transfer of bulk files MUST use Secure Copy (SCP), which relies on Secure Shell (SSH) for security, as the secure file transport mechanism. 4.4. Data Model Requirements o The protocol MUST be capable of supporting a large addressing space. For example, if the provisioned data involves telephone numbers, the protocol must be capable of supporting an addressing space of the same magnitude as the PSTN. o The protocol's data model SHOULD provide means to logically group public identities into Service Areas and associate Routes to Service Areas. 4.5. Data Presentation Requirements o The protocol MUST utilize SOAP 1.1 [SOAP], WSDL1.1 [WSDL], and XML 1.0 [XML]. o The protocol MUST support efficient transportation of a large number of data model objects from the client to the server. 4.6. Protocol Operations o The protocol MUST support the ability to add, modify, and delete the objects defined in the protocol data model. o The protocol MUST support the ability to query for a specific instance of each type of object defined in the data model by using the object identifier. o The protocol MUST support the ability for multiple ESPP Clients to provision objects into the same ESPP Server. o The protocol MUST support the ability for ESPP objects created by one ESPP Client to refer to ESPP objects created by another ESPP Client. Creighton & Mule Expires August 21, 2008 [Page 9] Internet-Draft espp-requirements February 2008 4.7. Versioning, Capability Exchange, and Extensibility Requirements o The protocol MUST support schema versioning such that major version changes are defined as any change that breaks backward compatibility and minor version changes are defined as any change that does not break backward compatibility. o The protocol MUST allow, but not require, a server to expose multiple concurrent major versions and/or minor versions of the protocol concurrently. o The protocol MUST make the major version identification of a request message detectable by schema validation and the minor version identification of a request message detectable by the application. o The protocol MUST be extensible such that new operations and objects can be added to the protocol in a systematic manner. Creighton & Mule Expires August 21, 2008 [Page 10] Internet-Draft espp-requirements February 2008 5. Security Considerations Provisioning data and other configuration information in scope of this ENUM-SIP Server Provisioning protocol include public identities, telephone number ranges, signaling path border elements and NAPTRs. This information is sensitive and its transmission in the clear and without integrity checking leaves servers exposed to eavesdropping attacks. If the object values such as TNs, Routes, or Service Areas are set maliciously, it may result in sessions being misrouted or an over- allocation of signaling resources in an attempt to create denial of service attacks. An initial set of security requirements for such a provisioning protocol are defined in Section 4.3. Creighton & Mule Expires August 21, 2008 [Page 11] Internet-Draft espp-requirements February 2008 6. Acknowledgments This document is based on the work of participants in the CableLabs PacketCable ENUM Server vendor focus team. The authors wish to thank the following participants for their contributions and efforts: Jack Burton, Paul Natale, Costas Gavrilidis, Matt Cannon, Ken Cartwright, Kevin Johns, James Brister, Ted Lemon, Vivian Neou, Mark McBride, Tim Cody, Sean Leach, Gene Lew, Rich Shockey, Mark Teodoro, Robby Benedyk, Steve Dimig, , Ajay Gupta, Sean Kent, Tom Kershaw, Manjul Maharishi, Yasir Saleem, Sanjeev Chauhan, Gaurav Sharma, Vikas Sarawat, Daryl Malas and Sumanth Channabasappa. Creighton & Mule Expires August 21, 2008 [Page 12] Internet-Draft espp-requirements February 2008 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [CableLabs-ESPP] CableLabs, "PacketCable ENUM Server Provisioning Specification, PKT-SP-ENUM-PROV-I01-080215", February 2008. [I-D.espp-protocol] Cartwright, K., Dimig, S., Teodoro, M., and J-F. Mule, "ENUM-SIP Server Provisioning Protocol (ESPP)", draft-mule-peppermint-espp-protocol-00.txt (work in progress), February 2008. [I-D.ietf-speermint-terminology] Meyer, R. and D. Malas, "SPEERMINT Terminology", draft-ietf-speermint-terminology-16.txt (work in progress), February 2008. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [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. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [SOAP] W3C, "W3C Recommendation, SOAP Version 1.1", May 2000. Creighton & Mule Expires August 21, 2008 [Page 13] Internet-Draft espp-requirements February 2008 [WSDL] W3C, "W3C Recommendation, Web Services Description Language (WSDL) Version 1.1", March 2001. [XML] W3C, "W3C Recommendation, Extensible Markup Language (XML) 1.0", August 2006. Creighton & Mule Expires August 21, 2008 [Page 14] Internet-Draft espp-requirements February 2008 Authors' Addresses Tom Creighton Comcast Cable Communications One Comcast Center Philadelphia, PA 19103 USA Email: tom_creighton@cable.comcast.com Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: jfm@cablelabs.com Creighton & Mule Expires August 21, 2008 [Page 15] Internet-Draft espp-requirements February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Creighton & Mule Expires August 21, 2008 [Page 16]