Version 4.1 - 2.0 AH and ESP
At the 50,000 foot level, the difference between AH and ESP is that AH does not encrypt anything and ESP encrypts. AH provides integrity and ESP provides confidentiality (and optionally integrity). They are protocols that are used in the IPsec protocol - either individually or combined.
The Authentication Header protocol is IP protocol 51. It is covered under RFC 4302. "The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays." I'm looking at the AH header and I'm not so sure that this would be a drag-and-drop diagram. However, it would be good to know the parts of an AH header:
# Protocol (IPv4) or Next Header (IPv6)
# Payload Length
# Security Parameters Index (SPI)
# Sequence Number Field
# Integrity Check Value (ICV)
If you look at the diagrams of AH and ESP in my previous post, you will see that AH includes this ICV in the AH header, whereas ESP includes a separate section for ICV at the end (after the ESP trailer). The SPI will be covered later, but basically it's the index number of the SA. The Sequence Number Field starts at 0 (for each established SA) and increments (the first packet's sequence number is 1). This is the number that is used for anti-replay verification. This value must not cycle - and to prevent that, a new SA would be established.
The ICV caught my notice while reading the RFC. Basically, you can think of this like a checksum. So now add checksum to routing and what happens? Well as the packet moves, the checksum would be different at each hop. The TTL is definitely going to change. So how do you still verify the integrity if there are fields that change? This is where the concept of mutable fields comes in. The exact details of how to handle these fields is explained in the RFC, but I think it would be a good idea to list the mutable fields:
## FOR IPv4 ##
DSCP
ECN
Flags
Fragment Offset
TTL
Header Checksum
## FOR IPv6 ##
DSCP
ECN
Flow Label
Hop Limit
I wouldn't exactly memorize that list, but think about it for a while and it makes sense. It would be good to have seen this and not need it rather than need it and never see it. I think that's deep enough on AH - so on to ESP.
"ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality." ESP is covered in RFC 4303 and uses IP protocol 50.
ESP headers consist of SPI, Sequence Number, Payload Data + Padding, Pad Length, Next Header and ICV. The padding is interesting. Not only does it help the ICV field align properly, but also think about the encryption. That must also meet a certain block size and be a multiple of some number of bytes.
Interestingly enough, the RFC for ESP (RFC 4303) does not discuss algorithms that must be implemented for ESP. Those guidelines can be found in RFC 7321. You're probably wondering why I always include the RFC number in my posts. The more you use them, the more likely you are to remember them. And, since I'm going there to read the RFC, I might as well post the link. [Yes, I read RFCs. Be afraid - very afraid.]
Now think about why they had a separate RFC for mandatory algorithms (or why they have mandatory ones at all). The nature of cryptography is that it is constantly changing. What was secure yesterday (DES) is no longer secure today. Cryptanalysis is a field where they are constantly testing and hammering at algorithms to test their strength. As they are testing today's algorithms, they are also creating new and improved algorithms. When today's strong encryption is no longer considered "strong," you want to be able to move to the newer (currently strong) algorithms. Keeping mandatory standards is one way to make sure that IPsec still works and is still secure and everyone supports the currently secure protocols. That way devices continue to play well together.
The list of algorithms is interesting. But it's a bit difficult to read - since they outline the Old Standard and the New Standard. There are a lot of "SHOULD, MAY, MUST, MUST NOT" in the tables that can be confusing to someone not specifically interested in implementing this in code. I doubt the exam will cover any individual algorithm and/or its update or required usage. More relevant would be this list that I posted previously:
## AH ##
ah-md5-hmac
ah-sha-hmac
## ESP Encryption ##
esp-aes
esp-gcm
esp-gmac
esp-aes 192
esp-aes 256
esp-des
esp-3des
esp-null
## ESP Authentication ##
esp-md5-hmac
esp-sha-hmac
Now that we've gone through this material, let's think about how NAT fits into the picture. [This may be a fair question on the exam.] Think about what was said above about the ICV. Also note that the Source Address is not considered a mutable field. However, if a source uses its real IP address - and that later gets translated at the router, that is definitely going to break the ICV (if that field is part of the ICV calculation). Look again at the diagrams of AH and ESP in my previous post, and compare all of those headers and the "integrity" lines. AH is going to try and authenticate the headers in both tunnel and transport mode. That's what it does. ESP does encryption (with optional integrity checks). The new header in tunnel mode and the original header in transport mode are not checked for integrity. Therefore, if you use (or get a question on) NAT and AH vs ESP -- AH cannot handle NAT and ESP can handle NAT. Now if you do get something on that topic, look closely at the question. ESP can handle NAT, but has trouble with PAT. You don't see a lot of information on this, but think about the difference. NAT maps IP addresses to IP addresses - that would be in the IP header. PAT maps real IP addresses to an IP address and port. Now you're moving out of the realm of the IP header - so it would make sense that there could be issues. Most likely, any question would be AH vs ESP with NAT rather than ESP with NAT vs PAT. But, that's just a guess.
And with that, I'm done reviewing AH and ESP. Another reminder (mainly to myself) - there are 28 listed topics on section 2.0 and it only counts for 14% of the exam. Learn all you can and review everything, but keep things in perspective.