How to encrypt Enterprise Extender connections

You can encrypt your Ente3rprise Extender (EE) connections. The two options available for encryption of Enterprise Extender connections are:

• IPSec

• SNA session level encryption (SLE)

 

IPSec for EE Security

IPSec is a set of protocols which provide security for IP traffic between two hosts. The hosts create an IPSec tunnel by establishing a Security Association (SA) which defines how to encapsulate/decapsulate the data. IPSec supports two protocols:

 

• Authentication Header (AH), which provides authentication for the data in an IP packet

• Encapsulating Security Payload (ESP), which provides encryption for the data in an IP packet

.

You can use IPSec to encrypt EE sessions, as discussed in the SNA Network Implementation Guide in Chapter 6, under the topic "IP Security (IPSec)" . See also "HPR/IP EE Security Functions" in section 1.4.3 Functions of HPR/IP (EE) of the Enterprise Extender Implementation Guide. (SG24-7359-00).

You will find a step by step procedure for implementing IPSec in Chapter 8. IP Security of IBM z/OS V2R2 Communications Server TCP/IP Implementation Volume 4: Security and Policy-Based Networking: An IBM Redbooks publication.

 

We suggest the use of the IPSec Encapsulating Security Payload (ESP) protocol within IPSec for both encrypting and authenticating data over any insecure link. According to section 8.2.3 IP Encapsulating Security Payload protocol, in IBM z/OS V2R2 Communications Server TCP/IP Implementation Volume 4: Security and Policy-Based Networking: An IBM Redbooks publication , "In ESP, before leaving a host, outbound packets are rebuilt with additional IPSec headers using a cryptographic key that is known to both communicating hosts. This is called encapsulation. On the receiving side, the inbound packets are stripped of their IPSec headers (decapsulated) using the same cryptographic key, thereby recovering the original packet. Any packet that is intercepted on the IP network is unreadable to anyone without the encryption key. Any modifications to the IP packet while in transit are detected by authentication processing at the receiving host and is discarded."

After completing implementation of IPSec to secure your Enterprise Extender connections, follow the procedure Steps for verifying IP security and defensive filter operation in Chapter 29 of the IP Diagnosis Guide .

The section MTU Size Considerations with EE in Enterprise Extender Implementation Guide states:

"Attention: IPSec adds additional ESP and AH headers to each IP packet, therefore enlarging the size of the original IP datagram in the WAN. If the resulting IPSec datagram exceeds the MTU size of the next hop, it will have to be fragmented. Some devices will not route fragmented packets for security reasons causing retransmissions at RTP layer. Unfortunately the retransmitted NLPs will suffer the same death and the HPR pipe will be stalled. If EE traffic is traversing IPSec tunnels, we recommend reducing the MTU size toward the destination host to 1420 to accommodate the increase of the packet size caused by IPSec. See the IPSec discussions in z/OS Communications Server: IP Configuration Guide (SC31-8775)."

For more information on how to use IPSec to encrypt Enterprise Extender connections on z/OS systems, see the IBM Techdoc "Using IPSec to secure Enterprise Extender demo ".

For information on how to use IPSec to encrypt Enterprise Extender connections on AIX, Linux, and Windows systems, see the following links: (Note: This is not an exhaustive list, nor is it an endorsement for the referenced sites or products. This is just a list of some example documentation for configuring IP Sec on Linux, and Windows):

• • OpenSwan (IPSec on Linux)

  • Windows: IPSec

  • Step-by-Step Guide to Internet Protocol Security (IPSec)

  • "Configuring IPSec between z/OS and Windows" (Appendix C), in IBM z/OS V2R2 Communications Server TCP/IP Implementation Volume 4: Security and Policy-Based Networking: An IBM Redbooks publication.

SNA Session Level Encryption (SLE) for EE Security

The Enterprise Extender Implementation Guide (SG24-7359-00) points out that "SNA Session Level Encryption (SLE) is provided by the z/OS Cryptography Facility. Logmodes can be set up to require encryption so any application using those logmodes would encrypt session data. This allows data to and from specific applications to be encrypted rather than the connection level encryption provided by IPSEC."

Some tests have indicated that using IPSec can have a negative impact on large FTP file transfers.  In this situation, we recommend implementing VTAM SLE. See also "Compatibility with IPSec and SNA Session Level Encryption (SLE)" in Section 1.3.2 Benefits of Using EE in the Enterprise Extender Implementation Guide (SG24-7359-00).

As stated in the z/OS Communications Server: SNA Network Implementation Guide, in Chapter 6 under Providing encryption, if you use SNA session level encryption, use the filtering rule on the EE UDP port to allow traffic to flow without subsequent IPSec encryption. You can also use a combination of SNA encryption and IPSec authentication, where IPSec authentication is designed using filter rules on the same EE UDP port.

VTAM session level encryption (SLE) requires the hardware cryptographic function of the GA2
PCIX Cryptographic Coprocessor ( PCIXCC ). The hardware card is required for this function.

VTAM has two options for session level encryption:

• End-to-end cryptography
• Host-by-host cryptography

In end-to-end cryptography, one end node (EN) files encryption keys with its network node (NN) server, and that NN files encryption keys with the partner application VTAM. (See the topic End-to-end cryptography in Chapter 13 of the  z/OS V2r3.0 Communications Server: SNA Network Implementation Guide.)

In host-by-host cryptography, encryption is required in all hosts on the session path. (See the topic Host-by-host cryptography in Chapter 13 of the z/OS V2R3.0 Communications Server: SNA Network Implementation Guide.)

For more information on SNA session level encryption, see:

"Implementing cryptography for LU-LU session data" in Chapter 13 of the z/OS V2R3.0 Communications Server: SNA Network Implementation Guide.

• Technote VTAM Session Level Encryption and Central Processor Assist for Cryptographic Function (CPACF) .
• Technote Performance degradation with session level encryption

Communications Server for Windows supports SLE, but Communications Server for AIX and Communications Server for Linux do not. For information on configuring CS/WIN for SLE, see the Network Administration Guide at the CS/WIN library .

VTAM SLE provides encryption but not authentication, whereas IPSec provides both.