How to Secure Traffic Between Two Systems

This procedure assumes the following setup:

• The two systems are named enigma and partym. Substitute the names of your systems when following this procedure.

• Each system has two addresses, an IPv4 address and an IPv6 address.

• Each system invokes AH protection with the MD5 algorithm, which requires a key of 128 bits.

• Each system invokes ESP protections with the 3DES algorithm, which requires a key of 192 bits.

• IPsec uses shared security associations (SAs).

  With shared SAs, only one pair of SAs is needed to protect the two systems.

1. On the system console, become superuser or assume an equivalent role.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session.

   ---

2. On each system, add the addresses and host name for the other system in the /etc/inet/ipnodes file. The entries for one system must be contiguous in the file.

   If you are connecting systems with IPv4 addresses only, you modify the /etc/inet/hosts file.

   1. On a system that is named partym, type the following in the ipnodes file:

      # Secure communication with enigma 192.168.116.16 enigma fec0::10:20ff:fea0:21f6 enigma

   2. On a system that is named enigma, type the following in the ipnodes file:

      # Secure communication with partym 192.168.13.213 partym fec0::9:a00:20ff:fe7b:b373 partym

   This step enables the boot scripts to use the system names without depending on nonexistent naming services.

3. On each system, create the file /etc/inet/ipsecinit.conf.

   You can copy the file /etc/inet/ipsecinit.sample to the file /etc/inet/ipsecinit.conf.

4. Add the IPsec policy entry to the ipsecinit.conf file.

   1. On the enigma system, add the following policy to the ipsecinit.conf file:

      {laddr enigma raddr partym} ipsec {auth_algs any encr_algs any sa shared}

   2. On the partym system, add the same policy to its ipsecinit.conf file:

      {laddr partym raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

      For the syntax of IPsec policy entries, see the ipsecconf(1M) man page.

5. On each system, add a pair of IPsec SAs between the two systems.

   You can configure Internet Key Exchange (IKE) to create the SAs automatically. You can also add the SAs manually.

   ---

   Note –

   You should use IKE unless you have good reason to generate and maintain your keys manually. IKE key management is more secure than manual key management.

   ---

   • Configure IKE by following one of the configuration procedures in Configuring IKE (Task Map). For the syntax of the IKE configuration file, see the ike.config(4) man page.

   • If you are going to add the SAs manually, see How to Manually Create IPsec Security Associations.

6. Reboot each system.

   # /usr/sbin/reboot

7. Verify that packets are being protected. See How to Verify That Packets Are Protected.

Example—Securing Traffic Between Systems Without Rebooting

The following example describes how to test that the traffic between two systems is secure. In a production environment, it is safer to reboot than to run the ipsecconf command.

Instead of rebooting at Step 5 of How to Secure Traffic Between Two Systems, do one of the following options.

• If you used IKE to create keying material, stop and then restart the in.iked daemon.

  # pkill in.iked # /usr/lib/inet/in.iked

• If you added keys manually, use the ipseckey command to add the SAs to the database. Then activate the IPsec policy with the ipsecconf command.

  # ipseckey -f /etc/inet/secret/ipseckeys # ipsecconf -a /etc/inet/ipsecinit.conf

Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, the socket is in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf.