Understanding IPsec

What IPsec is

IPsec is a security protocol suite that protects data from unauthorized disclosure when it is being transmitted between storage systems and clients. Using IPsec, you can add policies on your storage system that do both of these things:

Configure encryption and authentication algorithms between your storage system and client.
Policies can be configured from your storage system to the client and from the client to your storage system over a range of IP addresses and ports.
Negotiate a security association (SA) between the two end-stations (systems that initiate and receive secure communications). The SA is used for secure data exchanges between your storage system and the client.
Note
Maintaining security is processor intensive. However, storage system security processing can be offloaded from the CPU to an IPsec accelerator adapter. For more information, see L Larval (uninitiated).

About security associations

A security association (SA) is an authenticated simplex (uni-directional) data connection between two end-stations. Security configurations are typically configured in pairs. An SA has all of the following:

A unique Security Parameter Index (SPI) number
An IP destination address
An IPsec security protocol
The IPsec security protocol must be either of the following:
- Authentication Header (AH)
  The AH protocol inserts an authentication header into each packet before the data payload. The authentication header includes a checksum created with a cryptographic hash algorithm, either Message Digest function 95 (MD5 - 128 bit key) or Secure Hash Algorithm (SHA - 160 bit key). The AH protocol does not alter the packet's data payload.
- Encapsulating Security Payload (ESP)
  The ESP protocol inserts a header before the data payload and a trailer after it. When you specify an encryption algorithm, either Data Encryption Standard (DES) or triple DES, ESP alters the data payload by encrypting it. Alternatively, you can specify packet authentication using the same MD5 or SHA-1 algorithms that are available with the AH protocol. If you use the ESP security protocol, you need to specify either authentication or encryption, or both.
  
  Note
  When you specify the AH protocol, only packet authentication (providing data integrity) is enabled. When you specify the ESP protocol, both packet authentication and packet encryption (providing data privacy) can be enabled.

At least two security associations, inbound and outbound, are required between end-stations. Security associations are stored in the Security Association Database (SAD) when IPsec is enabled on an end-station.

Security associations are created from security policies.

About security policies

Security associations are created based on information collected in security policies, which determine how security is handled in a transfer of information. Security policies can include any of the following types of specifications:

The source and destination addresses (or ranges of addresses) of the end-stations (storage system and client)
Packet authentication methods
Packet encryption methods
Restrictions on ports and services
Whether inbound and outbound SAs are mirrored
Strictness of policy application

Security policies are stored in the Security Policy Database (SPD) when IPsec is enabled on an end-station. Matching security policies must be configured on your storage system and clients.

About key exchange

An IPsec SA is negotiated by means of the key management protocol IKE (Internet Key Exchange). Phase 1 of an IKE key exchange authenticates the identity of the end-stations, which allows the establishment of an IPsec SA in Phase 2.

Two key exchange mechanisms using IKE are supported between storage systems and clients: Kerberos and preshared keys. However, only preshared keys can be used between two storage systems.

Kerberos is a network authentication system in which end-stations prove their identity by obtaining identical secret keys from a Key Distribution Center (KDC), the Kerberos security server. For Windows 2000 and later, the KDC is located on the Windows domain controller, which processes IKE authentication requests for storage systems and Windows clients in the domain.
Kerberos authentication is enabled automatically when CIFS is licensed and configured on your storage system.
Preshared keys are identical ASCII text strings entered manually on each end-station. Authentication is validated when IKE successfully compares the hash value of the two keys. Preshared key configuration is simple, but it requires manual management on each end-station. Also, preshared keys are static and persistent, therefore vulnerable unless changed frequently.
Note
The authentication of end-station identity provided by the key exchange protocol IKE is different from the packet integrity authentication provided by the IPsec protocols AH and ESP.

About the Data ONTAP IPsec implementation

The IPsec implementation for Data ONTAP conforms to the Internet Engineering Task Force (IETF) Security Architecture for the Internet Protocol (RFC 2401) and related protocols. The following restrictions apply:

By default, storage systems obey all IPsec parameters that are configured on clients.
The only exception is Perfect Forward Secrecy (PFS), which is not supported on storage systems.
Only transport mode is supported on storage systems; tunnel mode is not supported.
Consequently, IPsec is supported for security associations between storage systems and clients, but it is not supported for security associations between storage systems and security gateways.
Only clients running Solaris or Windows 2000 or later are supported for IPsec connections.
The following authentication mechanisms are supported:
- For Solaris--only preshared keys authentication
- For Windows--preshared keys and Kerberos authentication; however, Kerberos authentication is available only for Windows Domains, not Windows Workgroups
- Between storage systems--only preshared keys authentication
Data ONTAP supports preshared keys and Kerberos key exchange mechanisms, but it cannot be configured to use a specific mechanism. Instead, Data ONTAP relies on the client to specify which key exchange mechanism to use.
You cannot configure parameters associated with SA, for example, how long the SA is valid, how many bytes of data can pass through the SA, in Data ONTAP. Instead, Data ONTAP uses the parameters that the client provides.

For more information about implementation and standards, see the na_ipsec(1) man page.

IPsec in a cluster configuration

The IPsec protocol, by its nature, does not work well in a failover environment, that is, an environment in which one storage system in a cluster configuration must take over the other storage system. This is because security policies, but not security associations, are taken over from the failed storage system. Clients will continue to send packets to the failed client for the remainder of the client security association lifetime, after which a new security association must be renegotiated and dropped packets resent.

For this reason, you are advised to reduce the security association lifetime to a minimum value to optimize IPsec operation in a cluster configuration. This minimizes the time clients use to destroy their security associations and negotiate new ones with the storage system that took over.

Note
You set the value of the security association's lifetime on clients rather than on your storage system.

IPsec in a vFiler unit configuration

IPsec can be enabled on a per-vFiler unit basis, with distinct security policies for each vFiler unit. IPsec configuration is preserved when vFiler units are moved from one hosting storage system to another, unless the vFiler unit's IP address is changed.

IPsec configuration can be set within the context of a vFiler unit or at your storage system command line by using the vfiler run command.

Note
Policies and configurations discussed in this chapter must be set individually for each vFiler unit.