If you would like to read the other parts of this article series please read:
AH aka authentication header continued…
We left off in part two talking about how AH really only authenticates parts of the IP header and that this is less then desirable. Realizing that certain parts of the IP header will change in transit necessitated this approach. This is largely why you don’t really see a lot of AH usage but rather far more ESP traffic. That said let’s continue with our look at AH!
AH is not restricted in use to only itself. It can also be used in conjunction with ESP or what is called “nested” or as seen in tunnel mode. One of the key differences to realize between ESP and AH is the following. ESP does not authenticate any part of the IP header itself unless it is being used in tunnel mode. If it is in tunnel mode then the original IP header has been encapsulated by ESP, which in turn generates another IP header for routing. That to me sums up the differences between AH and ESP.
What does AH look like?
What does an AH header look like though? Well it is built a little bit like ESP really, and seeing as I was not able to find an AH packet to look at I will list the general breakdown of an AH packet as follows;
|| Mac Header || IP Header || AH Header || Data ||
The above is how an AH packet would look like if viewed horizontally. The MAC header is simply the MAC address of the computer, followed by the normal IP header. Next in line is the AH header. The AH header itself is broken down into various segments as seen below;
|| Next header || Length || SPI || Sequence number || Authentication data ||
The next header field refers to the encapsulated protocol, while the length field is used to denote the size of the authentication data payload as measured in 4 byte words. Next we have the SPI or security parameter index value and after it the sequence number. Lastly is the authentication data itself.
This will sum up our high level overview of AH and how it works. We have seen that AH does have some serious shortcomings and in reality you would be far better served to use ESP as your IPSec protocol. Should you wish to read more about AH I would encourage you to check out the official RFC on it.
GRE or Generic Routing Encapsulation protocol
This is actually a fairly neat protocol and one whose name pretty much sums up what it was designed for. Simply put this is a generic protocol which can encapsulate other protocols and then have the whole package routed to a destination. That being said there is a lot more to it then that simplistic explanation. So let’s get on with digging a little deeper into GRE.
Generic routing encapsulation is itself a protocol that will encapsulate another network layer protocol and in turn be sent via another network layer protocol. We will use the following example to try and give this explanation some context. Your computer network has a packet that needs to be encapsulated and sent to another computer. This packet will be then encapsulated using the generic routing encapsulation protocol. This new packet that used GRE to encapsulate the original packet is then itself encapsulated into another protocol and sent on its merry way to the destination IP address.
You would be quite right in thinking that there is a whole lot of encapsulation going on here! There is the first original packet that is encapsulated using GRE, then GRE is encapsulated, and then it is in turn sent. Pretty much all computer communications use encapsulation of one form or another, it is just we don’t often hear about it as much as when we are talking about GRE. This is important to understand due to the nature of GRE ie: it is meant to encapsulate another protocol. It is easy to get confused, but you can remember simply that GRE swallows something up and in turn is encapsulated for transmission. What does a GRE packet look like though? Well let’s take a look at one below.
GRE packet
00:03:11.297652 192.168.1.100 > 192.168.1.200: gre [KSv1] ID:0600 S:0 ppp: Conf-Req(0), Auth-Prot CHAP/MSCHAPv2, Magic-Num=110e07b6, PFC, ACFC, Call-Back CBCP, MRRU=1614, End-Disc Local, Link-Disc=000f (ttl 125, id 18980, len 89)
0x0000 4500 0059 4a24 0000 7d2f e4da c0a8 0164 E..YJ$..}/……
0x0010 c0a8 01c8 3001 880b 0039 0600 0000 0000 H..X0….9……
0x0020 ff03 c021 0100 0035 0305 c223 8105 0611 …!…5…#….
0x0030 0e07 b607 0208 020d 0306 1104 064e 1317 ………….N..
0x0040 019b 4793 3c42 ae4b ca88 ce57 771b 8ddb ..G.<B.K…Ww…
0x0050 6600 0000 0017 0400 0f f……..
The above noted GRE packet is actually carrying around PPP or as it is referred to PPP-over-GRE. We can also see from the above packet that it is a fairly complex one. There are many different metrics involved. Defining all of the above metrics is beyond the scope of this article, but I would encourage you to log some GRE packets in a binary format and then use Ethereal to look at the various parts of it.
By far and away, one of the simplest ways to study IPSec is to simply download and install one of the freeware or shareware programs. It will only be through the use of IPSec programs that you will gain a deeper understanding of them. That, plus actually logging what is going on during an IPSec session is helpful. It is important to not only log the session itself, but also to do it from the very start of it. In an ideal world for your home computer lab you actually have two distinct connections to the Internet.
Having such a lab setup allows you to do more in terms of experimentation and certainly helps set up a more realistic test scenario when trying to learn more about VPN’s and their configuration. Not everyone can afford such a setup though, but perhaps if you work in a big company you could ask the people in the IT department to show you around. This would be most helpful as well since most corporations run Cisco gear and have opted for Cisco centric VPN solutions.
Wrapup
We have seen over the past three articles that IPSec is indeed a complex and sometimes confusing area of study. If nothing else, this cements the fact that further study of this computer security domain should be undertaken. There are many excellent IPSec solutions out there whether they be software or hardware. Knowing what is going on under the hood of these security appliances is a very good idea. One should never remain totally blind as to what is happening on their networks, as you may likely find yourself having to troubleshoot it! I had a good time writing this article series as IPSec is an area I often ignore myself. Going back over the various RFC’s for these protocols was a good refresher for me, and I would encourage you to read the definitive source of information for ESP, AH, IKE, and GRE. That is their respective RFC’s. I sincerely hope you enjoyed this series on IPSec, and as always welcome your feedback.Till next time!
If you would like to read the other parts of this article series please read:
