[Dr.WoW] [No.31] IKE and ISAKMP Highlighted

Latest reply: May 19, 2018 01:28:26 4817 3 1 0
Keys used for manual IPSec VPN encryption and authentication are all manually configured. To ensure the long-term security of an IPSec VPN, these keys must be modified and replaced often. As the number of sub-hosts grow, the task of key configuration and modification becomes ever more difficult. As Tiandihui's forces grew in strength, the maintenance and administration of IPSec VPNs became a daunting task. To lessen the load of IPSec VPN administration, the Tiandihui Host paid homage to the Supreme Host to find an elixir for their ailments. The elixir was there all along, a gift of the gods. IPSec protocol profiles have long pondered this dilemma - the answer lies in a "smart" key steward - the IKE (Internet Key Exchange) protocol.

IKE combines 3 major protocols - the ISAKMP (Internet Security Association and Key Management Protocol), Oakley protocol and SKEME protocol.

l   ISAKMP mainly defines the process used to establish the collaborative relationship (for example, IKE SA and IPSec SA) between IKE peers.

l   At the heart of the Oakley and SKEME protocols is the DH (Diffie-Hellman) algorithm, which ensures data transfer security through the safe distribution of key and authentication identification over the Internet. Do not underestimate the DH algorithm. With it, the cipher and authentication keys needed for IPSec and IKE SAs can also be dynamically refreshed.

With an IKE association, IPSec VPN security and administrative hassles were no longer a problem for Tiandihui. Now, new sub-host VPNs could be established at incredible speeds.

The ultimate goal of the IKE protocol is to establish a dynamic IPSec SA through host-to-sub-host negotiations while also providing real-time maintenance of the IPSec SA. The establishment of an IPSec SA and the corresponding IKE negotiation is completed through ISAKMP packets, and as such, before we deploy our IKE, Dr. WoW will give us a lesson on ISAKMP packets, as shown in Figure 1-1.

Figure 1-1 ISAKMP packet encapsulation and packet headers

[Dr.WoW] [No.31] IKE and ISAKMP-1239965-1

 

l   IP packet header

?       SRC (Source IP Address): local IP address of the initiated IKE negotiation; may be that of a physical/logical interface and maybe be command configured.

?       DST (Destination IP Address): peer IP address of the initiated IKE negotiation; command configured.

l   UDP packet header

IKE protocol port 500 initiates negotiation and responds to negotiation. When both the host and sub-hosts have fixed IP addresses, this port will never change in the negotiation process. When either the host or the sub-host s have an NAT device (NAT traversal scenario), the IKE protocol will use a special process which we will discuss later on.

l   ISAKMP packet header

?       Initiator's cookie (SPI) and responder's cookie (SPI): the SPI serves as a cookie for both IKEv1 and IKEv2, a unique IKE SA identifier.

?       Version: the IKE version number. Many things have changed for the better since the launch of IKEs. To differentiate, older IKEs are known as IKEv1 while updated IKEs are known as IKEv2.

?       Exchange Type: the IKE defined exchange type. Exchange types define the exchange sequence that ISAKMP messages must follow. Later, we will discuss the IKEv1 main mode, aggressive mode, and fast mode. When discussing IKEv2, we'll mention initial exchanges and child SA exchanges. All of these are different IKE defined exchange types.

?       Next Payload: The next payload type identifies the message. A single ISAKMP packet may be loaded with multiple payloads. This field provides "link" capabilities within the payload. If the current payload is the message's final payload, this field will be 0.

?       ISAKMP Payload (Type Payload): A type of payload carried in an ISAKMP packet that is used as a "parameters packet" for negotiating IKE and IPSec SAs. There are many different types of payloads, and each different payload may carry different "parameter packets". The specific usage of different payloads will be discussed together with the packet capturing process.

The essence of IKEv1 and IKEv2 is the focus of this section. Without further ado, Dr. WoW will introduce it.

 

 

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

  • x
  • convention:

user_2790689
Created Jul 25, 2015 04:00:23 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

wissal
MVE Created Apr 10, 2018 15:46:13 Helpful(0) Helpful(0)

useful document, thanks
  • x
  • convention:

Telecommunications%20Engineer%2C%20currently%20senior%20project%20manager%20of%20the%20radio%20access%20network%20and%20partner%20of%20Huawei%20de%20Tunisia.
w1
Created May 19, 2018 01:28:26 Helpful(0) Helpful(0)

useful document, thanks:)
  • 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