SecureConnect

Enterprises have requirements to encrypt in transit data in many environments, particularly in PCI and other regulated environments. Encrypting in transit data is straightforward for an enterprise when the data is moving between datacenters. An enterprise can deploy dedicated security appliances (such as VPN concentrators) to implement IPsec-based communication across open untrusted networks.

However, what if an enterprise needs to encrypt in transit data within a VLAN, datacenter, or PCI environment, or from a cloud location to an enterprise datacenter? Deploying a dedicated security appliance to protect every workload is no longer feasible, especially in public cloud environments. Additionally, configuring and managing IPsec connections becomes more difficult as the number of hosts increases.

Our Solution

SecureConnect leverages the built-in encryption libraries of host operating systems. On Windows hosts, SecureConnect utilizes Windows IPsec. On Linux hosts, SecureConnect utilizes StrongSwan and Linux kernel IPsec for traffic encryption.

With SecureConnect, Illumio delivers a feature that configures the Security Associations (SAs) necessary to enable traffic encryption between workloads. Once authenticated, encryption and cryptographic suites provide confidentiality and data integrity to network traffic flowing between workloads.

The PCE centrally manages all traffic encryption for workloads so that it can be policy driven. For example, a customer can require that all traffic between their web servers and database servers is encrypted. Selecting the SecureConnect option for these workloads allows the PCE to apply the requisite security policy to your organization to make that happen. SecureConnect reduces the complexity of configuring IPsec encryption and auto-scales per your policy definitions.

Use Cases

Employing SecureConnect is especially beneficial in these common scenarios:

• Facilitate PCI compliance by ensuring that confidential data is encrypted over the network.
• Secure off-site backup and recovery of data across geographically distributed datacenters.
• Secure communications across applications and application tiers for regulatory compliance and tighter security.
• Enable secure data migration across different public cloud providers.

Features of SecureConnect

SecureConnect has the following key features.

Platforms Supported by SecureConnect

SecureConnect works for connections between Linux workloads, between Windows workloads, and between Linux and Windows workloads.

IPsec Implementation

SecureConnect implements a subset of the IPsec protocol called Encapsulating Security Payload (ESP), which provides confidentiality, data-origin authentication, connectionless integrity, an anti-replay service, and limited traffic-flow confidentiality.

In its implementation of ESP, SecureConnect uses IPsec transport mode. Using transport mode, only the original payload is encrypted between the workloads. The original IP header information is unchanged so all network routing remains the same. However, the protocol being used will be changed to reflect the transport mode (ESP).

Making this change causes no underlying interfaces to change or be created or any other underlying networking infrastructure changes. Using this approach simply obfuscates the data between endpoint workloads by encrypting the data between them.

If SecureConnect is unable to secure traffic between two workloads with IPsec, it will block unencrypted traffic when the policy was configured to encrypt that traffic.

IKE Versions Used for SecureConnect

SecureConnect connections between workloads use the following versions of Internet Key Exchange (IKE) based on workload operating system:

• Linux ↔ Linux: IKEv2
• Windows ↔ Windows: IKEv1
• Windows ↔ Linux: IKEv1

For a list of supported operating systems for managed workloads, see the VEN OS Support and Package Dependencies on the Illumio Support portal (login required).

Using Pre-Shared Keys with SecureConnect

SecureConnect includes the option of using pre-shared keys (generated by the PCE) or client-side PKI certificates for IKE authentication.

You can configure SecureConnect to use pre-shared keys (PSKs) to build IPsec tunnels that are automatically generated by the PCE. SecureConnect uses one key per organization. All the workloads in that organization share the one PSK. SecureConnect uses a randomly generated 64-character alpha-numeric string, for example:

c4aeb6230c508063db3e3e1fac185bea9c4d17b4642a87e091d11c9564fbd075

When SecureConnect is enabled for a workload, you can extract the PSK from a file in the /opt/illumio directory, where the VEN stores it. You cannot force the PCE to regenerate and apply a new PSK. If you feel the PSK has been compromised, contact Illumio Customer Support (login required).

Using PKI Certificates with SecureConnect

SecureConnect allows you to use client-side PKI certificates for IKE authentication and IPsec communication between managed workloads. If you have a certificate management infrastructure in place, you can leverage it for IKE authenticate between workloads because it provides higher security compared to using pre-shared keys (PSKs).

Certificate-based SecureConnect works for connections between Linux workloads, between Windows workloads, and between Linux and Windows workloads.

The IPsec configuration uses the certificate with the distinguished name from the issuer field that you specify during PCE configuration for IKE peer authentication.

Existing IPsec Configuration on Windows Systems

Installing a VEN on a Windows system does not change the existing Windows IPsec configuration, even though SecureConnect is not enabled. The VEN still captures all logging events (event.log, platform.log) from the Windows system that relate to IPsec thereby tracking all IPsec activity.

Performance

The CPU processing power that a workload uses determines the capacity of the encryption. The packet size and throughput determine the amount of power that is required to process the encrypted traffic using this feature.

In practice, enabling SecureConnect for a workload is unlikely to cause a big spike in CPU processing or a decrease in network throughput. However, Illumio recommends benchmarking performance before enabling SecureConnect and comparing results after enabling it.

SecureConnect Prerequisites, Limitations, Caveats

Before configuring your workloads to use SecureConnect, review the following prerequisites and limitations, and consider the following caveats.

PKI Certificates with SecureConnect

The following prerequisites and limitations apply when configuring SecureConnect to use certificates:

• You must have a PKI infrastructure to distribute, manage, and revoke certificates for your workloads. The PCE does not manage certificates or deliver them to your workloads.
• The PCE supports configuring only one global CA ID for your organization.
• The VEN on a workload uses a Certificate Authority ID (CA ID) to authenticate and establish a secure connection with a peer workload.

Connected workloads must have CA identity certificates signed by the same root certificate authority. When workloads on either end of a connection use different CA IDs, the IKE negotiation between the workloads will fail and the workloads will not be able to communicate with each other.

SecureConnect runtime fails between VENs running on release versions before 20.x with VENs on releases after 20.x because of the version mismatch.

VEN Versions

To use PKI certificates with SecureConnect, your workloads must be running VEN version 17.2 or later.

Maximum Transmission Unit (MTU) Size

IPsec connections cannot assemble fragmented packets. Therefore, a high MTU size can disrupt SecureConnect for the workloads running on that host.

Illumio recommends setting the MTU size at 1400 or lower when enabling SecureConnect for a workload.

Ports

Enabling SecureConnect for a workload routes all traffic for that workload through the SecureConnect connection using ports 500/UDP and 4500/UDP for NAT traversal and for environments where ESP traffic is not allowed on the network (for example, when using Amazon Web Services). You must allow 500/UDP and 4500/UDP to traverse your network for SecureConnect.

Unsupported SecureConnect Usage

SecureConnect is not supported in the following situations:

• SecureConnect cannot be used between a workload and unmanaged entities, such as the label “Any (0.0.0.0/0 and ::/0” (such as, the internet).
• SecureConnect is not supported on virtual services.
• SecureConnect is not supported on workloads in the Idle state. If you enable it for a rule that applies to workloads that are in both Idle and non-Idle enforcement, you can impact the traffic between these workloads.
• SecureConnect is not supported on AIX and Solaris platforms.

SecureConnect and Visibility Only state

When you configure workloads to use SecureConnect be aware of the following caveat.

SecureConnect encrypts traffic for workloads running in all enforcements except Idle. If misconfigured, you could inadvertently block traffic for workloads running in the Visibility Only enforcement state.

SecureConnect Host-to-Host Encryption

When you configure workloads to use SecureConnect be aware of the following caveat.

SecureConnect encrypts traffic between workloads on a host-to-host basis. Consider the following example.

In this example, it appears that enabling SecureConnect will only affect MySQL traffic. However, when you enable SecureConnect for a rule to encrypt traffic between a database workload and a web workload over port 3306, the traffic on all ports between the database and web workloads is protected by IPsec encryption.

Certificate Setup on Workloads

To use PKI certificates with SecureConnect, you must independently set up certificates on your Windows and Linux workloads.

Generate or obtain certificates from a trusted source in your organization. You should only use certificates obtained from trusted sources.

File Requirements

File	Requirements
Issuer's certificate	The global CA certificate, either root or intermediate, in PEM or DER format NOTE: On Linux, the issuer's certificate must be readable by the Illumio user.
pkcs12 container	Archive containing the public key, private key, and identity certificate generated for the workload host. Sign the identity certificate using the global root certificate. You can password protect the container and private key but do not password protect the public key.

Installation Locations

Windows Store

Use the Windows OS, for example Microsoft Management Console (MMC), to import the files into these locations of the local machine store (not into your user store).

• Root certificate: Trusted Root Certificate Store
• pkcs12 container: Personal ("My") certificate store

Linux Directories

Copy the files into the following Linux directories. (You cannot change these directories.)

• Root certificate: /opt/illumio_ven/etc/ipsed.d/cacert
• pkcs12 container: /opt/illumio_ven/etc/ipsed.d/private

Enable SecureConnect for a Rule

The following table lists the valid provider and consumer combinations for which you can enable SecureConnect:

Provider	Service	Consumer
Workload	Any service	Workload
All workloads	Any service	All workloads
Label/Label Group	Any service	Label/Label Group

SecureConnect is supported on workloads in Visibility Only and Full enforcement states.

1. From the PCE web console menu, choose Rulesets and Rules > Segmentation Ruleset.

   The Segmentation Rulesets page appears.

2. Create a new ruleset or open an existing one. See Segmentation Rulesets for information.
3. In the ruleset, select the Scopes and Rules tab.
4. If necessary create an intra-scope or an extra-scope rule. See Rule Writing for information. To edit an existing rule, click the edit icon at the end of the row.
5. To enable SecureConnect for the rule, select SecureConnect from the Providing Service drop-down list.
6. Click the Save icon at the end of the row.
7. To apply the changes to the applicable workloads, provision the changes. See Provision Changes for information.

When you enable SecureConnect for a rule, the PCE duplicates symmetrical encryption for both sides of the connection.