|
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
|