DEFENSE INFORMATION SYSTEMS AGENCY P. O. BOX 549 FORT MEADE, MARYLAND Joint Interoperability Test Command (JTE) 22 Jan 13

Transcription

1 DEFENSE INFORMATION SYSTEMS AGENCY P. O. BOX 549 FORT MEADE, MARYLAND IN REPLY REFER TO: Joint Interoperability Test Command (JTE) 22 Jan 13 MEMORANDUM FOR DISTRIBUTION SUBJECT: Joint Interoperability Certification of the RedSky E911 Manager with Release References: (a) DoD Directive , Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS), 5 May 2004 (b) Department of Defense Instruction , "DoD Unified Capabilities (UC)," 9 December 2010 (c) through (e), see Enclosure 1 1. References (a) and (b) establish Defense Information Security Agency (DISA), Joint Interoperability Test Command (JITC), as the responsible organization for interoperability test certification. 2. The RedSky E911 Manager with Release is hereinafter referred to as the System Under Test (SUT). The SUT meets all of its critical interoperability requirements and is therefore certified for joint use within the Defense Information Systems Network (DISN) as an E911 Management System specifically with the Cisco Unified Communications Manager (CUCM). The SUT was tested and certified with one E911 Manager server that interfaced to the CUCM version 8.0(2) Local Session Controller (LSC). JITC analysis determined the SUT is also certified with two servers when one of them is configured for backup operations. Additionally, the SUT is certified with any CUCM LSC or Cisco Private Branch Exchange 1 (PBX1) on the Unified Capabilities (UC) Approved Products List (APL). The SUT met the critical interoperability requirements set forth in Reference (c), using test procedures derived from Reference (d). No other configurations, features, or functions, except those cited within this memorandum, are certified by JITC. This certification expires upon changes that could affect interoperability, but no later than three years from the date of this memorandum. 3. This finding is based on interoperability testing conducted by Telecommunication Systems Security Assessment Program (TSSAP), review of the vendor's Letters of Compliance (LoC), and DISA Certifying Authority (CA) Recommendation of the Information Assurance (IA) configuration. Interoperability testing was conducted by TSSAP, San Antonio, Texas, from 11 through 22 June Additional interoperability testing was conducted by TSSAP, San Antonio, Texas, from 1 through 5 October Review of the vendor s LoC was completed on 12 July The DISA CA provided a positive recommendation on 30 November 2012 based on the security testing completed by DISA-led IA test teams and published in a separate report, Reference (e). The acquiring agency or site will be responsible for the DoD Information Assurance Certification and Accreditation Process (DIACAP) accreditation. Enclosure 2 documents the test results and describes the tested network and system configurations including specified patch releases.

2 JITC Memo, JTE, Joint Interoperability Certification of the RedSky E911 Manager with Release The interface, Capability Requirement (CR) and Functional Requirement (FR), and component status of the SUT are listed in Tables 1 and 2. The threshold CR/FRs for E911 Manager Systems is established by Section of Reference (c) and was used to evaluate the interoperability of the SUT. Enclosure 3 provides a detailed list of the interface, capability, and functional requirements. Interface Critical Table 1. SUT Interface Interoperability Status UCR Reference 10Base-X Yes Certified 100Base-X Yes Certified 1000Base-X No Certified Threshold CR/FR (See note.) Status Remarks E911 Management System The SUT met all critical CRs and FRs for the IEEE 802.3i (10BaseT) interface. The SUT met all critical CRs and FRs for the IEEE 802.3u (100BaseT) interface. The SUT met all critical CRs and FRs for the IEEE 802.3ab (1000BaseT) interface. NOTE: The SUT high-level CR and FR ID numbers depicted in the Threshold CRs/FRs column can be cross-referenced in Table 2. These high-level CR/FR requirements refer to a detailed list of requirements provided in Enclosure ab 1000BaseT Gbps Ethernet over twisted pair at 1 Gbps (125 Mbps) 802.3i 10BaseT Mbps over twisted pair 802.3u Standard For Carrier Sense Multiple Access With Collision Detection At 100 Mbps CR Capability Requirement FR Gbps IEEE Mbps SUT UCR Functional Requirement Gigabits per second Institute of Electrical and Electronics Engineers Megabits per second System Under Test Unified Capabilities Requirements Table 2. SUT CRs and FRs Status CR/FR ID Capability/Function Applicability 1 UCR Reference Status Product Interface Requirements Interfaces to LSC Required Met Proprietary Signaling Interface to LSC Conditional Met 2 Standardized Signaling Interface to LSC Conditional Not Tested E911 Management System Requirements Maintain location data and ELINs Required Met Maintain data items required by ALI databases Required Met Export ALI data to required standardized formats Required Met 3 Export ALI data to required proprietary format Conditional Not Tested Export ALI data as scheduled, by event, or as requested Required Met EI registration Required Met Provide LSC with ELIN when queried Required Met 911 notification to non-psap Conditional Met Read, add, delete, modify ERL/ELIN entries Required Met Authentication to LSC Required Met Transfer of ALI data to target ALI database Conditional Not Tested IPv6 Requirements IPv6 Dual Stack Required Met IPv6 Protocol Required Met Information Assurance Requirements DISA STIGs Required Met 4 2

3 JITC Memo, JTE, Joint Interoperability Certification of the RedSky E911 Manager with Release Table 2. SUT CRs and FRs Status (continued) NOTES: 1. The annotation of required refers to a high-level requirement category. The applicability of each sub-requirement is provided in Enclosure 3. The SUT does not need to provide conditional requirements. However, if a capability is provided, it must function according to the specified requirements. 2. The SUT was tested to interface with the CUCM Version 8.0(2) using JTAPI and AXL. 3. The SUT complies with NENA Version 2.1 format. 4. Security is tested by Department of Defense component lab-led Information Assurance test teams and the results published in a separate report, Reference (e). ALI AXL CR CUCM DISA EI ELIN ERL FR Automatic Line Identification Administrative XML Layer Capability Requirement Cisco Unified Communications Manager Defense Information Systems Agency End Instrument Emergency Location Identification Number Emergency Response Location Functional Requirement ID Identification IPv6 Internet Protocol version 6 LSC Local Session Controller JTAPI Java Telephony Application Programming Interface NENA National Emergency Number Association PSAP Public Safety Answering Point STIGs Security Technical Implementation Guides SUT System Under Test UCR Unified Capabilities Requirements 5. No detailed test report was developed in accordance with the Program Manager s request. JITC distributes interoperability information via the JITC Electronic Report Distribution (ERD) system, which uses Unclassified-But-Sensitive Internet Protocol Router Network (NIPRNet) e- mail. More comprehensive interoperability status information is available via the JITC System Tracking Program (STP). STP is accessible by.mil/gov users on the NIPRNet at Test reports, lessons learned, and related testing documents and references are on the JITC Joint Interoperability Tool (JIT) at (NIPRNet). Information related to DSN testing is on the Telecom Switched Services Interoperability (TSSI) website at Due to the sensitivity of the information, the Information Assurance Accreditation Package (IAAP) that contains the approved configuration and deployment guide must be requested directly through government civilian or uniformed military personnel from the Unified Capabilities Certification Office (UCCO), disa.meade.ns.list.unified-capabilities-certification-office@mail.mil. All associated data is available on the DISA UCCO website located at 6. The JITC point of contact is CPT James Torres, DSN , commercial (520) , FAX DSN , or to james.m.torres.mil@mail.mil. JITC s mailing address is P.O. Box 12798, Fort Huachuca, AZ The UCCO tracking number for the SUT is FOR THE COMMANDER: 3 Enclosures a/s for BRADLEY A. CLARK Acting Chief Battlespace Communications Portfolio 3

4 JITC Memo, JTE, Joint Interoperability Certification of the RedSky E911 Manager with Release Distribution (electronic mail): DoD CIO Joint Staff J-6, JCS USD(AT&L) ISG Secretariat, DISA, JTA U.S. Strategic Command, J665 US Navy, OPNAV N2/N6FP12 US Army, DA-OSA, CIO/G-6 ASA(ALT), SAIS-IOQ US Air Force, A3CNN/A6CNN US Marine Corps, MARCORSYSCOM, SIAT, A&CE Division US Coast Guard, CG-64 DISA/TEMC DIA, Office of the Acquisition Executive NSG Interoperability Assessment Team DOT&E, Netcentric Systems and Naval Warfare Medical Health Systems, JMIS IV&V HQUSAISEC, AMSEL-IE-IS UCCO 4

5 ADDITIONAL REFERENCES (c) Office of the Assistant Secretary of Defense, Department of Defense Unified Capabilities Requirements 2008, Change 3, September 2011 (d) Joint Interoperability Test Command, Unified Capabilities E911 Test Plan, Draft (e) Telecommunication Systems Security Assessment Program, Information Assurance (IA) Assessment Report RedSky E911 Manager Release (TN# ), Draft Enclosure 1

6 CERTIFICATION TESTING SUMMARY 1. SYSTEM TITLE. The RedSky E911 Manager with Release 6.3.1; hereinafter referred to as the System Under Test (SUT). 2. SPONSOR. Air Combat Command, Communications Directorate (ACC/A6), Mr. William E. Marion, Langley Air Force Base, Virginia, 3. SYSTEM POC. Mr. Jerry Eisner, 925 West Chicago Ave., Suite 300, Chicago, Illinois 60642, 4. TESTER. Telecommunication Systems Security Assessment Program (TSSAP), Lackland Air Force Base, Texas SYSTEM DESCRIPTION. The SUT is an adjunct device that communicates with Voice over Internet Protocol (VoIP) Enterprise Call Servers for the purpose of providing device specific location information in the event that a user calls The SUT substitutes the Calling Party Number with an Emergency Line Identification Number (ELIN) that represents the actual location of the device to enterprise connection point. The E911 Manager provides batch updates of these locations to the Automatic Location Information (ALI) database operated by either a Local Exchange Carrier (LEC) or private entity, i.e. standalone ALI database or military base. The SUT also provides real time location information for devices that connect dynamically to the Enterprise, including VoIP phones, Wireless Fidelity (Wi-Fi) phones, and Virtual Private Network (VPN) soft-phone clients. The SUT was tested with the Cisco Unified Communications Manager (CUCM) version 8.0(2) Local Session Controller (LSC). However, based on JITC analysis, the SUT is also certified with any CUCM LSC or Cisco Private Branch Exchange 1 (PBX1) on the Unified Capabilities (UC) Approved Products List (APL). The SUT consists of a RedSky E911 Manager server and the RedSky Emergency On- Site Notification (EON) Client. The RedSky E911 Manager is the primary component in the SUT. The primary function of the RedSky E911 Manager is to correlate up to date accurate location information with a telephone attached to a VoIP enterprise call server or PBX system for the purpose of providing automated updates to a 911 ALI database. Location information is derived manually, uploaded from external databases, or through network discovery. The secondary function is to provide a notification, which includes the device identification and the location of the caller every time a call to 911 is made. The solution is designed to be deployed with two, redundant RedSky E911 Manager servers. The SUT was tested and certified with one E911 Manager server. JITC analysis determined the SUT is certified with either one or two E911 Manager servers. The primary function of the RedSky EON Client is to receive a notification that a telephone device connected to the VoIP enterprise call server or Time Division Multiplexed (TDM) PBX system has dialed and to display the device identification and location information in order to either initiate or facilitate the appropriate Public Safety emergency response. Enclosure 2

7 6. OPERATIONAL ARCHITECTURE. Figure 2-1 depicts the Defense Information Systems Network (DISN) Unified Capabilities notional operational architecture that the SUT may be used in. ALI Automatic Line Identification ASLAN Assured Services Local Area Network B/P/C/S Base/Post/Camp/Station CER Customer Edge Router DISN Defense Information Systems Network E-911 Enhanced 911 IAP Internet Access Point LSC Local Session Controller NIPRNet Unclassified-but-Sensitive Internet Protocol Router Network PSAP Public Safety Answering Point PSTN Public Switched Telephone Network UC Unified Capabilities Figure 2-1. E911 Management System Notional Architecture for UC E911 Services 7. INTEROPERABILITY REQUIREMENTS. The interface, Capability Requirements (CR) and Functional Requirements (FR) for E911 Management Systems are established by Section of Reference (c). 7.1 Interfaces. The SUT uses the interfaces shown in Table 2-1 to connect to the Global Information Grid network. This table shows the physical interfaces supported by the SUT and the associated standards. 2-2

8 Table 2-1. E911 Manager Interface Requirements Interface Critical UCR Reference Criteria 10Base-X Yes Base-X Yes Base-X No ab 1000BaseT Gbps Ethernet over twisted pair at 1 Gbps (125 Mbps) 802.3i 10BaseT Mbps over twisted pair 802.3u Standard For Carrier Sense Multiple Access With Collision Detection At 100 Mbps CR Capability Requirement FR Gbps IEEE Mbps SUT UCR Support minimum threshold CRs/FRs (1-4) and meet interface criteria for IEEE 802.3i. Support minimum threshold CRs/FRs (1-4) and meet interface criteria for IEEE802.3u. Support minimum threshold CRs/FRs (1-4) and meet interface criteria for IEEE 802.3ab. Functional Requirement Gigabits per second Institute of Electrical and Electronics Engineers Megabits per second System Under Test Unified Capabilities Requirements 7.2 CR and FR. E911 Management Systems have required and conditional features and capabilities that are established by Section of the UCR 2008 Change 3. The SUT does not need to provide non-critical (conditional) requirements. If they are provided, they must function according to the specified requirements in order to be certified for that capability. The SUT s features and capabilities and its aggregated requirements in accordance with E911 Management Systems requirements are listed in Table 2-2. Detailed CR/FR requirements are provided in Table 3-1 of Enclosure 3. Table 2-2. E911 Management System CRs and FRs CR/FR ID Capability/Function Applicability (See note.) UCR Reference Product Interface Requirements Interfaces to LSC Required Proprietary Signaling Interface to LSC Conditional Standardized Signaling Interface to LSC Conditional E911 Management System Requirements Maintain location data and ELINs Required Maintain data items required by ALI databases Required Export ALI data to required standardized formats Required Export ALI data to required proprietary format Conditional Export ALI data as scheduled, by event, or as requested Required EI registration Required Provide LSC with ELIN when queried Required notification to non-psap Conditional Read, add, delete, modify ERL/ELIN entries Required Authentication to LSC Required Transfer of ALI data to target ALI database Conditional IPv6 Requirements IPv6 Dual Stack Required IPv6 Protocol Required Information Assurance Requirements DISA STIGs Required

9 Table 2-2. E911 Management System CRs and FRs (continued) NOTE: The annotation of required refers to a high-level requirement category. The applicability of each sub-requirement is provided in Enclosure 3. The SUT does not need to provide conditional requirements. However, if a capability is provided, it must function according to the specified requirements. ALI CR DISA EI ELIN ERL FR Automatic Line Identification Capability Requirement Defense Information Systems Agency End Instrument Emergency Location Identification Number Emergency Response Location Functional Requirement ID Identification IPv6 Internet Protocol version 6 LSC Local Session Controller PSAP Public Safety Answering Point STIGs Security Technical Implementation Guides SUT System Under Test UCR Unified Capabilities Requirements 7.3 Information Assurance (IA). Table 2-3 details the IA requirements applicable to the E911 Management Systems products. Table 2-3. E911 Management Systems IA Requirements (NOTE) UCR Requirement Applicability Reference General Requirements Required Authentication Required Integrity Required Confidentiality Required Non-Repudiation Required Availability Required Criteria Detailed requirements and associated criteria for E911 Management Systems are listed in Reference (e). NOTE: The annotation of Required refers to a high-level requirement category of IA requirements from the UCR 2008, Change 3, Section 5.4. The detailed IA requirements are included in Reference (e). E911 Enhanced 911 IA Information Assurance UCR Unified Capabilities Requirements 7.4 Other. None 8. TEST NETWORK DESCRIPTION. The SUT was tested at Telecommunication Systems Security Assessment Program in a manner and configuration similar to that of an operational environment. Testing the SUT s required functions and features was conducted using the test configuration depicted in Figure

10 ALI Automatic Line Information ASLAN Assured Services Local Area Network E911 Enhanced 911 EON Emergency On-Site Notification IP LSC SUT Internet Protocol Local Session Controller System Under Test Figure 2-2. SUT Test Configuration with Cisco LSC 9. SYSTEM CONFIGURATIONS. Table 2-4 provides the system configurations and hardware and software components tested with the SUT. The SUT was tested in an operationally realistic environment to determine its interoperability capability with associated network devices and network traffic. 2-5

11 Table 2-4. Tested System Configurations System Name Software Cisco Catalyst 3750 Switch IOS Software Version 12.2(55) Cisco 3845 IOS Software Version 15.1(3)T Cisco Unified Communications Manager Software Version 8.0(2) Equipment Active Directory (Microsoft Windows Server 2008) SysLog Server (Kiwi SysLog Server 9.2) Required Ancillary Equipment Management Workstation (site-provided) LDAP Server (Microsoft Windows Server 2008) Public-Key Infrastructure System Under Test Part Number Software/Firmware RedSky E911 Manager (See note.) 4PDL320G5P E911 Manager EON Client Not Applicable RedSky EON 5.6 Software, Microsoft Windows XP or later NOTE: The SUT solution is designed to be deployed with two, redundant RedSky E911 Manager servers. The SUT was tested and certified with one E911 Manager server. JITC analysis determined the SUT is certified with either one or two E911 Manager servers. E911 Enhanced 911 EON Emergency On-Site Notification IOS LDAP Internetwork Operating System Lightweight Directory Access Protocol 10. TESTING LIMITATIONS. None. 11. INTEROPERABILITY EVALUATION RESULTS. The SUT meets the critical interoperability requirements for an E911 Management System in accordance with UCR 2008, Change 3, section The SUT is certified with any CUCM LSC or PBX1 on the UC APL. Additional discussion regarding specific testing results is located in subsequent paragraphs Interfaces. The interface status of the SUT is provided in Table 2-5. Table 2-5. SUT Interface Interoperability Status UCR Threshold Interface Critical (See note.) Status Remarks Reference CR/FR E911 Management System The SUT met all critical CRs and FRs for 10Base-X Yes Certified the IEEE 802.3i (10BaseT) interface. The SUT met all critical CRs and FRs for 100Base-X Yes Certified the IEEE 802.3u (100BaseT) interface. The SUT met all critical CRs and FRs for 1000Base-X No Certified the IEEE 802.3ab (1000BaseT) interface. NOTE: The SUT high-level CR and FR ID numbers depicted in the Threshold CRs/FRs column can be cross-referenced in Table 2-6. These high-level CR/FR requirements refer to a detailed list of requirements provided in Enclosure ab 1000BaseT Gbps Ethernet over twisted pair at 1 Gbps (125 Mbps) 802.3i 10BaseT Mbps over twisted pair 802.3u Standard For Carrier Sense Multiple Access With Collision Detection At 100 Mbps CR Capability Requirement FR Gbps IEEE Mbps SUT UCR Functional Requirement Gigabits per second Institute of Electrical and Electronics Engineers Megabits per second System Under Test Unified Capabilities Requirements 2-6

12 11.2 CR and FR. The SUT CR and FR status is depicted in Table 2-6. Detailed CR/FR requirements are provided in Enclosure 3, Table 3-1. Table 2-6. SUT CR and FR Status CR/FR ID Capability/Function Applicability 1 UCR Reference Status Product Interface Requirements Interfaces to LSC Required Met Proprietary Signaling Interface to LSC Conditional Met 2 Standardized Signaling Interface to LSC Conditional Not Tested E911 Management System Requirements Maintain location data and ELINs Required Met Maintain data items required by ALI databases Required Met Export ALI data to required standardized formats Required Met 3 Export ALI data to required proprietary format Conditional Not Tested Export ALI data as scheduled, by event, or as requested Required Met EI registration Required Met Provide LSC with ELIN when queried Required Met 911 notification to non-psap Conditional Met Read, add, delete, modify ERL/ELIN entries Required Met Authentication to LSC Required Met Transfer of ALI data to target ALI database Conditional Not Tested IPv6 Requirements IPv6 Dual Stack Required Met IPv6 Protocol Required Met Information Assurance Requirements DISA STIGs Required Met 4 NOTES: 1. The annotation of required refers to a high-level requirement category. The applicability of each sub-requirement is provided in Enclosure 3. The SUT does not need to provide conditional requirements. However, if a capability is provided, it must function according to the specified requirements. 2. The SUT was tested to interface with the CUCM Version 8.0(2) using JTAPI and AXL. 3. The SUT complies with NENA Version 2.1 format. 4. Security is tested by Department of Defense component lab-led Information Assurance test teams and the results published in a separate report, Reference (e). ALI AXL CR CUCM DISA EI ELIN ERL FR Automatic Line Identification Administrative XML Layer Capability Requirement Cisco Unified Communications Manager Defense Information Systems Agency End Instrument Emergency Location Identification Number Emergency Response Location Functional Requirement ID Identification IPv6 Internet Protocol version 6 JTAPI Java Telephony Application Programming Interface LSC Local Session Controller NENA National Emergency Number Association PSAP Public Safety Answering Point STIGs Security Technical Implementation Guides SUT System Under Test UCR Unified Capabilities Requirements a. Product Interface Requirements (1) Interfaces to the LSC. The UCR 2008, Change 3, section , states that the E911 Management System shall support signaling interfaces to UC LSC 2-7

13 products from at least two different vendors, and shall use these interfaces for signaling with those LSCs for End Instrument (EI) registrations and processing of 911 calls from EIs. A system that only interoperates with a single LSC can be certified as part of the LSC, but since it has not demonstrated multivendor interoperability it cannot be certified as a standalone product. The SUT met the requirement for a system that can only interoperate with a single LSC with both testing and providing the vendor s Letters of Compliance (LoC). The SUT interfaced with the CUCM Release 8.0(2). (a) If the UC LSC product supports a proprietary signaling interface for E911 Management System interconnection, the E911 Management System shall support that interface, per the LSC vendor s proprietary interface specifications. The SUT met this requirement with both testing and the vendor s LoC. The SUT interfaced with the CUCM Release 8.0(2) using Java Telephony Application Programming Interface (JTAPI) and Automated XML Layer (AXL). (b) If the UC LSC product supports a standardized signaling interface for E911 Management System interconnection, the E911 Management System shall support that interface, per standardized interface specifications identified by the LSC vendor. This requirement is conditional, was not tested, therefore, is not certified for use. (2) The UCR 2008, Change 3, section , states that LSCs are not required to support interfaces to standalone E911 Management Systems. The burden is on the E911 solution to interface to the LSC. The SUT met this requirement with both testing and the vendor s LoC. b. E911 Management System Requirements (1) The UCR 2008, Change 3, section , states that the E911 Management System shall maintain, for each LSC to which it interfaces, an appropriate set of location data, and corresponding ELINs, that identify the physical locations of each of the EIs served by the LSC. Each record in an ALI database is assumed to include, at a minimum, a location - comprised of a street address and Emergency Response Location (ERL) - and an associated Emergency Location Identification Number (ELIN). An ERL identifies a specific physical location, area or zone at the street address to which an emergency responder can be sent, e.g., the northeast quadrant of the third floor. An ELIN is a 10-digit telephone number that uniquely identifies the location (i.e., each ELIN is associated with one and only location). The SUT met this requirement with testing. (2) The UCR 2008, Change 3, section , states that the E911 Management System shall also maintain any additional data items required by the ALI databases supporting the Public Safety Answering Points (PSAPs) serving the Base/Post/Camp/Station (B/P/C/S) or enclave. These PSAPs are responsible for handling 911 calls from the EIs served by the LSCs to which the E911 Management System interfaces. The SUT met this requirement with vendor LoC. 2-8

14 (3) The UCR 2008, Change 3, section , states that the E911 Management System shall also maintain any additional data items required by the ALI databases supporting the PSAPs serving the B/P/C/S or enclave. These PSAPs are responsible for handling 911 calls from the EIs served by the LSCs to which the E911 Management System interfaces. Sources for the ALI data maintained by the E911 Management System may include the LSCs with which it interfaces, LSC service provisioning systems and direct manual entry. The SUT met this requirement with testing. (4) The UCR 2008, Change 3, section , states that the E911 Management System shall be capable of exporting, to a file, ALI data in.csv or National Emergency Number Association (NENA) Version 2.0, or later, formats. The SUT met this requirement with both testing and the vendor s LoC. The SUT complies with NENA Version 2.1 format (a) If the B/P/C/S or enclave requires ALI data to be provided in a proprietary format, the E911 Management System shall be capable of exporting, to a file, the ALI data in the required proprietary format. This conditional requirement was not tested; therefore, is not covered under this certification. (b) If the E911 Management System supports direct, secure electronic transfer of ALI data to a target ALI database (or to an intermediary application or service that in turn updates the ALI database), and the B/P/C/S or enclave supports and allows such a transfer, a direct electronic export of ALI data may be made in lieu of exporting the data to a file. The SUT met this requirement with testing. (5) The UCR 2008, Change 3, section , states that the E911 Management System shall be capable of exporting ALI data as depicted in the subparagraphs below. testing. (a) On a periodic, scheduled basis. The SUT met this requirement with (b) In response to a configurable event (i.e. the creation of a new ERL and ELIN in the system). The SUT met this requirement with testing. (c) In response to an administrator s request, on an ad hoc basis. The SUT met this requirement with testing. (6) The UCR 2008, Change 3, section , states that when notified by an LSC of an EI registration, the E911 Management System shall: (a) Determine the physical location of the EI, based on Internet Protocol (IP) address assigned to the EI and any additional information provided by the LSC at registration notification. This SUT met this requirement with testing. 2-9

15 (b) Determine the ERL assigned to that location. The SUT met this requirement with testing. (c) Keep an internal record of the EI registration that includes the ELIN for the ERL assigned to the EI s location. The SUT met this requirement with testing. (d) Acknowledge receipt of the registration notification to the LSC, and include the EI s ELIN in that acknowledgement. The SUT met this requirement with testing. (7) The UCR 2008, Change 3, section , states that when queried by an LSC processing a 911 call from a registered EI, the E911 Management System shall provide the LSC with the ELIN associated with that EI in its internal record. The SUT met this requirement with both testing and the vendor s LoC. (8) The UCR 2008, Change 3, section , states that if the E911 Management System supports notification of a 911 call to a configurable entity within the B/P/C/S or enclave other than a PSAP, such as a front desk or security command center, and the LSCs to which the E911 Management System interfaces support notifying the E911 Management System when processing a 911 call, the E911 Management System shall provide a notification message to a configured non-psap entity when a 911 call is made. Allowed notification methods include automated voice call, , and text messaging. The SUT met this requirement with testing to the EON client. (9) The UCR 2008, Change 3, section , states that the E911 Management System shall meet IPv6 in accordance with UCR 2008, Change 3, section The E911 Management System shall meet all of the IPv6 protocol requirements for Network Appliances and Simple Servers (NA/SS) products in Section 5.3.5, including the requirements in Table The SUT met this requirement with testing and the vendor s LoC Information Assurance. Security is tested by Department of Defense component lab-led Information Assurance test teams and the results published in a separate report, Reference (e) Other. None 12. TEST AND ANALYSIS REPORT. No detailed test report was developed in accordance with the Program Manager s request. JITC distributes interoperability information via the JITC Electronic Report Distribution (ERD) system, which uses Unclassified-But-Sensitive Internet Protocol Router Network (NIPRNet) . More comprehensive interoperability status information is available via the JITC System Tracking Program (STP). STP is accessible by.mil/gov users on the NIPRNet at Test reports, lessons learned, and related testing documents 2-10

16 and references are on the JITC Joint Interoperability Tool (JIT) at (NIPRNet). Information related to DSN testing is on the Telecom Switched Services Interoperability (TSSI) website at Due to the sensitivity of the information, the Information Assurance Accreditation Package (IAAP) that contains the approved configuration and deployment guide must be requested directly through government civilian or uniformed military personnel from the Unified Capabilities Certification Office (UCCO), All associated data is available on the DISA UCCO website located at

17 SYSTEM FUNCTIONAL AND CAPABILITY REQUIREMENTS The E911 Management Systems have required and conditional features and capabilities that are established by Section of the Unified Capabilities Requirements (UCR). The System Under Test (SUT) need not provide conditional requirements. If they are provided, they must function according to the specified requirements in order to be certified for that capability. The detailed Functional Requirements (FR) and Capability Requirements (CR) for E911 Management Systems are listed in Table 3-1. Detailed Information Assurance (IA) requirements are included in Reference (e) and are not listed below. Table 3-1. E911 Management System Capability/Functional Requirements ID Requirement The E911 Management System shall support signaling interfaces to UC LSC products from at least two different vendors, and shall use these interfaces for signaling with those LSCs for EI registrations and processing of 911 calls from EIs. NOTE: A system that only interoperates with a single LSC can be certified as part of the LSC, but since it has not demonstrated multivendor interoperability it cannot be certified as a standalone product. If the UC LSC product supports a proprietary signaling interface for E911 Management System interconnection, the E911 Management System shall support that interface, per the LSC vendor s proprietary interface specifications. If the UC LSC product supports a standardized signaling interface for E911 Management System interconnection, the E911 Management System shall support that interface, per standardized interface specifications identified by the LSC vendor. The E911 Management System shall maintain, for each LSC to which it interfaces, an appropriate set of location data, and corresponding ELINs, that identify the physical locations of each of the EIs served by the LSC. NOTE: The level of detail in the location data depends on the B/P/C/S or enclave s E911 wiremap and the approach chosen by the 911 administrator for mapping physical locations to ERLs. The E911 Management System shall also maintain any additional data items required by the ALI databases supporting the PSAPs serving the B/P/C/S or enclave. These PSAPs are responsible for handling 911 calls from the EIs served by the LSCs to which the E911 Management System interfaces. NOTE: Sources for the ALI data maintained by the E911 Management System may include the LSCs with which it interfaces, LSC service provisioning systems and direct manual entry. The E911 Management System shall be capable of exporting, to a file, ALI data in.csv or NENA Version 2.0, or later, formats. If the B/P/C/S or enclave requires ALI data be provided in a proprietary format, the E911 Management System shall be capable of exporting, to a file, the ALI data in the required proprietary format. If the E911 Management System supports direct, secure electronic transfer of ALI data to a target ALI database (or to an intermediary application or service that in turn updates the ALI database), and the B/P/C/S or enclave supports and allows such a transfer, a direct electronic export of ALI data may be made in lieu of exporting the data to a file. The E911 Management System shall be capable of exporting ALI data: 1. On a periodic, scheduled basis; 2. In response to a configurable event (i.e. the creation of a new ERL and ELIN in the system); and 3. In response to an administrator s request, on an ad hoc basis. UCR Reference Required/ Conditional R C C R R R C R Enclosure 3

18 Table 3-1. E911 Management System Capability/Functional Requirements (continued) ID Requirement When notified by an LSC of an EI registration, the E911 Management System shall: 1. Determine the physical location of the EI, based on IP address assigned to the EI and any additional information provided by the LSC at registration notification; 2. Determine the ERL assigned to that location; 3. Keep an internal record of the EI registration that includes the ELIN for the ERL assigned to the EI s location; and 4. Acknowledge receipt of the registration notification to the LSC, and include the EI s ELIN in that acknowledgement. When queried by an LSC processing a 911 call from a registered EI, the E911 Management System shall provide the LSC with the ELIN associated with that EI in its internal record. If the E911 Management System supports notification of a 911 call to a configurable entity within the B/P/C/S or enclave other than a PSAP, such as a front desk or security command center, and the LSCs to which the E911 Management System interfaces support notifying the E911 Management System when processing a 911 call, the E911 Management System shall provide a notification message to a configured non-psap entity when a 911 call is made. Allowed notification methods include automated voice call, , and text messaging. Conformant with Section 5.3.5, IPv6 Requirements, the E911 Management System shall support dual IPv4 and IPv6 stacks (i.e., support both IPv4 and IPv6 in the same IP end point) as described in RFC The E911 Management System shall meet all of the IPv6 protocol requirements for NA/SS products in Section 5.3.5, IPv6 Requirements, including the requirements in Table , UC Network Appliances and Simple Servers (NA/SS). E911 Management Systems shall meet the Information Assurance requirements of all applicable DISA STIGs. The E911 Management System shall allow an administrator to read, add, delete and modify the ERL/ELIN entries maintained in the system. The E911 Management System shall allow an administrator to configure authentication credentials so that the system can authenticate the LSCs to which it interfaces, and the LSCs can authenticate the E911 Management System. If the E911 Management System supports direct, secure electronic transfer of ALI data to a target ALI database, the E911 Management System shall allow an administrator to configure the address of an ALI database, along with authentication credentials so that the system can authenticate the ALI database, and the ALI database can authenticate the E911 Management System. Note that in this requirement target ALI database means the database proper or any intermediary application or service that, in turn, updates the target ALI database. UCR Reference Required/ Conditional R R C R R R R R C ALI Automatic Line Identification B/P/C/S Base/Post/Camp/Station C Conditional DISA Defense Information Systems Agency EI End Instrument ELIN Emergency Location Identification Number ERL Emergency Response Location ID Identification IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 LSC Local Session Controller NA Network Appliances PSAP Public Safety Answering Point R Required RFC Request for Comments SS Simple Servers STIGS Security Technical Implementation Guides UC Unified Capabilities UCR Unified Capabilities Requirements 3-2