IPsec Tasks

This section provides procedures that enable you to secure traffic between two systems, secure a Web server, and set up a virtual private network. The system names enigma and partym are examples only. Substitute the names of your systems for the names enigma and partym.

For information on how to use roles to administer IPsec, see “Role-Based Access Control (Tasks)” in System Administration Guide: Security Services.

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.

How to Secure a Web Server

A secure Web server allows web clients to talk to the Web service. On a secure Web Server, traffic that is not Web traffic must pass security checks. The following procedure includes bypasses for Web traffic. In addition, this Web server can make non-secured DNS client requests. All other traffic requires ESP with Blowfish and SHA-1 algorithms. Other traffic also uses a shared SA for outbound traffic. Shared SAs reduce the number of security associations that must be generated.

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. Determine which services need to bypass security policy checks.

   For a Web server, these services include TCP ports 80 (HTTP) and 443 (Secure HTTP). If the Web server provides DNS name lookups, the server might also need to include port 53 for both TCP and UDP.

3. Create a file in the /etc/inet/ directory for the Web server policy. Give the file a name that indicates its purpose, for example IPsecWebInitFile. Type the following lines in this file:

   # Web traffic that Web server should bypass. {sport 80 ulp tcp} bypass {dir out} {dport 80 ulp tcp} bypass {dir in} {sport 443 ulp tcp} bypass {dir out} {dport 443 ulp tcp} bypass {dir in} # Outbound DNS lookups should also be bypassed. {dport 53} bypass {dir out} {sport 53} bypass {dir in} # Require all other traffic to use ESP with Blowfish and SHA-1. # Use a shared SA for outbound traffic, in order to avoid a # large supply of security associations. {} permit {encr_algs blowfish encr_auth_algs sha} {} apply {encr_algs blowfish encr_auth_algs sha sa shared}

   This configuration enables only secure traffic to access the system, with the bypass exceptions that are described in the previous step.

4. Read the file that you created in the previous step into /etc/inet/ipsecinit.conf.

   # vi /etc/inet/ipsecinit.conf :r IPsecWebInitFile :wq!

5. Protect the IPsecWebInitFile file with read-only permissions.

   # chmod 400 IPsecWebInitFile

6. To secure the web server 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.

   ---

   You can also reboot. Rebooting ensures that IPsec policy is in effect on all TCP connections. At reboot, the TCP connections latch policy according to the policy in the IPsec policy file.

The Web server now allows only Web-server traffic, as well as outbound DNS requests and replies. No other services work without enabling IPsec on a remote system.

If you want a remote system to communicate securely with the Web server for non-Web traffic, their policies must match. The following policy in a remote system's ipsecinit.conf file enables the system to communicate with the Web server:

# Communicate with Web server about non-Web stuff
#
	{} permit {encr_algs blowfish encr_auth_algs sha}
	{} apply {encr_algs blowfish encr_auth_algs sha sa shared}

How to Set Up a Virtual Private Network

This procedure shows you how to set up a VPN by using the Internet to connect two networks within an organization. The procedure then shows you how to secure the traffic between the networks with IPsec.

This procedure extends the procedure, How to Secure Traffic Between Two Systems. In addition to connecting two machines, you are connecting two intranets that connect to these two machines. The machines in this procedure function as gateways.

The procedure assumes the following setup:

• Each system is using an IPv4 address space.

• Each system has two interfaces. The hme0 interface connects to the Internet. In this example, Internet IP addresses begin with 192.168. The hme1 interface connects to the company's LAN, its intranet. In this example, intranet IP addresses begin with the number 10.

• Each system invokes AH protection with the MD5 algorithm. The MD5 algorithm requires a 128-bit key.

• Each system invokes ESP protection with the 3DES algorithm. The 3DES algorithm requires a 192-bit key.

• Each system can connect to a router that has direct access to the Internet.

• IPsec uses shared security associations.

For a description of VPNs, see Virtual Private Networks. The following figure describes the VPN that this procedure configures.

This procedure uses the following configuration parameters:

1. On the system console on one of the systems, 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. Turn off IP forwarding:

   # ndd -set /dev/ip ip_forwarding 0

   Turning off IP forwarding prevents packets from being forwarded from one network to another network through this system. For a description of the ndd command, see the ndd(1M) man page.

3. Turn on IP strict destination multihoming:

   # ndd -set /dev/ip ip_strict_dst_multihoming 1

   Turning on IP strict destination multihoming ensures that packets for one of the system's destination addresses arrive at the correct destination address.

   When you use the ndd command to turn off IP forwarding and turn on IP strict destination, fewer packets flow through the system. Multihoming shuts down the flow of packets except for packets that are going to system addresses. For system addresses, multihoming delivers only packets that arrive on the interface that corresponds to the destination IP address.

4. Disable most network services, and possibly all network services, on the Solaris system by doing the following substeps, as needed:

   1. Edit the inetd.conf to remove all but essential services, and then type the following command:

      # pkill -HUP inetd

      ---

      Note –

      The VPN router should allow very few incoming requests. You need to disable all processes that accept incoming traffic. For example, you might comment out lines in the inetd.conf file, you might kill SNMP, and so on. Alternately, you can use techniques that are similar to the techniques in How to Secure a Web Server.

      ---

   2. If inetd.conf has not been edited to remove all but essential services, type the following command on a command line:

      # pkill inetd

   3. Disable other Internet services, such as SNMP, NFS, and so on, by typing one or more commands such as the following examples, as needed:

      # /etc/init.d/nfs.server stop # /etc/init.d/sendmail stop

      The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, telnet, or rlogin could be exploited.

5. On each system, add a pair of security associations between the two systems.

   The IKE daemon automatically creates the security associations that you configure IKE to create. You can use one of the following procedures to configure IKE for the VPN:

   • How to Configure IKE With Pre-Shared Keys

   • How to Configure IKE With Self-Signed Public Certificates

   • How to Configure IKE With Public Keys Signed by a Certificate Authority

   If the systems are using IPv6 addresses, you must manually create the security associations. For the steps, see How to Create IPsec Security Associations Manually.

6. On each system, edit the /etc/inet/ipsecinit.conf file to add the VPN policy.

   1. For example, on enigma, type the following entries into the ipsecinit.conf file:

      # LAN traffic can bypass IPsec. {laddr 10.16.16.6 dir both} bypass {} # WAN traffic uses ESP with 3DES and MD5. {} ipsec {encr_algs 3des encr_auth_algs md5}

   2. For example, on partym, type the following entries into the ipsecinit.conf file:

      # LAN traffic can bypass IPsec. {laddr 10.1.3.3 dir both} bypass {} # WAN traffic uses ESP with 3DES and MD5. {} ipsec {encr_algs 3des encr_auth_algs md5

   The ipsec entry prevents remote systems from sending clear packets. The bypass entry allows nodes that are part of the LAN to treat the VPN router as if the router is part of the LAN.

7. (Optional) For a higher level of security, remove the LAN bypass entry.

   The entry in ipsecinit.conf would look like the following:

   # All traffic uses ESP with 3DES and MD5. {} ipsec {encr_algs 3des encr_auth_algs md5}

   Each system on the LAN would then need to activate IPsec to communicate with the VPN router.

8. On each system, configure a secure tunnel, ip.tun0.

   The tunnel adds another physical interface from the IP perspective. Type three ifconfig commands to create the point-to-point interface:

   # ifconfig ip.tun0 plumb # ifconfig ip.tun0 system1-point system2-point \ tsrc system1-taddr tdst system2-taddr encr_algs 3DES encr_auth_algs MD5 # ifconfig ip.tun0 up

   1. For example, on enigma, type the following commands:

      # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 encr_algs 3DES encr_auth_algs MD5 # ifconfig ip.tun0 up

   2. For example, on partym, type the following commands:

      # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16 encr_algs 3DES encr_auth_algs MD5 # ifconfig ip.tun0 up

   The policy that is passed to the ifconfig commands must be the same as the policy in the ipsecinit.conf file. Upon reboot, each system uses the policy in its ipsecinit.conf file.

9. On each system, turn on ip_forwarding for the hme1 and ip.tun0 interfaces.

   # ndd -set /dev/ip hme1:ip_forwarding 1 # ndd -set /dev/ip ip.tun0:ip_forwarding 1

   ip_forwarding means that packets that arrive from somewhere else can be forwarded. ip_forwarding also means that packets that leave this interface might have originated somewhere else. To successfully forward a packet, both the receiving interface and the transmitting interface must have ip_forwarding turned on.

   Because the hme1 interface is inside the Intranet, ip_forwarding must be turned on for hme1. Because ip.tun0 connects the two systems through the Internet, ip_forwarding must be turned on for ip.tun0.

   The hme0 interface has its ip_forwarding turned off to prevent an outside adversary from injecting packets into the protected Intranet. The outside refers to the Internet.

10. On each system, ensure that routing protocols do not advertise the default route within the Intranet:

    # ifconfig hme0 private

    Even if hme0 has ip_forwarding turned off, a routing protocol implementation might still advertise the interface. For example, the in.routed protocol might still advertise that hme0 is available to forward packets to its peers inside the Intranet. Your setting the interface's private flag prevents these advertisements.

11. Manually, add a default route over hme0.

    This route should be a router with direct access to the Internet.

    # pkill in.rdisc # route add default router-on-hme0-subnet

    1. For example, on enigma, add the following route:

       # pkill in.rdisc # route add default 192.168.116.4

    2. On partym, add the following route:

       # pkill in.rdisc # route add default 192.168.13.5

       Even though the hme0 interface is not part of the Intranet, hme0 does need to reach across the Internet to its peer system. To find its peer, hme0 needs information about Internet routing. The VPN system looks like a host, rather than a router, to the rest of the Internet. Therefore, you can use a default router or run the router discovery protocol to find a peer system. For more information, see the route(1M) and in.routed(1M) man pages.

12. Ensure that hme0 uses the default route after a reboot by creating a defaultrouter file.

    Put the IP address of hme0's default router in the/etc/defaultrouter file. This step prevents the in.rdisc daemon from being started at reboot.

    1. For example, on enigma, put its Internet router in the /etc/defaultrouter file:

       # vi /etc/defaultrouter 192.168.116.4 router-E

    2. Put partym's Internet router in partym's /etc/defaultrouter file:

       # vi /etc/defaultrouter 192.168.13.5 router-C

13. On each system, prevent routing from occurring early in the boot sequence, and thus reduce vulnerability:

    # touch /etc/notrouter

14. Ensure that the VPN starts after a reboot by editing the /etc/hostname.ip.tun0 file.

    system1-point system2-point tsrc system1-taddr \ tdst system2-taddr encr_algs 3des encr_auth_algs md5 up

    1. For example, on enigma, add the following lines to the hostname.ip.tun0 file:

       10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \ tdst 192.168.13.213 encr_algs 3DES encr_auth_algs MD5 up

    2. On partym, add the following lines to the hostname.ip.tun0 file:

       10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \ tdst 192.168.116.16 encr_algs 3DES encr_auth_algs MD5 up

15. On each system, create a file that configures some VPN parameters at boot time. Name the file /etc/rc3.d/S99vpn_setup. Type the following lines in the file.

    ndd -set /dev/ip hme1:ip_forwarding 1 ndd -set /dev/ip ip.tun0:ip_forwarding 1 ifconfig hme0 private in.routed

    You can also manually add routes in the /etc/rc3.d/S99vpn_setup file, instead of using in.routed.

16. On each system, run a routing protocol:

    # in.routed

How to Generate Random Numbers

If your site has a random number generator, use the generator. Otherwise, you can use the od command with the Solaris /dev/random device as input. For more information, see the od(1) man page.

1. Generate random keys.

   On a Solaris system, you can use the od command.

   # od -X -A n file

   -x	Displays the octal dump in hexadecimal format. Hexadecimal format is useful for keying material. The hexadecimal is printed in 4–character chunks.
   -X	Displays the octal dump in hexadecimal format. The hexadecimal is printed in 8–character chunks.
   –A n	Removes the input offset base from the display.
   file	A source for random numbers

   For example, the following commands print hexadecimal numbers.

   # od -X -A n /dev/random | head -2 d54d1536 4a3e0352 0faf93bd 24fd6cad 8ecc2670 f3447465 20db0b0c c83f5a4b # od -x -A n /dev/random | head -2 34ce 56b2 8b1b 3677 9231 42e9 80b0 c673 2f74 2817 8026 df68 12f4 905a db3d ef27

2. Combine the numbers to create a key of the appropriate length.

   Remove the spaces between the numbers on one line to create a 32–character key. A 32–character key is 128 bits. For an SPI, you can use an 8–character hexadecimal number.

How to Create IPsec Security Associations Manually

If the systems are using IPv6 addresses, you must manually create IPsec security associations.

If you are running an IPv4 network, use IKE to manage security associations. For how to use IKE to manage SAs, see Implementing IKE Task Map.

1. On the system console on one of the systems, 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. Enable the ipseckey command mode:

   # ipseckey >

   The > prompt indicates that you are in ipseckey command mode.

3. To create security associations, or to replace the security associations that you just flushed, type the following command.

   > add protocol spi random-hex-string \ src addr dst addr2 \ protocol_alg protocol-algorithm \ protocolkey random-hex-string-of-algorithm-specified-length

   random-hex-string	A random hexadecimal number of up to eight characters long. 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.
   protocol	One of esp or ah.
   addr	The IP address of one system.
   addr2	The IP address of the peer system of addr.
   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. For example, on enigma type the following commands to protect outbound packets. Use random numbers that you generate.

      > add esp spi 8bcd1407 src 192.168.116.16 dst 192.168.13.213 \ encr_alg 3DES \ encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d > add ah spi 18907dae src 192.168.116.16 dst 192.168.13.213 \ auth_alg MD5 \ authkey e896f8df7f78d6cab36c94ccf293f031 >

      ---

      Note –

      The peer system must use the same keying material.

      ---

   2. Still in ipseckey mode on enigma, type the following commands to protect inbound packets. Use random numbers that you generate.

      > add esp spi 122a43e4 src 192.168.13.213 dst 192.168.116.16 \ encr_alg 3des \ encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e > add ah spi 91825a77 src 192.168.13.213 dst 192.168.116.16 \ auth_alg md5 \ authkey ad9ced7ad5f255c9a8605fba5eb4d2fd >

      ---

      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.

      ---

4. Type Control-D or quit to exit ipseckey command mode.

5. To ensure that the keying material is available to IPsec at reboot, add the keying material to the /etc/inet/secret/ipseckeys file on enigma.

   add esp spi 8bcd1407 dst partym encr_alg 3DES \ encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d # add ah spi 18907dae dst partym auth_alg MD5 \ authkey e896f8df7f78d6cab36c94ccf293f031 # # add esp spi 122a43e4 dst enigma encr_alg 3DES \ encrkey 137fb4739a55c9b3a1747baa06359826a5e4358e # add ah spi 91825a77 dst enigma auth_alg MD5 \ authkey ad9ced7ad5f255c9a8605fba5eb4d2fd

6. Repeat Step 1 through Step 5 on partym.

   The keying material on the two systems must be identical.

Example—Replacing IPsec Security Associations

To prevent an adversary from having time to break your cryptosystem, you need to refresh your keying material. When you replace the SAs on one system, the SAs must also be replaced on the communicating system.

When replacing security associations, remove the old keys before you add new keys. Use the flush command in ipseckey command mode to remove the old keys. Then add the new keying information.

# ipseckey
> flush
> add esp spi …

How to Verify That Packets are Protected

To verify that packets are protected, test the connection with the snoop command. The following prefixes can appear in the snoop output:

• AH: prefix – Indicates that AH is protecting the headers. You see AH: if you used auth_alg to protect the traffic.

• ESP: prefix – Indicates that encrypted data is being sent. You see ESP: if you used encr_auth_alg or encr_alg to protect the traffic.

You must be root or an equivalent role to read the snoop output. You must have access to both systems to test the connection.

1. On one system, such as partym, become root.

   % su Password: root-password #

2. In a terminal window, begin to snoop the packets from another system, such as enigma.

   # snoop -v enigma Using device /dev/hme (promiscuous mode)

3. In another terminal window, remotely log on to the enigma system. Provide your password. Then become root, and send a packet from enigma to the partym system.

   % rlogin enigma Password: your-password % su Password: root-password # ping partym

4. In the snoop window on partym, you should see output that looks something like the following:

   IP: Time to live = 64 seconds/hops IP: Protocol = 51 (AH) IP: Header checksum = 4e0e IP: Source address = 192.168.116.16, enigma IP: Destination address = 192.168.13.213, partym IP: No options IP: AH: ----- Authentication Header ----- AH: AH: Next header = 50 (ESP) AH: AH length = 4 (24 bytes) AH: <Reserved field = 0x0> AH: SPI = 0xb3a8d714 AH: Replay = 52 AH: ICV = c653901433ef5a7d77c76eaa AH: ESP: ----- Encapsulating Security Payload ----- ESP: ESP: SPI = 0xd4f40a61 ESP: Replay = 52 ESP: ....ENCRYPTED DATA.... ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 20 arrived at 9:44:36.59 ETHER: Packet size = 98 bytes ETHER: Destination = 8:0:27:aa:11:11, Sun ETHER: Source = 8:0:22:aa:22:2, Sun ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = not ECN capable transport IP: .... ...0 = no ECN congestion experienced IP: Total length = 84 bytes IP: Identification = 40933 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 60 seconds/hops IP: Protocol = 51 (AH) IP: Header checksum = 22cc …