SSL VPN RFI SOW - 6.4.24.pdf

PDF 202 KB Posted

Attached to
Amendment 1 - NASA Secure Socket Layer (SSL) based Virtual Private Network (VPN) Remote Access Solution
Solicitation number
80TECH24RFI0012
Issued by

About this file

This document is a Request for Information (RFI) issued by NASA for a Secure Socket Layer (SSL) based Virtual Private Network (VPN) Remote Access Solution. The RFI seeks information from industry on product capabilities and compatibility with NASA's overall architecture to support approximately 8,000 full-client and 500 clientless users. Key requirements include support for multiple authentication methods, granular access controls, clientless access, device/user conditional access policies, HTML5 remote access protocols, and FIPS 140-2 compliance. General product questions cover aspects like operating system, bandwidth, multi-tenancy, policy management, logging, and high availability. NASA is requesting an estimated implementation timeline as well as feedback on any migration concerns from the agency's existing SSL VPN solutions. Responses to this RFI are due by June 26, 2024, and NASA will not pay for any costs associated with responding. This RFI does not constitute a solicitation, and NASA is not seeking proposals at this time.

View the file

Other files

File Type Posted
80TECH24RFI0012 - Amend 1.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Request for Information (RFI) for Secure Socket Layer (SSL) based Virtual Private Network (VPN) Remote Access Solution at NASA NOTE: This is a Request for Information Only. This is not a solicitation for proposals and there is no solicitation planned at this time.

General Information THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This RFI is issued solely for information and strategic planning purposes as part of NASA’s Office of the Chief Information Officer (OCIO) Network and Telecommunication Services (NaTS) Service Line strategic initiatives; it does not constitute a Request for Proposal (RFP) or a promise to issue an RFP in the future. This RFI does not commit the Government to contract for any supply or service whatsoever. Further, NASA is not at this time seeking proposals and will not accept unsolicited proposals for any specific SSL VPN solutions discussed in the following. Responders are advised that the U.S. Government will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party’s expense. Not responding to this RFI does not preclude participation in any future RFP, if any is issued. If a solicitation is released, it will be synopsized in accordance with FAR

5.2. It is the responsibility of the potential offerors to monitor SAM.gov and/or GSA eBuy for any possible future solicitation.

1.0 Background

NASA is performing a market study for a secure socket layer (SSL) based virtual private network (VPN) remote access solution to replace an existing SSL VPN solution. The Remote Access Service (RAS) line provides remote connectivity across the public Internet to secure network services and resources. RAS provides authenticated end users who are working remotely with secure access to internal resources and applications. This could include files shared on local or data center-based file servers, printers, and internal applications. The RAS service is provided to meet the requirements of mobile workers who need to routinely connect to their NASA Center network across an unsecured public Internet connection. This public connection may be initiated via a WiFi connection at a business or hotel, guest wireless services at another NASA site, a home network, or a cellular data connection.

2.0 Current Environment

The NASA VPN architecture is comprised of Agency SSL VPN appliances as well as traditional, full IPsec based VPN appliancesThe current SSL VPN solution is used primarily for application specific access for partners, researchers, universities, and other groups that may also require access to a full VPN client to access their network outside of NASA’s boundary. This request is focused on the replacement of the SSL VPN based solution with a comparable appliance-based solution. This solution supports approximately 8,000 users and 500 users require the clientless option.

Trusted Internet Connection (TIC) sites supporting Internet connectivity are located at the following NASA Centers. The SSL VPN appliances are currently hosted at multiple TIC locations in redundant pairs

- Ames Research Center (ARC)

- Goddard Space Flight Center (GSFC)

- Johnson Space Center (JSC)

- Marshall Space Flight Center (MSFC)

3.0 Requirements

Provided below are a set of high-level requirements designed to capture product capabilities and ensure compatibility within NASA’s overall architecture. The recommended solution should be capable of supporting 8,000 full-client and 500 clientless users.

Req # Requirement 1 Provide full Layer 3 VPN connectivity with granular access 2 Support multiple launch methods such as via Web browser / desktop client 3 Support machine-based VPN with ability to provided user based authentication after log-in 4 Support client / server proxy application that tunnels traffic from specific applications to specific destinations 5 Support “on demand” and “per app” VPN access with ability to auto-connect on device start-up 6 Support multiple single sign-on methods to include Security Assertion Markup Language

(SAML) 2.0, public key infrastructure (PKI)/digital certificates and OAuth / OpenID Connect (OIDC) to allow integration with any standard OpenID provider

7 Support conditional access based on device and user policies 8 Secure clientless access from any hypertext markup language 5 (HTML5) capable browser to published and/or user added applications and link 9 Support remote desktop protocol (RDP), teletype network (Telnet), virtual network computing

(VNC), and secure shell (SSH) access with advanced HTML5 10 Support across multiple end user device operating systems (i.e., Windows, MacOS, Apple

IOS, Android, etc.

11 Support ability to configure granular SSL / transport layer security (TLS) cipher configurations 12 Support representational state transfer (REST) application programming interfaces (API) for programmatic access to the appliances 13 Support standards based built-in Time-Based One-Time Passwords (TOTP) via smartphones 14 Support multiple, authenticated sessions per user 15 Support Web-based single sign-on (SSO) basic authentication and NTLM allowing users to access other applications or resources that are protected by another access management system without reentering credentials

16 Support ability to pass user name, credentials, and other custom defined attributes to the authentication forms of other products and as header variables

17 Solution must be federal information processing standards (FIPS) 140-2 compliant

18 Support production of audit logs that contain sufficient information to establish what events occur, the sources of the events and the outcomes of the events

19 Support logging of security relevant events such as all successful login and logoff attempts, all unsuccessful login attempts

20 Support export of audit logs to Splunk and other security event and incident management (SEIM tools)

21 Support ability to configure session lengths after which a user session is terminated

General Product Questions

Please provide responses to the following general product questions based on the requirements in 3.0:

1. What type of operating system is the appliance based on?

2. Does the product prevent end users from opening direct connections to the appliance applications or resources?

3. What are the bandwidth limitations for the product? Provide details on interface bandwidth options.

4. Does the product support multiple tenants or communities of interest on the same appliance?

5. What level of role-based access is supporting for administration of the product?

6. What authentication methods are supported?

7. Can multiple authentication interfaces be supported concurrently?

8. What types of policies are supported (i.e., Web based share directory, TCP, etc.)?

9. Are policies defined as PERMIT or DENY policies or both?

10. Can policies be associated with users, groups, or both?

11. How are policies stored and retrieved?

12. Are policies stored locally on the appliance?

13. Does your solution support encrypted syslog data sharing to a SIEM tool such as Splunk?

14. What formats of logging are supported? Provide specific details on the logging formats supported.

15. What information is logged? Provide specific details on data that is capable of being logged.

16. What tools can be used to process / analyze the logs?

17. Are full and split tunneling settings supported?

18. Does the appliance use hardware acceleration for SSL encryption?

19. What is the maximum number of concurrent user sessions?

20. What is the maximum number of concurrent SSL connections?

21. What is the bulk SSL throughput?

22. Does the appliance support high availability? How is high availability implemented?

23. Does the high availability require special hardware or connections?

24. What type of management interfaces are supported on the appliance?

25. Does the appliance offer SNMP v2 / SNMP v3 support?

26. Does your solution allow the co-existence of other vendor VPN clients on the same end user device? Provide details on any potential conflicts with other vendor VPN products.

27. What do you anticipate the annual cost to be for this effort?

28. Please describe any concerns or issues that might complicate a migration from our SSL full client and clientless VPNsolutions to your proposed solution.

4.0 Implementation Timeline

Please provide an estimated timeline to deploy the recommended solution

5.0 RFI Timeline

• Questions should be submitted via email within ten (10) business days of RFI release in order to permit Government coordination and responses. Requested information includes general business name, business division, and preferred point of contact(s) to include corporate address, phone number(s), and e- mail address(es)

• RFI responses are due no later than June 26, 2024, 5:00 p.m. EST. Responses are preferred to be limited to 10 pages in combined length (including illustrations, graphs, etc.) and shall be either Portable Document Format (PDF) (with copy and paste enabled) or Microsoft Word format. The aspect for the deliverable shall be formatted to 8.5" x 11" (letter size) paper with type no smaller than 11-point font.

• RFI responses shall be structured per numbering schema above to facilitate processing of returned information.

• Proprietary information, if any, should be minimized and SHALL BE CLEARLY MARKED.

Please be advised that all submissions become Government property and will not be returned.

File details come from the government source that posted it. Updated .