[Dr.WoW] [No.33] IKEv2 Highlighted

Latest reply: Apr 10, 2018 15:45:57 4553 2 1 0

1 IKEv2 Overview

IKEv1 seemed perfect enough, but before long, its shortcomings started to become clear.

l   Long IPSec SA negotiation times

For a single IPSec SA negotiation, IKEv1 main mode will typically need to send 6 (IKE SA negotiation) + 3 (IPSec SA negotiation) = 9 messages.

For a single IPSec SA negotiation, IKEv1 aggressive mode will typically need to send 3 (IKE SA negotiation) + 3 (IPSec SA negotiation) = 6 messages.

l   No support for remote user accessions

IKEv1 cannot perform authentication for remote users. If we want to support remote user accessions, we can only use L2TP, and use AAA authentication with PPP to authenticate remote users.

How to deal with this? Never fear! There's never a problem too difficult to solve! IKEv2 is the perfect answer to all these problems.

IKEv2 v.s. IKEv1:

l   Major speed boost to IPSec SA negotiations

The average IKEv2 negotiation for a single IPSec SA will only require 2 (IKE SA negotiation) + 2 (IPSec SA negotiation) = 4 messages. Successive IPSec SAs will only require two more messages.

l   EAP (Extensible Authentication Protocol) method identity authentication added.

Here, we'll only discuss the basic IKEv2 negotiation process and won't touch on EAP authentication in our discussion of enterprise networks just yet.

In Figure 1-1 we can see the entire networking environment which can help explain how IKEv2 actually works.

Figure 1-1 IKEv2/IPSec VPN networking

[Dr.WoW] [No.33] IKEv2-1249795-1

 

The IKEv2 configuration roadmap is almost exactly the same as IKEv1's, with a few detours. As shown in Figure 1-2, the commands in italics differ from IKEv1. By default, the firewall will start both the IKEv1 and IKEv2 protocols. When the negotiation is initiated locally, IKEv2 is used. When receiving a negotiation, IKEv1 and IKEv2 are both supported. So, we can also leave IKEv1 activated.

Figure 1-2 Schematic of IKEv2/IPSec configuration

[Dr.WoW] [No.33] IKEv2-1249795-2

 

2 IKEv2 Negotiation Process

The IKEv2 IPSec SA negotiation process is very different from IKEv1's; we can create an IPSec SA in as little as 4 messages! Talk about efficiency!

1.         With 4 initial exchange messages, IKE SA and IPSec SA are simultaneously taken care of.

The IKEv2 initial exchange uses 4 messages to establish IKE SA and IPSec SA. The capture packet messages are as follows:

[Dr.WoW] [No.33] IKEv2-1249795-3

 

As shown in Figure 1-3, the initial exchange includes the IKE SA initial exchange (IKE_SA_INIT exchange) and the IKE authentication exchange (IKE_AUTH exchange).

Figure 1-3 Initial exchange

[Dr.WoW] [No.33] IKEv2-1249795-4

 

l   First message (IKE_SA_INIT)

This negotiation is responsible for IKE SA parameters, including the IKE proposal, temporary random numbers (nonce) and DH values.

[Dr.WoW] [No.33] IKEv2-1249795-5

 

The SA payload is mainly used for negotiating IKE proposals.

[Dr.WoW] [No.33] IKEv2-1249795-6

 

KE (Key Exchange) and nonce payloads are mainly used to exchange key materials.

[Dr.WoW] [No.33] IKEv2-1249795-7

 

Once exchanged by the IKE_SA_INIT, the IKEv2 will ultimately generate 3 types of keys:

?       SK_e: used to encrypt the second message.

?       SK_a: used to authenticate the identity of the second message.

?       SK_d: used for encryption materials derived from the child SA (IPSec SA).

l   Second message (IKE_AUTH)

This is responsible for identity authentication and for creating the first child SA (IPSec SA). Currently, there are two commonly used techniques for identity authentication:

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

?       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 all use SKEYID_e encryption.

When a child SA is created, naturally, it also needs to negotiate an IPSec proposal for the protected data flow. IKEv2 will use TS payloads (TSi and TSr) to negotiate ACL rules between the two devices. The final result is that the two ACL rules will set up an intersection (this is different from IKEv1; IKEv1 does not have TS payloads to negotiate the ACL rule).

When a single IKE SA needs to create multiple IPSec SAs, such as when two IPSec peers send multiple data flows back and forth, a child SA exchange must be used to negotiate the subsequent IPSec SAs.

2.         The child SA exchanges two messages to establish one IPSec SA.

[Dr.WoW] [No.33] IKEv2-1249795-8

 

Child SA exchanges can only be performed after the IKE initial exchange is completed. The exchange initiator can be the initiator from the IKE initial exchange as well as the responder to the IKE initial exchange. These two messages will be protected by the IKE initial exchange negotiation key.

IKEv2 also supports the PFS function, and a new DH exchange can be performed and a new IPSec SA key generated during the child SA exchange phase.

 

 

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

  • x
  • convention:

user_2790689
Created Aug 4, 2015 04:12:13 Helpful(0) Helpful(0)

Good.
  • x
  • convention:

wissal
MVE Created Apr 10, 2018 15:45:57 Helpful(0) Helpful(0)

useful document, thanks
  • x
  • convention:

Telecommunications%20engineer%2C%20currently%20senior%20project%20manager%20at%20an%20operator%2C%20partner%20of%20Huawei%2C%20in%20the%20radio%20access%20network%20department%2C%20for%2020%20years%20I%20managed%20several%20types%20of%20projects%2C%20for%20the%20different%20nodes%20of%20the%20network.

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