[Dr.WoW] [No.32] IKEv1

Latest reply: Aug 30, 2018 06:50:09 4823 7 0 0

1 Configuring IKE/IPSec VPNs

IKEs are best for establishing IPSec VPNs between a single host and multiple sub-hosts. Its advantages become ever more prominent as the number of sub-hosts grows. For convenience's sake, here we'll only give a snapshot of how IPSec VPN networking is established between one host FW and one sub-host FW, as shown in Figure 1-1.

Figure 1-1 IKEv1/IPSec VPN networking

[Dr.WoW] [No.32] IKEv1-1242597-1

 

As shown in Figure 1-2, compared to manual configurations, the procedure used for IKE/IPSec VPNs only adds two further steps: the configuration of the IKE proposal and the IKE peer. The IKE proposal is primarily used to configure the encryption and authentication algorithms used to establish the IKE SA. The IKE peer is primarily used to configure the IKE version, identity authentication and exchange mode.

Figure 1-2 Schematic of IKEv1/IPSec configuration

[Dr.WoW] [No.32] IKEv1-1242597-2

 

Similar to manual IPSec VPNs, communication throughout the entire network must first be unimpeded. Specifically, the following two conditions must first be met:

l   The FW_A and FW_B are routable over a public network.

l   FW_A and FW_B security policies allow for traffic between PC_A and PC_B.

As for the configuration of IPSec VPN security policies, see the following sections. For now, we should first focus on this section - IKE IPSec VPN configuration.

See Table 1-1 for the steps to configure an IKE/IPSec VPN.

Table 1-1 IKE/IPSec VPN configuration

Configuration

Host FW_A

Sub-Host FW_B

IKE proposal

ike proposal 10

ike proposal 10

IKE Peer

ike peer b

 ike-proposal 10

 undo version 2 //IKEv1

exchange-mode main//main mode (default)

 remote-address 2.2.3.2//peer initiated IKE negotiation address

 pre-shared-key tiandihui2

ike peer a

 ike-proposal 10

undo version 2 //IKEv1

exchange-mode main//main mode (default)

remote-address 1.1.1.1//peer initiated IKE negotiation address

 pre-shared-key tiandihui2

ACL

acl number 3001

rule 5 permit ip source 192.168.0.0 0.0.0.255 destination 172.16.2.0 0.0.0.255

acl number 3000

rule 5 permit ip source 172.16.2.0 0.0.0.255 destination 192.168.0.0 0.0.0.255

IPSec Proposal

IPSec proposal a

transform esp

 encapsulation-mode tunnel

 esp authentication-algorithm md5

 esp encryption-algorithm des

IPSec proposal b

transform esp

 encapsulation-mode tunnel

 esp authentication-algorithm md5

 esp encryption-algorithm des

IPSec Policy

IPSec policy policy1 1 isakmp

 security acl 3001

 proposal a

 ike-peer b

IPSec policy policy1 1 isakmp

 security acl 3000

 proposal b

 ike-peer a

IPSec Policy Application

interface GigabitEthernet0/0/2

ip address 1.1.1.1 255.255.255.0

IPSec policy policy1

interface GigabitEthernet0/0/2

ip address 2.2.3.2 255.255.255.0

IPSec policy policy1

Route

ip route-static 172.16.2.0 255.255.255.0 1.1.1.2 //static route configured in peer private network to guide traffic through the applied IPSec policy interface

ip route-static 192.168.0.0 255.255.255.0 2.2.3.1 //static route configured in peer private network to guide traffic through the applied IPSec policy interface

 

 

Once configured, when host and sub-host FWs access a data flow, it can trigger the establishment of an IPSec VPN tunnel. Next, Dr. WoW will use capture packets to help us all understand the essence of IKEv1.

IKEv1 can be divided into two phases to complete the dynamic establishment of an IPSec SA:

l   Phase 1 establish IKE SA: the main mode or aggressive mode is used to establish IKE SA negotiation.

l   Phase 2 establish IPSec SA: the fast mode is used to establish IPSec SA negotiation.

Why would we divide this into two phases? How are these two phases related? To simply put, phase 1 is used to prepare for phase 2. Both IKE peers will exchange key materials, generate keys, and perform mutual identity authentication. Only after these preparations are completed will the IPSec actually begin the IPSec SA negotiation.

Next, we will introduce the main mode + fast mode process used to establish an IPSec SA. First, we will take a look at the differences between IKE/IPSec VPNs and manual IPSec VPNs.

2 Phase 1: Establishing IKE SA (Main Mode)

Three steps are taken to establish an IKE SA with six ISAKMP messages through main mode IKEv1. The screen capture of packet messages is as follows:

[Dr.WoW] [No.32] IKEv1-1242597-3

 

Next, we will use a host FW initiated IKE negotiation to illustrate the phase 1 negotiation process, as shown in Figure 1-3.

Figure 1-3 IKE SA main mode negotiation process

[Dr.WoW] [No.32] IKEv1-1242597-4

 

1.         IKE proposal negotiation.

The negotiation is divided into two circumstances:

l   The initiator's IKE peer cited an IKE proposal (sends the cited IKE proposal)

l   The initiator's IKE peer did not cite an IKE proposal (sends all IKE proposals)

Under these two circumstances, responders will search from among their own configured IKE proposals for an IKE proposal that matches the sender's (As such, the cited IKE proposal line in Figure 1-2 "Schematic of IKEv1/IPSec configuration" is dashed which means that cited and uncited are both acceptable). If there is no matching security proposal, the negotiation will fail.

The principles by which both IKE peers judge whether or not the IKE proposals match include whether or not the ends use the same encryption algorithm, authentication algorithm, identity authentication method, and DH group ID, but does not include the IKE SA's life cycle.

IKE peer configuration parameters are header keys, peer IDs or IP addresses or domain names that allow the IKE ends to successfully connect. They also include identity authentication parameters. No matter where the error lies, "though we sit end by end, fate would not have it so".

NOTE

When an IPSec SA is established through IKEv1 negotiation, the timing of the IKE SA timeout is either the local life cycle or the peer life cycle, whichever is shorter. If the life cycles configured on the two devices on either end of the tunnel differ, it will not affect IKE negotiation.

By taking a look at a screen capture packet, we can see the IKE proposal used for negotiation that is carried in the SA payload of the ISAKMP messages. Message (1) is used as an example below:

[Dr.WoW] [No.32] IKEv1-1242597-5

 

2.         The DH algorithm is used to exchange key materials and also generate keys.

Host and sub-host FWs use Key Exchange and nonce payloads in ISAKMP messages to exchange key materials. Key Exchange is used to exchange public DH values; nonce is used to transfer temporary random numbers. The two IKE peers in the DH algorithm only exchange key materials and do not exchange the actual shared keys. As such, hackers who steal DH values and temporary values cannot figure out shared keys. This is precisely the beauty of the DH algorithm. Within the screen capture packet, we can see the key materials exchanged between the IKE peers. Message (3) is used as an example below:

[Dr.WoW] [No.32] IKEv1-1242597-6

 

Once key materials are exchanged, the two IKE peers will combine their own configured identity authentication methods to each begin their respective complicated key computing processes (pre-shared keys or digital certificates are all involved in the key computing process), and ultimately generate 3 keys:

l   SKEYID_a: ISAKMP message integrity authentication key - No one would dare to tamper with an ISAKMP message. If the message has even the slightest change, its response integrity will be detected!

l   SKEYID_e: ISAKMP message cipher key - Don't even try to steal an ISAKMP message. Even if you do, you won't understand it!

l   SKEYID_d: Used for encryption and authentication keys derived from IPSec packets - ultimately, this key guarantees the security of IPSec encapsulated data packets!

The first two keys above ensure the security of subsequent ISAKMP message exchanges!

Throughout the entire key exchange and computing process, when controlled by an IKE SA timeout, the time will be automatically refreshed at a certain interval to avoid potential security issues when keys are used for a long period of time.

3.         Identity authentication

The two IKE peers perform identity authentication with the ISAKMP message (5) and (6) exchange identity message. Currently, there are two identity authentication techniques that are commonly used:

l   Pre-shared key method (pre-share): The device identity message is the IP address or name.

l   Digital certificate method: The device identity message is the certificate and a partial message HASH value (signature) authenticated through private-key encryption.

The identity messages above are encrypted with the SKEYID_e. As such, in the screen capture packets, we can only see ISAKMP messages identified as "Encrypted" and cannot see the contents of the message (identity message). Message (5) is used as an example below:

[Dr.WoW] [No.32] IKEv1-1242597-7

 

The pre-shared key is the simplest and most common method of identity authentication. With this method, device identity messages can be identified by the IP address or name (including the FQDN and USER-FQDN). When IKE peers both have a fixed IP address, in general, they will both be identified by their IP addresses; when one peer has a dynamically assigned IP address, this peer will only be identified by its name. Only when the identity messages of the authenticating peer and authenticated peer match will identity authentication be successful. The key points to host and sub-host FW identity authentication configuration are as shown in Table 1-2.

Table 1-2 Identity authentication message configuration

Device Identity Type

Host (Authenticating)

Sub-Host (Subject to Authentication)

IP address

remote-address

Interface address or local-address designated address for initiating IPSec tunnel negotiation

FQDN

remote-id

ike local-name

USER-FQDN

remote-id

ike local-name

 

There's an issue here that we should all be aware of. When the two IKE peers both have a fixed IP address, the IP addresses configured with a remote-address command must keep the same address as the one used for peer-initiated IKE negotiation. The use of this IP address is threefold: not only does it designate the IP address of the tunnel peer, it's also used when looking for local pre-shared keys and for authenticating peer identities. This is the greatest pitfall of IPSec; in different circumstances, it may change over many different times. If the proper law cannot be found, there will definitely be an error.

In summary, the IKE will perform two major actions in the phase 1 negotiation process:

l   It will generate cipher and authentication keys for successive ISAKMP messages and also generate key materials for IPSec SA.

l   Once identity authentication is complete and when encrypted, the identity message can be an IP address, device name, or a digital certificate with even more information.

Moreover, all of these contributions are subject to the SA life cycle control, and as soon as the SA times out, all of the tasks above will be repeated. The benefit here is that regardless of the results of key computing and identity authentication, the whole process will be repeated at a definite time, thereby eliminating opportunities for malicious behavior. None of this is included for manual IPSec VPNs, which is precisely why IKEs are "smart" key stewards.

3 Phase 2: Establishing IPSec SA

Beginning with phase 2, the two IKE peers will continue to exchange key materials, including SKEYID_d, SPIs and protocols (AH and/or ESP protocols), nonce, and other such parameters. Then, each peer will perform key computing and generate keys for IPSec SA encryption and authentication. In this way, each IPSec SA is guaranteed to use an absolutely unique key for the subsequent encryption and authentication of data transfers. Also, IPSec SA also has timeout; as soon as the IPSec SA times out, the IKE SA and IPSec SA will be deleted, and the negotiation will begin anew.

IKEv1 uses the fast exchange mode to establish an IPSec SA through three ISAKMP messages. The screen capture of the packet messages is as follows:

[Dr.WoW] [No.32] IKEv1-1242597-8

 

Because the SKEYID_e generated by IKEv1 phase 1 of the fast exchange mode encrypts ISAKMP messages, all of the packets that we have captured are all encrypted and we cannot see the specific contents of the payloads. As such, we can only explain the following steps textually. As shown in Figure 1-4, we will still illustrate this with a host FW initiated IPSec negotiation.

Figure 1-4 IPSec SA fast exchange mode negotiation process

[Dr.WoW] [No.32] IKEv1-1242597-9

 

4.         Initiator sends the IPSec proposal, protected data flow (ACL) and key materials to the responder.

5.         Responder responds with a matching IPSec proposal and protected data flow. At the same time, both parties generate a key for the IPSec SA.

The IPSec uses ACL to delineate the data flows that it wants to protect. As in our example, where the host only needs to communicate with a single sub-host, the configuration is relatively simple and only an ACL "mutual mirror" (the source and destination IP addresses of one ACL are the opposite of the other) needs to be configured on each FW. However, for other more complex situations, for instance, when a host establishes a VPN with multiple sub-hosts that the sub-hosts access through the host, as well as L2TP/GRE over IPSec, or 2-in-1 IPSec and NAT gateways, ACL configurations become more particular. We will revisit these scenarios when we encounter them again.

The principle by which both IKE peers judge whether or not the IPSec proposals match is that the authentication algorithms, encryption algorithms and encapsulation modes used by both security protocols must all be the same.

Because all IPSec SA keys are derived from SKEYID_d, as soon as SKEYID_d is leaked, it may compromise the IPSec VPN. To elevate the security of key management, IKE delivers a PFS (perfect forward secrecy) function. Once PFS is activated, a one-time add-on DH exchange will be performed during IPSec SA negotiation, to regenerate new IPSec SA keys, thereby further improving IPSec SA security. Remember that if a PFS is to be configured, it must be configured on both tunnel FWs!

6.         Initiator sends confirmation results.

Once negotiation is complete, the sender will begin to send the IPSec (ESP) packets.

[Dr.WoW] [No.32] IKEv1-1242597-10

 

Once an IPSec SA is successfully established, check the IPSec VPN presence message. This is illustrated with the host FW_A display message.

l   Check the IKE SA status:

<FW_A> display ike sa

current ike sa number: 2

------------------------------------------------------------------------

conn-id peer flag phase vpn

------------------------------------------------------------------------

40129 2.2.3.2 RD|ST v1: 2 public

40121 2.2.3.2 RD|ST v1: 1 public

Here both the IKE SA (v1: 1) and IPSec SA (v1: 2) statuses are displayed. RD means that the SA is set to READY. There is only one IKE SA between the IKE peers. The IKE SA is a two-way logical connection (no distinction between the source and destination).

l   Check the IPSec SA status:

<FW_A> display IPSec sa brief

current IPSec sa number: 2

current IPSec tunnel number: 1

---------------------------------------------------------------------

Src Address Dst Address SPI Protocol Algorithm

---------------------------------------------------------------------

1.1.1.1 2.2.3.2 4090666525 ESP E: DES; A: HMAC-MD5-96;

2.2.3.2 1.1.1.1 2927012373 ESP E: DES; A: HMAC-MD5-96;

The IPSec SA is unidirectional (distinction between source and destination), and both IPSec SAs together constitute a single IPSec tunnel. Generally speaking, a single data flow will correspond to a single IPSec SA. However, when the IPSec also uses ESP + AH encapsulation, a single data flow will correspond to two IPSec SAs.

l   Check the session table:

<FW_A> display firewall session table

 Current Total Sessions: 3

 icmp VPN: public --> public 192.168.0.2: 18334-->172.16.2.2: 2048

 udp VPN: public --> public 1.1.1.1: 500-->2.2.3.2: 500

 esp VPN: public --> public 2.2.3.2: 0-->1.1.1.1: 0

We have now established the IPSec SA. On the surface, it might seem like there are not many differences between the IKE method and the manual method, but in fact, the differences are massive:

l   Different key generation methods

Manually, all IPSec SA parameters that must be created, including the encryption and authentication keys, are all manually configured and can only be manually refreshed.

With the IKE method, all IPSec SA encryption and authentication keys that must be created are generated by the DH algorithm and can be dynamically refreshed. Key management costs are lower, and security is higher.

l   Different IPSec SA life cycles

Manually created IPSec SAs will have a permanent presence.

With the IKE method, IPSec SAs are triggered by the data flow, and the SA life cycle parameter (also known as the SA timeout) controls are configured by both ends.

The main mode is the recommended method of configuration for reliable security. Next, we will take a brief look at another kind of IKE SA negotiation method - aggressive mode.

4 Phase 1: Establishing IKE SA (Aggressive Mode)

IKEv1 completes IPSec dynamic negotiation in two phases; when phase 1 uses the main mode negotiation, it offers reliable security, but sometimes, the perfect main mode will still be useless. Why is that? Let's take a look at what happens when we replace main mode with aggressive mode.

In Table 1-1 "IKE/IPSec VPN configuration", if we change the IKE peer configuration command exchange-mode main to exchange-mode aggressive, the IKEv1 phase 1 negotiation mode will be changed to aggressive mode. Let's take a look at the capture packets to see how aggressive mode packets interact:

[Dr.WoW] [No.32] IKEv1-1242597-11

 

As shown in Figure 1-5, aggressive mode only needs three ISAKMP messages to complete the phase 1 negotiation process. Phase 2 is still the same fast mode as before.

Figure 1-5 IKE SA aggressive mode negotiation process

[Dr.WoW] [No.32] IKEv1-1242597-12

 

The initiator and responder peremptorily place all of their messages, including the IKE proposal, relevant key messages and identity messages, into a single ISAKMP message and send it to the other end, thereby improving IKE negotiation efficiency. However, because the identity message is transferred as plaintext, it does not go through the encryption and integrity authentication process, which lowers IKE SA security. Clearly, security here falls shorts. So why do we even have aggressive mode?

Back in the early days of IPSec VPNs, when people used the main mode + pre-shared key identity authentication method, the IPSec needed to search for the pre-shared key locally on the peer IP address. This kind of key search method only works when the peer has a fixed IP address. If there is not a fixed address, aggressive mode can be used to "brutally" solve this problem.

In aggressive mode, the "identity messages" are not encrypted, and locally, the identity message is exactly the same as what was sent from the peer (i.e. the IP address). This is all that is needed to search for the pre-shared key. As such, in the initial stages of IPSec VPN applications, aggressive mode was mainly used to deploy IPSec VPNs to nodes that did not have fixed IP addresses. Nowadays, IPSec VPN has many other ways to solve this problem and the unsafe aggressive mode is clearly not the best option. All we really need to do now is understand how it used to be used; Dr. WoW does not recommend any actual use of it though.

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

Mohamed_Mostafa
Mohamed_Mostafa Created Sep 20, 2018 07:07:49
Great explanation  
user_2790689
Created Jul 28, 2015 09:23:16 Helpful(0) Helpful(0)

Good.

 

  • x
  • convention:

kamilla_kamilla
Created Jan 29, 2016 23:05:26 Helpful(0) Helpful(0)

This is a very good post which I really enjoy reading. It is not every day that I have the possibility to see something like this.

192.168.1.1

  • x
  • convention:

user_2887027
Created Sep 9, 2017 06:57:27 Helpful(0) Helpful(0)

icmp VPN: public --> public 192.168.1.1: 18334-->172.16.2.2: 2048

udp VPN: public --> public 1.1.1.1: 500-->2.2.3.2: 500

esp VPN: public --> public 2.2.3.2: 0-->1.1.1.1: 0 [Dr.WoW] [No.32] IKEv1-2472719-1[Dr.WoW] [No.32] IKEv1-2472719-2[Dr.WoW] [No.32] IKEv1-2472719-3[Dr.WoW] [No.32] IKEv1-2472719-4
  • x
  • convention:

user_2890713
Created Sep 13, 2017 10:47:28 Helpful(0) Helpful(0)

:$:$:$
Finally I found a great post with interesting topic. I read every points of this post that is really so enjoyable and I have bookmark your site for get back again here. gmail account login
  • x
  • convention:

Aaradhya
Created Apr 27, 2018 06:20:26 Helpful(0) Helpful(0)

I found very interesting and nice keep sharing awesome shared troubleshooting wireless network
  • x
  • convention:

ronitkapoor
Created Aug 30, 2018 06:50:09 Helpful(0) Helpful(0)

This was great loved to read this very knowledgeable and interesting and most importantly this is providing value keep sharing your knowledge with us. Try 192.168.0.1 router login for more information on 192.168.0.1.
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login