IPSec (IP Security): Part 2 - IKE & AH

by Don Parker [Published on 28 Feb. 2006 / Last Updated on 28 Feb. 2006]

In this article series based on IPSec we covered ESP in part I. Part II will go on to cover what IKE is, and also looked at will be AH. Being able to understand the various parts that make up what is called IPSec is an important building block in an effort to further your knowledge. Read on to find out more!

If you would like to read the other parts of this article series please read:


Just what is IKE?

In part I we touched briefly on what an SA (security association) is and that it had a role in IKE. Just what is IKE though? Well it is the protocol that is used to actually setup the SA. It is during the SA negotiation that various options are chosen. One option that can be enabled is anti-replay protection. There are other options that can be enabled, and likely should be depending on your needs. IKE itself and its role really boils down to its authenticating two IPSec end points and helping to set up a secure tunnel between them.

IKE will perform this role over what are called two “phases”. Phase I will authenticate the identity of both IPSec end points. During Phase I, IKE will also negotiate matching SA’s (security associations) between the two end points allowing them to communicate safely and securely. This in turn allows IKE to securely take care of Phase II. Another key point is that an authenticated Diffie-Hellman exchange will occur with the end result being that both end points will have matching “shared secret keys”.

The above noted Phase I though can be broken down into two modes. These are “main mode” and “aggressive mode”. Main mode is broken down into three separate exchanges of information between both end points.

  1. Specific algorithms and hashes used to actually secure the communications are agreed upon.
  2. A Diffie-Hellman exchange takes place, which is used to generate shared secret keys. This is used to verify the identity of both end points in step three.
  3. Based upon the IP address of both end points the identity of each other is verified. The earlier noted key exchange is now used to decrypt the IP addresses thereby verifying them.

The end result of the above three steps is that we now have a matching SA between both end points. This now allows both end points to pursue communications via a now secured channel. This process is a fairly detailed and structured exchange. In the other “aggressive mode” there is less information exchanged. That is probably why it is called “aggressive”!. During an “aggressive mode” setup the first step sends most of the SA values such as algorithms and hashes to be used. Also sent is the Diffie-Hellman exchange and an identity packet as well.

Now the second step sends back the same information to the initiating end point with the only remaining step being for the initiator to signal that the exchange is now complete. There is one glaring problem with this mode though. That being that the information was sent back and forth in the clear before it was secured. This can lead to someone being able to capture the packets and analyze them for a possible attack.

Yet another phase!

In case you are not yet thoroughly confused we have another phase to cover and that would be Phase II of the IKE. Don’t feel bad if you are confused because this is difficult information to grasp. Unless you are always setting up VPN’s, which most people aren’t, then this information can be hard to get a handle on. With Phase II there is only one mode, and it is referred to as “quick mode”. This mode will happen once a secure tunnel has been setup during Phase I. In Phase II “quick mode” SA details are negotiated and protected due to the existing tunnel setup during Phase I. Also the SA’s themselves are established and will be renegotiated as required. Lastly, further Diffie-Hellman exchanges can be done.

This rounds out our discussion of IKE and it should be noted that IKE will be used by not only ESP, but also by AH (authentication header). AH is another of the IPSec protocols, specifically proto 51. This is the numerical value assigned to it that you will see in an IP header in the protocol field. I was hoping to be able to show you an AH packet, but was unable to come up with one. Should you wish to try and find one in your database, if you log your traffic, then try the following BPF filter;

-nXvSs 0 ip and net 192.168 and ip[9] = 51

The above will log all packets with the netblock 192.168 in it and also with an IP protocol field equalling 51. If you are logging to a binary log then you simply need to put the –s 0 and disregard the other switches, as seen below;

-s 0 ip and net 192.168 and ip[9] = 51 –w bleh

The reality of it is that most people no longer use AH as a means of IPSec. It really makes far more sense to use ESP as all of the transmission sent will or can be encrypted. Why would you want to simply authenticate when you can completely encrypt your data stream? These are the very types of decisions that hopefully this article series will allow you to make with more authority.

This is very much like walking down to your local electronics retailer and looking at some high priced stereo systems. You get to hear the salesperson talk to you about the fidelity of the speakers on a nice system. Problem is though that the RF (radio frequency) range that these speakers are touted for really don’t impact you as the human ear can only hear a certain frequency range. That is why some stereo salesman make me laugh. Don’t simply memorize the product literature, understand the theory behind it! As you can see it pays to do a little research whether it be for the purchase of a VPN solution or a stereo system.

AH aka authentication header

This protocol, and cousin to ESP if you will, in a nutshell provides integrity and authentication for the end user. AH also has the ability to provide protection against replay attacks which are commonly seen against these types of protocols. That being said, if the anti-replay option is to be used by the destination endpoint then it must say so during the SA (security association). One of the key things to know about AH is that it will provide authentication for only certain parts of the IP header. We must remember that certain parts of the IP header change in transit ie: as it is being routed to its ultimate destination.

Back to basic IP protocol metrics for a moment to explain this concept. There is a field in the IP header that is called the TTL or “time to live”. Each and every time this packet goes through a router the router itself will decrement the TTL value and send it on its way. Well, each time this TTL is decremented the router recalculates the IP checksum to compensate for the changed IP header value. Were the router not to do this then the destination computer upon recomputing the IP checksum would note it is different than the one listed in the header and reject it. So as you can see not all of the IP header is authenticated. Less then ideal wouldn’t you say?

During some interesting discussions that I have had with a friend of mine called Matt Atkinson, you would come to realize the importance of encrypting data if possible. Especially so if you are talking about routing protocols! There are some very clever hackers out there who will always be looking for weaknesses in protocols and their usage. Good thing that people like Matt are on our side. On that note I will break the article here and carry on in part three with AH and GRE. Till then keep the packets flowing!

If you would like to read the other parts of this article series please read:

See Also

Featured Links