EIS_RFP_Section_C_Amendment_12.docx

Enterprise Infrastructure Solutions (EIS) Request for Proposals

Section C Description / Specifications / Statement of Work

Issued by:

General Services Administration Office of Integrated Technology Services 1800 F St NW Washington, DC 20405

October 2015

Table of Contents

General Services Administration Network Services 2020 Enterprise Infrastructure Solutions

EIS RFP #QTA0015THA3003 Amendment 12 Enterprise Infrastructure Solutions EIS RFP #QTA0015THA3003 Amendment 12 ii Enterprise Infrastructure Solutions Appendix A Appendix B Appendix C Background The General Services Administration (GSA), Federal Acquisition Service, Integrated Technology Services (ITS), Network Services Program (NSP[footnoteRef:1]) establishes and manages a range of acquisition programs to meet the needs of federal agencies for telecommunications, networking services and associated support. [1: See http://www.gsa.gov/portal/category/22151 for background]

This Request for Proposals (RFP) describes the government’s requirements for the Enterprise Infrastructure Solutions (EIS) contract.

EIS Goals The EIS contract is intended to meet the program goals for:

Service Continuity.

Highly Competitive Prices.

High-Quality Service.

Full Service Vendors.

Operations Support.

Transition Assistance and Support.

The overarching goal for EIS is to make the resulting contracts as flexible and agile as possible to meet and satisfy the widely differing requirements of the federal agencies both now and for the next decade and beyond.

EIS Scope for Mandatory and Optional Services The EIS mandatory services include the following:

It should be noted that Access Arrangements (Section C.2.9) are included as a mandatory component and shall be priced. The contractor shall also provide Voice services to non-domestic locations as defined in Section J.1.2.

Any service included in Section C.1.8.1 that is not listed above is considered optional.

Minimum Requirements for Geographic Coverage The contractor shall provide EIS services on a global basis. Geographic coverage for domestic and non-domestic locations is specified in Section J.1. Domestic locations are further divided into CONUS and OCONUS.

CONUS Geographic requirements are defined by a set of domestic cities, based on the Core Based Statistical Areas (CBSAs) as defined in OMB Bulletin No. 13-01, dated February 28, 2013. The minimum mandatory geographic coverage area includes any 25 of the top 100 CBSAs provided by the government in Section J.1. The CBSAs listed are ranked in descending order of government bandwidth usage. It should be noted that there are over 900 CBSAs in the U.S. requiring services.

Notwithstanding the minimum requirements, the contractor is encouraged to propose the mandatory and optional services within any CBSA, OCONUS or non-domestic locations, whether included in Section J.1 or not, as long as the offer includes at least 25 of the top 100 CBSAs listed in Section J.1.

The contractor shall provide the mandatory services to all government locations within each of its selected CBSAs.

Task Orders The government will order services in accordance with FAR Subpart 16.505. Agencies will conduct fair opportunity and award task orders (TOs) in accordance with the aforementioned subpart and the terms and conditions of this contract. For more detail, see Section G.3.

Authorized Users This contract is for the use of all federal agencies, authorized federal contractors, agency-sponsored universities and laboratories, other organizations as defined in Section H.3, and, when authorized by law or regulation, state, local, and tribal governments.

Upgrades and Enhancements The government recognizes that telecommunications technologies and services are rapidly evolving. Accordingly, the government anticipates that services and solutions available under this contract will be increased, enhanced, and upgraded as these improvements become available to commercial customers.

As the virtualization of infrastructure continues from computing to networking, the government is interested in the deployment roll-out of Network Function Virtualization and Software Defined Network (NFV/SDN) in the contractor's backbone wide area network (WAN), because the SDN supports quick provisioning and easy management.

Network function virtualization (NFV) is the virtualization of network equipment functions, which typically run on dedicated appliances, to now run on industry-standard servers, switches and storage devices with the aim of lowering costs, improving efficiency and increasing agility, via hypervisor technologies. Standards are being created by the European Telecommunications Standards Institute (ETSI), including major telecom equipment vendors and communications service providers (CSPs), with involvement by the Open Networking Foundation.

Software Defined Networking (SDN) is an approach to networking in which control is decoupled from the physical infrastructure, allowing network administrators to support a network fabric across multi-vendor equipment. The SDN decouples network control and forwarding functions, enabling network control to become directly programmable and the underlying infrastructure to be abstracted from applications and network services, by supporting the following capabilities:

Transport independence by disaggregating the service from the physical network.

Security (encryption and device authentication) at the routing level.

Allow network segmentation with different segments having different encryption schemes.

Centralized policy and control of all the devices across the network.

Allow Layer 4-7 services (to be advertised) on demand.

This will allow network managers, both agency and service providers, to configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs/codes (APIs), which they can write themselves because the programs/codes do not depend on proprietary software.

Organization of this Statement of Work Section C.2 provides the technical requirements addressed by this contract. Section C.1.8 describes the general requirements and the format for the specification of the individual service areas and services, which are contained in Sections C.2.1 through C.2.12. Section C.3 contains requirements for management of transition from another expiring GSA-administered contract to EIS. Section C.4 specifies the government’s requirements for Section 508 compliance that have been established to ensure access to information and services by government employees and citizens with disabilities.

General Requirements Organization of EIS Services EIS service areas and services are presented in the following table.

Ethernet Transport Optical Wavelength Service Private Line

SONET

Dark Fiber Internet Protocol Service

Circuit Switched Voice Service Toll Free Service

CSDS

Platform as a Service Software as a Service Content Delivery Network Service

Web Conferencing Service Unified Communications Service Managed Trusted Internet Protocol Service Managed Security Service Managed Mobility Service Audio conferencing Video Teleconferencing Intrusion Prevention Security Service

IT-related products and services listed in the table above may be acquired only if they are associated to an infrastructure or telecommunications solution acquired through EIS.

Service Locations A Service Delivery Point (SDP) is the interface point at which a service is delivered by the contractor to the government or its designated agent. The SDP is the interface point for the physical or logical delivery of a service and the point at which performance parameters are measured to determine compliance with the contract.

Performance Almost all EIS services have a specified standard set of common metrics or Key Performance Indicators (KPIs) to measure and report their performance. This standard set of KPI’s measures the primary dimensions an agency needs in order to evaluate service effectiveness. The underlying KPI computations are service specific or context sensitive (as defined within each service) to reflect the broad range of service offerings and the EIS focus on delivery of end to end services. The seven standard KPIs used for most services as specified within this contract are defined below.

Standard KPIs:

For certain services, when required by agency customers, two service levels are specified. Routine service levels apply for most government applications. Critical service levels are defined for agency applications requiring higher levels of availability, performance, or restoral criteria. Critical service levels will be sought in the TO fair opportunity process. The parameters specified in the service descriptions shall apply to all domestic (both CONUS and OCONUS) services. Performance parameters for non-domestic services are specified in Section C.1.8.5. In addition, the performance provided shall always be at a level not less than what is generally available commercially, at no additional cost to the government. Thus, if the available commercial performance parameter is more demanding than the minimum acceptable level specified in this contract, the available commercial performance parameter shall take precedence.

As standards evolve, the contractor may propose and provide alternatives to the government that meet or exceed the standards listed per specific service.

Conformity to Standards Throughout Section C, references are made to standards (including interim standards, Internet Engineering Task Force (IETF) Requests for Comments (RFCs), or de-facto standards) as they existed at the time of contract award. If a standard is defined by a specific version and/or date, then that specific version of the standard shall be implemented. Otherwise, compliance with the latest versions of these standards is expected. American national standards shall supersede international standards for services to be provided to on-net users located in the U.S. Where multiple standards are cited, the order of precedence shall be the industry forum specification, followed by ANSI, followed by iconectiv, and followed by ITU-TSS, unless otherwise specified.

Non-Domestic Coverage includes delivery of service from domestic SDPs to non-domestic SDPs, from non-domestic SDPs to domestic SDPs, and from non-domestic SDPs to non-domestic SDPs. The following requirements for the numbering plan, features, performance, interfaces, security, and management and operations considerations that are applicable to the non-domestic services shall supersede the corresponding requirements specified for the domestic services:

1. Numbering Plan. The numbering plan for non-domestic locations shall conform to country-specific numbering plans.

1. Features. All features identified as mandatory in each service description shall be provided to non-domestic SDPs in the areas involved.

1. Dial-In. The contractor shall support country-specific non-domestic PSTN numbers and/or toll-free numbers, if commercially available, for dial-in access of services.

1. Performance. The KPIs in the performance metrics for each service between nondomestic SDPs or between domestic and non-domestic SDPs shall be compliant with the best commercial values or practices for those parameters within the non-domestic country and/or jurisdiction hosting the non-domestic SDPs.

1. Interfaces. When a service is delivered to an SDP at a non-domestic location, the UNI, e.g., interface type, payload data rate, protocol type, standard for the SDP shall comply with the country-specific interface standards when delivering service to the country-specific government equipment. However, if the government equipment conforms to a North American standard, then the UNI standard at the SDP shall comply with the North American standard where permitted by local law and regulations.

Interoperability The contractor shall support interoperability for given service offerings so that a user of a service from one EIS contractor shall be able to communicate with users of services from other EIS contractors with equivalent performance. GSA recognizes that different levels of interoperability exist commercially, particularly in the area of data networking. Interoperability shall be made available for any service that is currently commercially offered by the contractor and is interoperable with the services of other EIS contractors. In addition, the contractor shall make available any future service interoperability at no additional cost to GSA when the contractor offers the interoperability for its commercially provided service.

Since near full interoperability is provided via the Public Switched Telephone Network (PSTN) for circuit switched services, the contractor shall support interoperability between voice services, circuit switched data service, and wireless services if offered. The contractor shall also support connectivity and interoperability for remote and mobile users as specified in the individual service descriptions.

System Security Requirements Communications services under this contract will carry non-sensitive programmatic and administrative traffic, Controlled Unclassified Information (CUI) traffic, and higher levels of sensitive and/or classified traffic up to and including Top Secret/SCI that may be encrypted by agency users. Therefore, the contractor is required to provide basic security for all network services, as well as the network management systems and information systems and databases used to support those services. Such security shall include protecting all network services, information, contractor infrastructure, and information processing resources against threats, attacks, or failures of systems.

The contractor shall ensure that all services provided comply with all Federal Information Security Management Act (FISMA), DOD, and Intelligence Community requirements where applicable. The contractor shall submit a Risk Management Framework Plan describing its approach for security compliance for all services provided under EIS. This plan shall be submitted with the proposal in accordance with National Institute of Standards (NIST) Special Publication (SP) 800-37.

System Security Compliance Requirements In providing EIS services, the contractor shall comply with all applicable federal and agency-specific IT security directives, standards, policies, and reporting requirements. The contractor shall comply with FISMA, DOD and Intelligence Community-associated guidance and directives to include all applicable Federal Information Processing Standards (FIPS), NIST SP 800 series guidelines (FIPS and NIST SPs available at: http://csrc.nist.gov/), agency-specific security directives, policies and guides, and other appropriate government-wide laws and regulations for protection and security of government IT. In addition, the contractor shall comply with all service specific security requirements identified within Section C.2 Technical Requirements (e.g., Cloud Infrastructure as a Service (IaaS), or Managed Trusted Internet Protocol Services (MTIPS)).

Compliance references include, but are not limited to:

Federal Information Security Management Act (FISMA) of 2002; (44 U.S.C. Section 301. Information security) available at: http://csrc.nist.gov/drivers/documents/FISMA-final.pdf.

Federal Information Security Modernization Act of 2014; (to amend Chapter 35 of 44 U.S.C.) available at https://www.congress.gov/113/bills/s2521/BILLS-113s2521es.pdf.

Clinger-Cohen Act of 1996 (formerly known as the “Information Technology Management Reform Act of 1996”) available at: https://www.fismacenter.com/Clinger%20Cohen.pdf.

Privacy Act of 1974 (5 U.S.C. § 552a).

Homeland Security Presidential Directive (HSPD-12), “Policy for a Common Identification Standard for Federal Employees and contractors”, dated August 27, 2004; available at: http://www.idmanagement.gov/.

Office of Management and Budget (OMB) Circular A-130, “Management of Federal Information Resources”, and Appendix III, “Security of Federal Automated Information Systems”, as amended; available at: http://www.whitehouse.gov/omb/circulars_a130_a130trans4/.

OMB Memorandum M-04-04, “E-Authentication Guidance for Federal Agencies” (Available at: http://www.whitehouse.gov/omb/memoranda_2004).

OMB Memorandum M-14-03. “Enhancing the Security of Federal Information and Information Systems” available at https://www.whitehouse.gov/sites/default/files/omb/memoranda/2014/m-14-03.pdf.

FIPS PUB 199, “Standards for Security Categorization of Federal Information and Information Systems.” Dated February 2004.

FIPS PUB 200, “Minimum Security Requirements for Federal Information and Information Systems.” Dated March 2006.

FIPS PUB 140-2, “Security Requirements for Cryptographic Modules.” Dated May 2001.

NIST SP 800-18 Revision 1, “Guide for Developing Security Plans for Federal Information Systems.” Dated February 2006.

NIST SP 800-30 Revision 1, “Guide for Conducting Risk Assessments.” Dated September 2012.

NIST SP 800-34 Revision 1, “Contingency Planning Guide for Information Technology Systems.” Dated May 2010.

NIST SP 800-37 Revision 1, “Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach.” Dated February 2010.

NIST SP 800-40 Revision 3, “Guide to Enterprise Patch Management Technologies.” Dated July 2013.

NIST SP 800-41 Revision 1, “Guidelines on Firewalls and Firewall Policy.” Dated September 2009.

NIST SP 800-47, “Security Guide for Interconnecting Information Technology Systems.” Dated August 2002.

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations.” Dated April 2013.

NIST Special Publication 800-53A, Revision 4, “Assessing Security and Privacy Controls in Federal Information Systems and Organizations, Building Effective Assessment Plans.” Dated December 2014.

NIST SP 800-58 “Security Considerations for Voice Over IP Systems.” Dated January 2005.

NIST SP 800-60 Revision 1, “Guide for Mapping Types of Information and Information Systems to Security Categories.” Dated August 2008.

NIST SP 800-61 Revision 2, “Computer Security Incident Handling Guide.” Dated August 2012.

NIST SP 800-88 Revision 1, “Guidelines for Media Sanitization.” Dated December 2014.

NIST SP 800-94 “Guide to Intrusion Detection and Prevention Systems.” Dated February 2007.

NIST SP 800-128 “Guide for Security-Focused Configuration Management of Information Systems.” Dated August 2011.

NIST SP 800-137 “Information Security Continuous Monitoring for Federal Information Systems and Organizations.” Dated September 2011.

NIST SP 800-144 “Guidelines on Security and Privacy in Public Cloud Computing.” Dated December 2011.

NIST SP 800-160 “Systems Security Engineering.” Draft dated May 2014.

NIST SP 800-161 “Supply Chain Risk Management Practices for Federal Information Systems and Organizations.” Dated April 2015.

NIST SP 800-171, “Protecting Controlled Unclassified Information in the Nonfederal Information Systems and Organizations.” Dated June 2015.

Committee on National Security Systems (CNSS) Policy No. 12, National Information Assurance Policy for Space Systems Used to Support National Security Missions. Dated 28 November 2012.

Committee on National Security Systems (CNSS) Policy No. 15, National Information Assurance Policy on the Use of Public Standards for the Secure Sharing of Information Among National Security Systems. Dated 1 October 2012.

Committee on National Security Systems Instruction (CNSSI) No. 1253, Security Categorization and Control Selection for National Security Systems. Dated March 2012.

Committee on National Security Systems Instruction (CNSSI) No. 5000, “Guidelines for Voice over Internet Protocol (VoIP) Computer Telephony.” Dated April 2007.

Department of Defense Instruction (DODI) 8500.01 “Cybersecurity.” Dated 14 March 2014.

DODI 8510.01 “Risk Management Framework (RMF) for DOD Information Technology (IT).” Dated 12 March 2014.

Department of Defense (DOD) Cloud Computing Security Requirements Guide (SRG). Draft Dated 7 December 2014.

ICD 503, “Intelligence Community Information Technology Systems Security: Risk Management, Certification and Accreditation.” Dated 15 September 2008.

ICD 703, “Protection of Classified National Intelligence, Including Sensitive Compartmented Information.” Dated 21 June 2013.

ICD 704, “Personnel Security Standards and Procedures Governing Eligibility for Access to Sensitive Compartmented Information and Other Controlled Access Program Information.” Dated 2 October 2008.

ICD 705, “Sensitive Compartmented Information Facilities.” Dated 26 May 2010.

ICD 731, “Supply Chain Risk Management.” Dated 7 December 2013.

Other agency-specific policies, directives and standards as identified at the TO level.

Security Compliance Requirements FIPS 200, “Minimum Security Requirements for Federal Information and Information Systems,” is a mandatory federal standard that defines the minimum security requirements for federal information and information systems in eighteen security-related areas. Contractor systems supporting agencies must meet the minimum security requirements through the use of the security controls in accordance with NIST Special Publication 800-53, Revision 4 (hereinafter described as NIST SP 800-53) “Recommended Security Controls for Federal Information Systems.”

To comply with the federal standard, the government has determined the security category of the information and information system in accordance with FIPS 199, “Standards for Security Categorization of Federal Information and Information Systems,” to be established at a minimum of a Moderate Impact Level and baseline security controls must be established as identified in NIST SP 800-53 and other associated directives and guides identified and/or provided by each specific agency.

The government recognizes that these requirements are evolving and will make the necessary updates as the standards are formally implemented to reflect the changes.

If a Cloud solution is used (meeting the NIST definition of Cloud as stated in C.2.5) the security category of the information and information system will be established at a minimum of a Moderate Impact Level and the baseline security controls, applicable directives and guides as well as deliverables that must be adhered to are identified at www.FedRAMP.gov.

GSA will not be an EIS contractor FedRAMP sponsor at the contract level.

Security Assessment and Authorization (Security A&A) In addition to the contractor’s Business Support System (BSS) requirements identified in Section G.5.6, the implementation of any contractor IT system that stores, transports or processes federal government data requires a formal approval process known as security A&A. NIST SP 800-37, Revision 1 (hereinafter listed as NIST SP 800-37) and agency-specific IT security procedural guidance, associated with managing enterprise risk, provides guidance for performing the security A&A process.

The contractor’s system must have the capability to provide a valid security A&A (when required by agency TO) prior to being placed into operation and processing government information for that agency. Agencies may require higher level certifications to be addressed at the TO level. Failure to obtain and maintain a valid assessment and authorization will be grounds for termination of a TO.

System Security Plan (SSP) For delivery of services under a TO, the contractor shall comply with all security A&A requirements mandated by federal laws, directives and policies, including making available any documentation, physical access, and logical access needed to support this requirement. The level of effort for the security assessment and authorization is based on the System’s NIST FIPS Publication 199 categorization. The SSP shall be completed in accordance with NIST Special Publication 800-18, Revision 1 (hereinafter listed as NIST SP 800-18) and other relevant guidelines. The SSP shall describe the contractor’s approach for security compliance for all services provided under the EIS contract. The SSP shall also include, at a minimum, appendices and attachments specifically identified within the TO.

System Security Plan Deliverables TOs will specifically identify the system security deliverables to be provided to an Ordering Contracting Officer (OCO), Information System Security Officer (ISSO), or Information System Security Manager (ISSM) initially, quarterly and on an annual basis, or when significant changes, as defined in NIST SP 800-37, occur to the system.

Additional Security Requirements

1. The contractor shall not publish or disclose in any manner, without the CO’s written consent, the details of any safeguards either designed or developed by the contractor under this TO or otherwise provided by the government. Exception - Disclosure to a Consumer Agency for purposes of security assessment and authorization verification.

2. To the extent required to carry out a program of inspection to safeguard against threats and hazards to the security, integrity, availability and confidentiality of any non-public government data collected and stored by the contractor, the contractor shall afford the government logical and physical access to the contractor’s facilities, installations, technical capabilities, operations, documentation, records, and databases within 72 hours of the request. Automated audits shall include, but are not limited to, the following methods:

· Authenticated and unauthenticated operating system/network vulnerability scans,

· Authenticated and unauthenticated web application vulnerability scans,

· Authenticated and unauthenticated database application vulnerability scans, and

· Internal and external penetration tests.

3. Automated scans can be performed by government personnel, or agents acting on behalf of the government, using government operated equipment, and government specified tools. If the contractor chooses to run its own automated scans or audits, results from these scans may, at the government’s discretion, be accepted in lieu of government performed vulnerability scans. In these cases, scanning tools and their configuration shall be approved by the government. In addition, the results of contractor-conducted scans shall be provided, in full, to the government.

Personnel Background Investigation Requirements The contractor shall perform personnel security / suitability checking in accordance with FAR Part 52.204-9 (see Section I).

All contractor personnel with access to government information that is within the security A&A scope must successfully complete a background investigation in accordance with Homeland Security Presidential Directive-12 (HSPD-12) Office of Management and Budget (OMB) guidance M-05-24, M-11-11 “Continued Implementation of Homeland Security Presidential Directive (HSPD-12) Policy for a Common Identification Standard for Federal Employees and Contractors,” and as specified in agency-identified security directives and procedural guides.

The ordering agency will be responsible for the cost of any required background investigations.

National Policy Requirements The concept of a national telecommunications infrastructure is recognized in national policy statements and directives issued under the authority of the Executive Office of the President, Congress, the Department of Homeland Security (including the Office of Emergency Communications), and other entities of the government. This telecommunications infrastructure is required to support the critical needs of the government under conditions of stress that range from crises and natural disasters (e.g., flood, earthquake) through declared conditions of National Security and Emergency Preparedness (NS/EP). Public safety and the economic well-being of the nation also depend upon the availability of reliable and responsive telecommunications services. EIS is a key component of the US national telecommunications infrastructure.

GSA expects to effectively provide assurance for government users that services and service elements (technical, management and operations-related) acquired through EIS will be in compliance with national policy throughout the life of the contracts. The contractor shall ensure that services delivered are in compliance with national policy directives that apply to the national telecommunications infrastructure.

Specific national policy requirements include, but are not limited to:

1. NS/EP requirements include a wide range of Executive Orders, Presidential Directives as promulgated by the Executive Office of the President, the Director of Homeland Security, the Office of Emergency Communications and other government entities. NS/EP requirements are covered in Section G.11.

1. OMB Memorandum M-05-22 directs that agencies must transition from IPv4 agency infrastructures to IPv6 agency infrastructures (network backbones). For agencies with an IPv6 network (and those implementing IPv6 networks) with IPv4 legacy support, the contractor solution must maintain functionality and shall comply with NIST SP 500-267. All systems, software, and equipment supporting the agency network and its services shall handle IPv6 in an equivalent or better way than current IPv4 capabilities, performance, and security. No systems, software, or equipment shall be deployed on the network that does not meet this requirement. Additionally, all network management shall be enabled using IPv6.

1. OMB Memorandum M-09-32, “Update on the Trusted Internet Connections Initiative,” “requires all agencies to undertake immediate responsibility for executing essential agreements and updating POA&Ms to facilitate not only TIC preparations, but also due diligence for integrating the National Cyber Protection System (NCPS, operationally referred to as EINSTEIN) deployments and synchronizing with US-CERT,” and OMB Memorandum M-15-01, “Fiscal year 2014-2015 Guidance on Improving Federal Information Security and Privacy Management Practices” requires Departments and Agencies (D/As) to enter into legally sufficient agreements with DHS relating to the deployment of EINSTEIN. DHS establishes these agreements with D/As authorizing in-line traffic inspection and modification, and such activities may include the interception, modification, use, and disclosure of D/A traffic. As such, specific EIS data service offerings: VPNS, Ethernet Transport, PLS, IPS, Cloud services, which includes IaaS Private Cloud, Paas, and SaaS, MNS Traffic Aggregation Service, MTIPS, and IPSS, and in future implementations could include other externally routed data services(e.g. OWS, SONETS), transporting Internet, Extranet, and Inter-Agency traffic shall identify and route said government traffic through a secure DHS EINSTEIN Enclave for processing by the latest generation of EINSTEIN capabilities. . As such, any service offering under EIS (VPNS, Ethernet Transport, IPS, Cloud, MTIPS or otherwise) transporting Internet, Extranet, and Inter-Agency traffic shall identify and route said government traffic through a secure DHS EINSTEIN Enclave for processing by the latest generation of EINSTEIN capabilities. The contractor shall design, implement, and operate its services to achieve the required routing of traffic through (including delivery to and receipt of traffic from) DHS EINSTEIN Enclaves. Transport SLA KPIs are measured as if through loopbacks in EINSTEIN Enclaves. EINSTEIN Enclaves are strictly intermediate hops and shall not be considered end points for SLA measurement.

Telecommunications policy and the national telecommunications infrastructure are increasingly impacted by the convergence of telecommunications and information technology. Thus, policy directives in the areas of Electronic Government (“E-Gov”), Enterprise Architecture development, and Information Assurance, for example, may also have implications for telecommunications infrastructure. Additional policy requirements may be identified to the contractor. If contract modifications are required to meet new government-specific requirements, the contractor shall submit a technical approach and schedule for proposing these modifications to the CO per contract modification guidelines identified in Section J.4.

Technical Support The contractor shall provide customer technical support as a component of each of its EIS services. For detailed requirements, please see Section G.6.2 Customer Service Office and Technical Support and Section G.6.4 Trouble Ticket Management.

Technical Requirements Data Service Virtual Private Network Service Service Description The contractor’s Virtual Private Network Service (VPNS) shall provide secure, reliable transport of agency applications across the provider’s high-speed unified multi-service IP-enabled backbone infrastructure.

Functional Definition The main characteristic of VPNS is that all infrastructure and devices involved in implementing the VPN are owned by the contractor and located at the edge of the contractor’s backbone. Tunnels terminate at the contractor’s edge router.

The contractor shall use its backbone to establish three basic solutions for VPNS:

1. Intranet ─ provides secure tunnels between remote sites, using broadband or dedicated access.

1. Extranet ─ enables trusted business partners to gain access to corporate information via secure/encrypted tunnels, using broadband or dedicated access.

1. Remote Access ─ enables mobile/remote workers to gain access to secure corporate information via secure encrypted tunnels, such as IPsec and TLS.

The contractor shall accommodate and optimize an agency’s applications to enable the network to accurately and consistently allow for traffic prioritization and cost efficiencies to support the following VPNS traffic types:

1. Time-critical traffic such as voice and video.

1. Business-critical traffic such as transactions.

1. Non-critical traffic such as email.

Standards VPNS shall comply with the following standards.

1. OMB M-11-11 “Continued Implementation of Homeland Security Presidential Directive (HSPD-12) Policy for a Common Identification Standard for Federal Employees and Contractors”

1. NIST Special Publication (SP) 800-46 Revision 1 “Guide to Enterprise Telework and Remote Access Security”

1. IETF RFCs:

1. For secure VPNs:

i. General IPSec

ii. ESP and AH

iii. Key exchange

iv. Cryptographic algorithms to include but not limited to 3DES, RC4 and AES

v. IPSec policy handling

vi. IPSec MIBs

vii. Remote access

viii. Certification Authorities

1. For trusted VPNs:

ix. General MPLS

1. IP Security Working Group – RFC 4303

1. IP Security Policy Working Group – RFC 3586

1. MPLS Working Group – RFC 3468

1. Layer 3 Virtual Private Network (L3VPN) Working Group – RFC 4176

1. Pseudo Wire Emulation Edge to Edge (pwe3) Working Group – RFC 3985

1. Use of PE-PE GRE or IP in RFC2547 RFC4364 VPNs:

draft-ietf-l3vpn-gre-ip-2547-00.txt

1. IETF-TLS Working Group – RFC 5246 for TLS 1.2

1. TLS 1.2 Protocol Specification

1. IETF RFCs for IPv4 and IPv6

1. CNSSP-15, National Information Assurance Policy on the Use of Public Standards for Secure Sharing of Information Among National Security Systems

1. All new versions, amendments, and modifications to the above documents and standards Connectivity VPNS shall connect government locations and trusted business partners for site-to-site access or broadband for remote access to provide direct connectivity between all sites as a partially- or fully-meshed WAN.

Technical Capabilities The following VPNS capabilities are mandatory unless marked optional.

1. The contractor shall meet applicable routing requirements in Section C.1.8.8 ensuring any encrypted tunnels are applied and proxied to allow inspection.

1. The contractor shall provide multiple tunneling standards, as required by an agency. Examples include L2TP, GRE, IP-in-IP, MPLS, IPSec, and TLS.

1. The contractor shall provide various encryption levels, as required by an agency. Examples include 3DES, RC4 and AES in accordance with the appropriate FIPS publications and modules.

1. The contractor shall provide authentication services as required by an agency. Examples include RADIUS, Internal LDAP, token integration, PKI, and X.509 certificates.

1. The contractor shall support IPv4 as both the encapsulating and encapsulated protocol.

1. The contractor shall support IPv6 as both the encapsulating and encapsulated protocol.

1. The contractor shall support QoS in the following standardized modes:

1. Best effort

1. Aggregate Customer Edge (CE) Interface level QoS (“hose” level)

1. Site-to-site level QoS (“pipe” level)

1. Intserv (RSVP) signaled

1. Diffserv marked

1. The contractor shall support QoS across a subset of the access networks as listed below:

1. 802.1p Prioritized Ethernet

1. MPLS-based access

1. Multilink Multiclass PPP

1. QoS-enabled wireless:

x. LTE

xi. Wireless 802.11.x

xii. Cable high-speed access (DOCSIS 1.1)

xiii. QoS-enabled Digital Subscriber Line (DSL)

xiv. QoS-enabled Satellite Broadband Access

1. The contractor shall support one or more of the following application level QoS objectives:

1. Intserv model for selected individual flows

1. Diffserv model for aggregated flows

1. The contractor shall provide isolation of traffic and routing service that isolates the exchange of traffic and routing information to only those sites that are authenticated and authorized members of a VPN. The contractor shall provide layered security architecture to ensure that attackers will not find a single point of entry but will be faced with multiple layers of security.

1. The contractor shall support multiple VPNs by allowing both permanent and temporary access to one or more VPNs for authenticated users across a broad range of access technologies.

1. The contractor shall provide secure routing services to provide full routing capability on the VPN platform with a secure policy across the VPN.

1. The contractor shall support the inclusion of encryption, decryption, and key management profiles as part of the security management system.

1. The contractor shall support an agency in deploying its own internal security mechanisms in addition to those deployed by the contractor, in order to secure specific applications or traffic at a granularity finer than a site-to-site basis.

1. The contractor shall allow an agency to choose from alternatives for authentication of temporary access users. Authentication server choices include:

1. Contractor-provided

1. Third party

1. Agency-provided Features The VPNS features are mandatory unless marked optional.

1. Load sharing

2. Fail-over protection

3. Diverse access points to service provider’s POP(s).

(optional)

Interfaces These UNIs at the SDP for VPNS are mandatory unless marked optional.

Private Line Service

1. DS0

2. T1

3. T3

4. OC-3c

5. OC-12c

6. OC-48c

7. OC-192c

8. OC-768c (optional) IPv4/v6 over PLS

1. OC-3c

2. OC-12c

3. OC-48c

4. OC-192c

5. OC-768c (optional) IP/PPP over SONET

2. LTE

3. Satellite Point-to-Point Protocol, IPv4/v6

Notes:

1. IPv6 shall be supported by the contractor.

1. Where E-1/E-3 carrier service is provided, appropriate corresponding payload data rates apply.

Performance Metrics The performance levels and acceptable quality level (AQL) of KPIs for VPNS are mandatory unless marked optional.

(Threshold)

1. Latency value is the average round trip transmission between agency premises routers for an VPN with all of its CONUS sites. The latency metric does not apply for DSL, Cable High Speed, Wireless, and Satellite access methods. Relevant standards are RFC 1242 and RFC 2285. The contractor may propose to the government more cost-effective test and measurement technique alternatives that meet or exceed the requirements in RFC 1242 and RFC 2285.

1. Latency value is the average round trip transmission between agency premises routers for an IP VPN with its CONUS and OCONUS sites. The latency metric does not apply for DSL, Cable High Speed, Wireless, and Satellite access methods. Relevant standards are RFC 1242 and RFC 2285. The contractor may propose to the government more cost-effective test and measurement technique alternatives that meet or exceed the requirements in RFC 1242 and RFC 2285.

1. VPN availability is measured end-to-end and calculated as a percentage of the total reporting interval time that the VPN is operationally available to the agency. Availability is computed by the standard formula:

1. See Section G.8.2 for the definitions and measurement guidelines.

Ethernet Transport Service Service Description Carrier Grade Ethernet transport service shall be implemented over an MPLS backbone, where Ethernet links are transported using MPLS label switched paths (LSPs) inside an outer MPLS “tunnel.” Point-to-point connections can also be provided by Ethernet over SONET solutions.

Ethernet Transport Service (ETS) allows agencies to interconnect their LANs (10 Mbps, 100 Mbps, 1 Gbps, and 10/40/100 Gbps) transparently over the Metro Area Networks (MAN) and the Wide Area Networks (WAN) regardless of the geographical location of their sites. Ethernet Transport Service enables Intranet and Extranet services, as well as intra- and inter-agency communications.

Ethernet shall be provided as a dedicated service or a shared service. Dedicated Ethernet is defined as private services that are carried over dedicated facilities at fixed and predetermined speeds. Shared Ethernet is defined as statistically multiplexed Ethernet connections.

Functional Definition ETS provides point-to-point, point-to-multipoint and multipoint-to-multipoint connections. ETS exploits Ethernet’s flexibility, cost effectiveness, and differentiation of service (e.g., traffic priority) capabilities while providing end-to-end transport of data traffic with minimal protocol conversion. The following ETS shall be supported:

1. Ethernet Private Line (E-LINE). E-Line is a point-to-point service in which bandwidth is reserved. E-Line supports full port speeds (10 Mbps, 100 Mbps, 1 Gbps, and 10/40/100 or higher Gbps) and can support different quality of service (QoS) priorities for customer traffic. E-Line is a point-to-point configuration as a Layer 2 tunnel providing a transparent dedicated connection between two sites. This service resembles/replaces traditional Time Division Multiplexing (TDM) private line service. Some applications include router interconnect, business continuity, and disaster recovery. E-LINE service can be offered over the MAN and/or WAN.

1. Ethernet Private LAN (E-LAN). E-LAN supports both point-to-multipoint and multipoint-to-multipoint configurations. For point-to-multipoint configurations, ETS connects three or more sites over Layer 2 tunnels. It supports full port speeds (10 Mbps, 100 Mbps, 1 Gbps, and 10/40/100 or higher Gbps) and can support different QoS priorities for customer traffic. For multipoint-to-multipoint configuration, also called E-Tree service, ETS connects several sites, similar to point-to-multipoint configuration, by connecting one or more roots and a set of leaves, but preventing inter-leaf communication. More than one site can be configured as the root site and other sites can communicate with each other through multiple root sites; for example, connecting disparate LAN segments into a single agency-wide virtual LAN. E-LAN can be offered over the MAN and/or WAN.

Standards ETS shall comply with the following standards:

1. Metro Ethernet Forum (MEF CE 2.0):

1. (Optional) Support Jumbo Ethernet frames

1. CE 2.0 is set of MEF CE 2.0 Certified network elements that connect to transport Carrier Ethernet services for all users, locally and worldwide. Ethernet transport services are carried over physical Ethernet networks and other legacy transport technologies.

1. Key Specifications:

· MEF 6.1 - CE Service Definitions

· MEF 10.2 - CE Service Attributes

· MEF 33 - Ethernet Access Services

· MEF 23.1 - Class of Service

· MEF 26.1 - ENNI

1. CE 2.0 expands CE 1.0 to:

· 8 services, 2 of each respectively in E-Line, E-LAN, E-Tree, and E-Access (defined in MEF Standards MEF 6.1, 22.1, 33)

· Standardized Multi-CoS with application-oriented CoS Performance Objectives, new metrics (MEF 6.1, 10.2, 20, 23.1)

· Interconnect through the integrated delivery of MEF Service Attributes (MEF 10.2, 26.1, 33) allows ubiquitous deployment spanning multiple providers

· Manageability, (MEF 7.1, 16, 17, 30, 31) plus additional specifications

1. International Telecommunications Union…