How to Secure Traffic Between Two Systems

This procedure assumes the following setup:

• 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

  With shared security associations, 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 total 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.

   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

      These names are examples only. Use the names of your systems when securing traffic between your systems.

   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 /etc/inet/ipsecinit.conf.

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

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

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

   2. On partym, 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 security associations between the two systems.

   On each system, edit a read-only /etc/inet/secret/ipseckeys file. A read-only file has permissions of 400. A pair of security associations for ESP and AH protection has the following format in the ipseckeys file:

   add protocol spi random-hex-string dst local-system \ encr_alg protocol-algorithm \ encrkey random-hex-string-of-algorithm-specified-length add protocol spi random-hex-string dst local-system \ auth_alg protocol-algorithm \ authkey random-hex-string-of-algorithm-specified-length add protocol spi random-hex-string dst remote-system \ encr_alg protocol-algorithm \ encrkey random-hex-string-of-algorithm-specified-length add protocol spi random-hex-string dst remote-system \ auth_alg protocol-algorithm \ authkey random-hex-string-of-algorithm-specified-length

   protocol	One of esp or ah. The ah protocol uses auth_alg and authkey arguments. The esp protocol uses encr_alg and encrkey arguments. esp also uses the auth_alg and authkey arguments that ah uses.
   random-hex-string	Random number of up to eight characters in hexadecimal format. If you enter more numbers than the SPI accepts, the system ignores the extra numbers. If you enter fewer numbers than the SPI accepts, the system pads your entry.
   local-system	Name of the local system
   remote-system	Name of the remote system
   protocol-algorithm	An algorithm for ESP or AH. Each algorithm requires a key of a specific length.  Authentication algorithms include MD5 and SHA. Encryption algorithms include 3DES and AES.
   random-hex-string-of-algorithm-specified-length	A random hexadecimal number of the length that is required by the algorithm. For example, the MD5 algorithm requires a 32–character string for its 128–bit key. The 3DES algorithm requires a 48–character string for its 192–bit key.

   1. Generate the random numbers.

      You need three random numbers for outbound traffic, and three random numbers for inbound traffic. Therefore, you need the following for each system:

      • Two hexadecimal random numbers as the value for the spi keyword. One number is for outbound traffic, one number is for inbound traffic. Each number can be up to eight characters long.

      • Two hexadecimal random numbers for the MD5 algorithm for AH. Each number must be 32 characters long. One number is for dst enigma, one number is for dst partym.

      • Two hexadecimal random numbers for the 3DES algorithm for ESP. For a 192-bit key, each number must be 48 characters long. One number is for dst enigma, one number is for dst partym.

      If you have a random number generator at your site, use the generator. You can also use the od command. See How to Generate Random Numbers for the procedure.

   2. For example, on enigma, the ipseckeys file might look like the following:

      # for inbound packets add esp spi c83f5a4b dst enigma encr_alg 3DES \ encrkey b6a8f89213a796bde03c601029861eae91c65783368165a6 # add ah spi 2f526ae6 dst enigma auth_alg MD5 authkey 305ec56369ca62c2ae804690c5713e18 # for outbound packets add esp spi 0cecc4b2 dst partym encr_alg 3DES \ encrkey 802e89f9f9b929ea2b615641b71ac7034a540d3cbeeaf6a9 # add ah spi a75bbe5f dst partym auth_alg MD5 \ authkey 2ae8b94967e6b9b0dd16e6d4b7ea7278

   3. The ipseckeys on partym uses identical keys. The comments differ, because dst enigma is inbound on enigma, and outbound on partym:

      # for outbound packets add esp spi c83f5a4b dst enigma encr_alg 3DES \ encrkey b6a8f89213a796bde03c601029861eae91c65783368165a6 # add ah spi 2f526ae6 dst enigma auth_alg MD5 authkey 305ec56369ca62c2ae804690c5713e18 # for inbound packets add esp spi 0cecc4b2 dst partym encr_alg 3DES \ encrkey 802e89f9f9b929ea2b615641b71ac7034a540d3cbeeaf6a9 # add ah spi a75bbe5f dst partym auth_alg MD5 \ authkey 2ae8b94967e6b9b0dd16e6d4b7ea7278

   ---

   Note –

   The keys and SPI can be different for each security association. You should assign different keys and a different SPI for each security association.

   ---

6. Reboot.

   # /usr/sbin/reboot

7. To verify that packets are being protected, see How to Verify That Packets are Protected.

Example—Securing Traffic Between IPv6 Addresses Without Rebooting

The following example describes how to test that you can secure traffic between systems with IPv6 addresses. In a production environment, to reboot is safer than to run the ipsecconf command.

1. Do the procedure How to Secure Traffic Between Two Systems through Step 5.

2. Instead of rebooting, use the ipseckey command to add the security associations to the database.

   # ipseckey -f /etc/inet/secret/ipseckeys

3. Activate IPsec policy with the ipsecconf command:

   # ipsecconf -a /etc/inet/ipsecinit.conf

   ---

   Note –

   Read the warning when you execute the command. A socket that is already in use (latched) provides an unsecured back door into the system.

   ---

Example—Securing Traffic Between IPv4 Addresses

The following example describes how to secure traffic between systems with IPv4 addresses. The example uses automatic key management (IKE) to create security associations. IKE requires less administrative intervention, and scales easily to secure a large amount of traffic.

1. Replace the /etc/inet/ipnodes file in Step 2 of the preceding task with the /etc/hosts file, as in the following:

   On the partym system, add enigma to the /etc/hosts file:

   # echo "192.168.116.16 enigma" >> /etc/hosts

   On the enigma system, add partym to the /etc/hosts file:

   # echo "192.168.13.213 partym" >> /etc/hosts

2. Edit the ipsecinit.conf file to add the IPsec policy entries as in Step 4.

3. You can create keys in one of two ways:

   • Configure IKE to generate the keys automatically. IKE also refreshes the keys automatically. To configure IKE, follow one of the configuration procedures in Table 4–1. For the syntax of the IKE configuration file, see the ike.config(4) man page.

     You should configure IKE unless you have good reason to generate and maintain your keys manually.

   • If you do not activate the IKE daemon, in.iked, then you can manually create the keys, as described in Step 5 in How to Secure Traffic Between Two Systems.

4. Reboot.

   To secure traffic without rebooting, use the ipseckey and ipsecconf commands.

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

   ---

   Note –

   Read the warning when you execute the command. A socket that is already in use (latched) provides an unsecured back door into the system.

   ---

5. To verify that packets are being protected, see How to Verify That Packets are Protected.