Networking Lab Solutions Homework The Setkey File Has Two Blocks And

IPSEC LAB

Part 1:IPSec connection with Manual Keying in the same subnet (Transport mode)

The goal of this part of the lab is to establish an IPSec connection between

1. Steps taken to configure the hosts:

Below is the setkey.conf file for M1. The setkey.conf file for M3 is identical, except for the

security policies section, which had “–P out” instead of “–P in” and “–P in” instead of “–P out”

add 192.168.100.2 192.168.101.2 esp 0x201 -E 3des-cbc ——> 6

add 192.168.101.2 192.168.100.2 esp 0x301 -E 3des-cbc ——> 9

0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df ——> 10

-A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b; ——> 11

# Security policies ——> 12

spdadd 192.168.100.2 192.168.101.2 any -P out ipsec ——> 13

esp/transport//require; ——> 14

The setkey file has two blocks. The first part deals with configuring the IPSec security associations

while the second part is used for configuring the security policies.

We configured the Security Policies in the following way

Using the keyword spdadd we specified the two end hosts which would be taking part in

the IPSec connection and gave the SA and direction (OUT since the configuration file is on M1). Also

we specified that the SA should be set up using the transport mode and the ESP protocol. This is shown

in Lines 13 and 14. Lines 15 and 16 specify the other direction (IN).

2. IPSec provides the following services in this example:

⚫ Confidentiality, since we are using the ESP protocol which encrypts the IP payload unlike the

AH protocol. We set the encryption key in the setkey.conf file

3. No,the IP header is not encrypted. This is because we are using the Transport mode which runs

4. The protocol number for ESP is 0x32 in hex or 50 in decimal

6. The SPI for the SA from M1 to M3 is 0x00000201 while that for the SA from M3 to M1 is

0x00000301.

Part 2: IPSec connection with Manual Keying between hosts in different subnets (Tunnel Mode):

In this part we have established an IPSec SA in the tunnel mode between 10.24.100.15 and

10.24.100.37 gateways. NAT was overcome using the given instructions. After the initial setup we sent

packets between 192.168.10.2 and 192.168.12.2 which were behind the 10.24.100.15 and 10.24.100.37

1. Shown below is the setkey.conf file that we used on 10.24.100.37 (M2). The setkey.conf file for

M2 of our partner group is identical, except for the security policies section, which had “–P out”

instead of “–P in” and “–P in” instead of “–P out” indicating the change in direction for the

add 10.24.100.37 10.24.100.15 esp 0x04786b7e -m tunnel -E 3des-cbc ——>8

0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df ——>9

# Security policies ——>10

spdadd 192.168.12.0/24 192.168.10.0/24 any -P out ipsec ——>11

esp/tunnel/10.24.100.37-10.24.100.15/require; ——>12

spdadd 192.168.10.0/24 192.168.12.0/24 any -P in ipsec ——>13

esp/tunnel/10.24.100.15-10.24.100.37/require; ——>14

Setkey.conf file on 10.24.100.37

The setkey file has two blocks in it and the first part deals with configuring the IPSec

Security Associations while the second part is used for configuring the Security Policies. We first

flushed the previous configuration settings (if any) and configured the Security Association Database

parameters as follows.

2. IPSec provides only confidentiality in this case. We are neither using AH nor using

3. Since we are using the tunneling mode the original IP header is encrypted and a new IP header

10.24.100.15 and 10.24.100.37 as the source and destinations respectively. The new IP header is

4. Yes, we are able to see ESP packets in both directions but only the incoming ICMP echo request

5. If in the tunnel mode ESP authentication was used , then there would be no difference in the

Part 3: IPSec connection with Manual Keying between hosts in different subnets (Transport Mode):

In this part we have established an IPSec SA in the transport mode between 192.168.10.2

and 192.168.13.2 which are behind the 10.24.100.15 and 10.24.100.37 gateways. NAT was overcome

192.168.10.2 and 192.168.13.2 was encrypted using the IPSec ESP protocol.

2. Shown below is the setkey.conf file that we used on 192.168.13.2 (M3). The setkey.conf file for

M1 of our partner group is identical, except for the security policies section, which had “–P out”

instead of “–P in” and “–P in” instead of “–P out” indicating the change in direction for the

add 192.168.10.2 192.168.13.2 esp 0x301 -E 3des-cbc ——>8

0xf6ddb555acfd9d77b03ea3843f26532558fe8eb5573965df; ——>9

#Security Policies ——>10

spdadd 192.168.10.2 192.168.13.2 any -P in ipsec ——>11

esp/transport//require; ——>12

Setkey.conf file on 192.168.13.2

The setkey file has two blocks in it and the first part deals with configuring the IPSec

security associations while the second part is used for configuring the Security Policies. We first

flushed the previous configuration settings( if any) and configured the Security Association Database

parameters as follows.

Lines 8 and 9 contain the required configuration settings for the SA in the other direction.

The encryption key for this SA is different from the one used for the previous SA.

We configured the Security Policies in the following way

Using the keyword spdadd we specified the two end hosts which would be taking part in

the IPSec connection and gave the SA a direction (IN since the configuration file is on M3). Also we

specified that the SA should be set up using the transport mode and the ESP protocol. This is shown in

Lines 11 and 12. Lines 13 and 14 specify the other direction (OUT).

2. IPSec provides only confidentiality in this case. We are neither using AH nor using

3. No,the IP header is not encrypted. This is because we are using the Transport mode which runs

4. No. Since the entire IP payload is encrypted, there is no way in which we can determine if the

higher layer protocol is TCP or UDP or IP.

5. Some of the difference between the transport mode and the tunnel mode are:

⚫ The original IP header is protected in the tunnel mode while it is not in the transport mode

6. The source and destination addresses of the IP Packets are the end hosts 192.168.10.2 and

192.168.13.2 . No, these are not the same as the source and destination of the tunnel mode in

7. “Use” level is used if an SA has already been established between the hosts. The packets are

hence IPSec protected if a session was existing else they will be sent in the clear. The “require”

lever requires an SA to be setup each time a new communication session begins, irrespective of

Part 4: Automatic Keying with IKE with pre-shared keys (Transport Mode)

In this part of the lab we used the method of pre-shared keys to set up the IPSec SA in the

Shown below is the network topology used by us.

1 a). The Configuration file for the IPSEC daemon Racoon : racoon.conf

path pre_shared_key “/etc/psk.txt”; ——>1

remote 192.168.10.2 { ——>2

encryption_algorithm 3des; ——>13

authentication_algorithm hmac_md5; ——->14

compression_algorithm deflate; ——->15

} ——>16

The configuration file contains details about various parameters that are used while setting up an IPSec

an RSA signature. Line 8 specifies the group to be used for Diffie-Hellman exponentiations.

Lines 11-16: This block is used during Phase 2 of IKE. Line 11 specifies that the block remains

anonymous. Instead of setting this for a specific host, the anonymous parameter is used to specify that

these settings should be used for all hosts that do not have a specific configuration [1]. This is sufficient

for simple connections. The peer is identified using the presharedsecret.

management in intuitive ways. The following is a typical setkey.conf file to enable this setup.

#!/usr/sbin/setkey -f

#Config for 192.168.13.2

# flush the SAD and SPD

flush;

(192.168.13.2) of one subnet, destined to M1 (192.168.10.2) of the other subnet have to follow the

1.c). Finally, the file from which the preshared key is derived: psk.txt

#This file contains the preshared key

192.168.10.2 presharedkey.

3. Description of IKE with preshared keys in the transport mode.

The IKE has two phases. Phase 1 is used for mutual authentication and to establish session

keys and at the end of this phase, two session keys are established, an integrity key and an encryption

key. It takes the first 4 packets to create these keys and they are used to encrypt the rest of phase 1 and

Phase 1: The ISAKMP SA establishment (Main Mode):

The screen shot above was taken while running racoon in the foreground or diagnostic

mode using the command racoon -F . It shows a successful, key exchange between the participating

Messages 1 and 2.

This message also sends the Crypto Proposal from the first machine to the second machine

to agree upon, for encryption and authentication purposes. In this case the the encryption algorithm will

be 3DES-CBC, Authentication is by using preshared keys and the hash algorithm for integrity check is

MD5. The proposal also contains the diffie-hellman key exchange modp group.

The second message is almost exactly the same as the first except that the source and