You’re implementing an L2TP/IPsec VPN solution to support remote employees. Which of the following is not true? (Source: Wentz QOTD)
A. AH may not be available in IPsec
B. AH ensures integrity only, but not confidentiality through encryption
C. Implementation of ESP is a mandatory requirement of IPsec
D. ESP ensures both confidentiality and the same level of integrity as AH does
Kindly be reminded that the suggested answer is for your reference only. It doesn’t matter whether you have the right or wrong answer. What really matters is your reasoning process and justifications.
My suggested answer is D. ESP ensures both confidentiality and the same level of integrity as AH does.
Protection Level of Integrity
User data, also known as the payload, is encapsulated into packets by pretending a header or optionally appending a trailer.
Authentication Header (AH) in the tunnel mode prepends an AH header without a trailer and generates a new IP packet. AH compute the hash or Integrity Check Value (ICV) against the whole newly generated IP packet. It provides a higher level of integrity protection than ESP.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Integrity Check Value-ICV (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. AH Format
Encapsulating Security Payload (ESP) in the tunnel model not only pretends an ESP header but also appends an ESP trailer and generates a new IP packet. ESP computes the hash or Integrity Check Value (ICV) to ensure integrity as well, but it works at the payload level instead of the packet level. The ICV doesn’t cover the new IP header and ESP trailer.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Top-Level Format of an ESP Packet
Two versions of IPsec can currently be found in implementations. The “new” IPsec or IPsec-v3 (RFC 4301, 4602, and 4303) obsoleted the “old” IPsec or IPsec-v2 (RFC 2401, 2402, and 2406); however, IPsec-v2 is still commonly found in operational use.
- AH [RFC4302] is mandatory to implement (MUST) in IPsec-v2, optional (MAY) in IPsec-v3
Authentication Header (AH)
The IP Authentication Header (AH) is used to provide:
- connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just “integrity”) and
- protection against replays.
Encapsulating Security Payload (ESP)
ESP can be used to provide:
- data origin authentication,
- connectionless integrity,
- an anti-replay service (a form of partial sequence integrity), and
- (limited) traffic flow confidentiality.
Internet Key Exchange (IKE)
Two versions of IKE can currently be found in implementations. The “new” IKE (IKEv2) obsoleted the “old” IKE (IKEv1); however, IKEv1 is still commonly found in operational use. Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. Since IKE always negotiates pairs of SAs, the term “SA” is generally used to refer to a pair of SAs (e.g., an “IKE SA” or an “IPsec SA” is in reality a pair of one-way SAs).
- The first SA, the IKE SA, is used to protect IKE traffic.
- The second SA provides IPsec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPsec SA. This document uses the term “IPsec SA”.
To further complicate the terminology, since IKEv1 consists of two sequential negotiations, called phases, the IKE SA is also referred to as a Phase 1 SA and the IPsec SA is referred to as a Phase 2 SA.
- “New” IPsec (IPsec-v3)
- RFC 4301, Security Architecture for the Internet Protocol (S, December 2005)
- RFC 4302, IP Authentication Header (S, December 2005)
- RFC 4303, IP Encapsulating Security Payload (ESP) (S, December 2005)
- IPsec and Non-repudiation
- Network packet
- UNDERSTANDING VPN IPSEC TUNNEL MODE AND IPSEC TRANSPORT MODE – WHAT’S THE DIFFERENCE?
A BLUEPRINT FOR YOUR SUCCESS IN CISSP
My new book, The Effective CISSP: Security and Risk Management, helps CISSP aspirants build a solid conceptual security model. It is not only a tutorial for information security but also a study guide for the CISSP exam and informative reference for security professionals.