Contents | Previous | Next

z/OS IP Security (IPSec) Performance Workload

This workload is actually an implementation of the z/OS SSL Performance Workload with the addition of IPSec processing. The application layer is not aware of IPSec processing, because IPSec processing is totally handled by the IP Layer of the TCP/IP stack. This combination of SSL and IPSec drives work to the zIIPs.

The z/OS Communications Server lets portions of IPSec processing run on zIIPs. This feature, called "zIIP-Assisted IPSec", lets Communication Server interact with z/OS Workload Manager to have its enclave Service Request Block (SRB) work directed to zIIPs. Within z/OS V1R9 Communications Server, much of the processing related to security routines, such as encryption and authentication algorithms and AH|ESP protocol overhead, runs in enclave SRBs, and this enclave SRB workload can be directed to available zIIPs. With zIIP-Assisted IPSec, the zIIPs, in effect, become encryption engines. In addition to performing encryption processing, zIIPs also handle cryptographic validation of message integrity and IPSec header processing. The zIIPs, in effect, are high-speed IPSec protocol processing engines that provide better price-performance for IPSec processing.

IPSec is a suite of protocols and standards defined by the Internet Engineering Task Force (IETF) to provide an open architecture for security at the IP networking layer of TCP/IP. IPSec provides the framework to define and implement network security based on policies defined by an organization. IPSec is used to create highly secure connections between two points in an enterprise - this may be server-to-server, or server to network device, as long as they support the IPSec standard. Using IPSec to provide end-to-end encryption helps provide a highly secure exchange of network traffic.

The Authenticated Header (AH) protocol is the IPSec-related protocol that provides authentication. The Encapsulated Security Payload (ESP) protocol provides data encryption, which conceals the content of the payload. ESP also offers authentication. Internet Key Exchange (IKE) protocol exchanges the secret number that is used for encryption or decryption in the encryption protocol.

AH and ESP support two mode types: transport mode and tunnel mode. These modes tell IP how to construct the IPSec packet. Transport mode is used when both endpoints of the tunnel are hosts (data endpoints). Tunnel mode is used whenever either endpoint of the tunnel is a router or firewall.

With transport mode, the IP header of the original transmitted packet remains unchanged.

With tunnel mode, a new IP header is constructed and placed in front of the original packet.

Some of the key IPSec parameters which can be controlled via the Policy file are:

IpDataOffer The IpDataOffer statement defines how to protect data sent through a dynamic VPN.

  • HowToEncap The desired encapsulation mode of the security association.
    • Tunnel Specifies that the security association operates in tunnel mode, which protects the entire IP packet. This mode must be used for a secure tunnel between two security gateways or between a security gateway and a remote system. One or both of the communication endpoints can be on different systems than the security endpoints.
    • Transport Specifies that the security association operates in transport mode, which protects only the transport-layer headers and data (that is, TCP or UDP packet) inside an IP packet. This mode can be used only when the endpoints of the security association are the two communicating systems (for example, neither system acts as a gateway).
  • HowToEncrypt Encryption is done using the ESP protocol. Specify the encryption algorithm used to provide data confidentiality. The default is DES.
    • DES DES encryption is used with a 56-bit key and a 64-bit initialization vector.
    • 3DES Triple DES executes the DES encryption algorithm three times and uses 192-bits, including 24 parity bits.
      • Rule: If 3DES is specified but is not supported by the system, the Policy Agent fails the policy.
    • AES The Advanced Encryption Standard (AES) algorithm is used with a 128-bit key.
      • Rule: If AES is specified but AES encryption is not supported by TCP/IP, Policy Agent fails the policy.
    • DoNot No encryption is used. If the HowToEncrypt value DoNot is specified with a HowToAuth ESP value, the ESP header is present, but the payload is not encrypted (ESP_NULL).
  • HowToAuth The desired authentication policy indicating which protocol and which algorithm to use when authenticating data. The default is ESP Hmac_Md5.
    • AH Carry authentication in AH headers.
    • ESP Carry authentication in ESP headers.
    • Hmac_Md5 Use the Hmac_Md5 algorithm to encode authentication data in either AH or ESP headers.
    • Hmac_Sha Use the Hmac_Sha algorithm to encode authentication data in either AH or ESP headers.

KeyExchangeOffer The KeyExchangeOffer statement defines how to change offer for a dynamic VPN. A key exchange offer indicates one acceptable way to protect a key exchange for a dynamic VPN.

  • HowToEncrypt The desired encryption policy for protecting key exchanges. The default is DES.
    • DES Use DES encryption, which utilizes a 56-bit key and a 64-bit initialization vector.
    • 3DES Triple DES executes the DES encryption algorithm three times and uses 192-bits, including 24 parity bits.
      • Rule: If 3DES is specified but is not supported by the system, then the Policy Agent fails the policy.
    • AES The Advanced Encryption Standard (AES) algorithm is used with 128-bit cryptographic key.
      • Rule: If AES is specified but AES encryption is not supported by TCP/IP, Policy Agent fails the policy.
  • HowToAuthMsgs The desired hash algorithm for authenticating key exchange messages. The default is MD5.
    • MD5 Use the MD5 algorithm.
    • SHA1 Use the SHA1 algorithm.
  • HowToAuthPeers Specifies the method for authenticating peers during phase 1 negotiation.
    • PresharedKey Use a pre-shared key to authenticate the peer.
    • RsaSignature Use an RSA signature to authenticate the peer.
  • DHGroup Specifies the Diffie-Hellman group used during the phase 1 key exchange. The default is Group1.
    • Group1 Modular exponentiation group with a 768-bit modulus.
    • Group2 Modular exponentiation group with a 1024-bit modulus.
    • Group5 Modular exponentiation group with a 1536-bit modulus.
    • Group14 Modular exponentiation group with a 2048-bit modulus.
    • Guideline: If AES encryption is used, use Diffie-Hellman Group 5 or 14.

KeyExchangeRule An IKE SA establishment might be initiated from the local system or from a remote system, and it involves several message exchanges. Depending on the initiator/responder state, and the message sequence, the IKE daemon locates a KeyExchangeRule statement to govern the policy that is used during the negotiation.

  • SharedKey The shared key to use with the LocalSecurityEndpoint statement and RemoteSecurityEndpoint statement pair when using a pre-shared key for authentication. The shared key can be specified as an ASCII string, an EBCDIC string, or a hexadecimal string. The maximum length for an ASCII or EBCDIC string is 900 characters. The maximum length for a hexadecimal string is 450 bytes. The hexstring must begin with a 0x.
    • Examples:
    • SharedKey Ascii SharedKeyValue The value is treated as an ASCII string. This specification is valuable if the sharedkey has been defined to the other endpoint as an ASCII string.
    • SharedKey Ebcdic SharedKeyValue The value is treated as an EBCDIC string.
    • SharedKey Hex 0xC1C2C3F1F2F3 The value is treated as a hexadecimal string.

Contents | Previous | Next