Security is among the most important considerations in network design. Malicious users and attackers are always trying to find ways of compromising the privacy and confidentiality of communication networks, so network designers must always keep security top of mind.
IPv4 was developed at a time when the internet was small: Security concerns were much lower due to the technology’s extremely limited initial deployment. In addition, TCP/IP was originally used only within academia, the government, and large corporations, where there was an attitude of trust and transparency. Any security was simply taken care of by upper-layer protocols.
As the mitigation of network attacks and malicious activities became more and more important, security features were added to IPv4 by employing “add-on” frameworks of encryption and authentication in the form of the Internet Protocol Security (IPsec) suite. IPsec is more than sufficient to secure IPv4 communications, but the fact that it is not inherently a part of the IP protocol specification makes it somewhat more complex and cumbersome to implement.
IPv6 was designed with inherent security features based on the lessons learned from IPv4. This includes designing security as an inseparable part of the IPv6 structure and streamlining and simplifying its implementation. In this article, we look at how IPsec has been integrated into IPv6 and how it ensures secure end-to-end network communications.
Summary of key concepts
In the table below, you will find a summary of the concepts covered in this article.
What is IPsec?
IPsec is not a protocol itself but rather a framework of multiple protocols, encryption methods, authentication processes, and cryptographic algorithms used to implement authentication, confidentiality, and encryption and to ensure data integrity in IP communications. The framework is broken down into several components and functions, as shown in the following diagram.
Each operation can use a different protocol, encryption method, or algorithm to apply the required security.
{{banner-13="/design/banners"}}
Applying IPsec to IPv4
In an IPv4 environment, IPsec components are implemented using additional headers within which the original IP packet is encapsulated. For example, the following illustrates how some of the above-mentioned mechanisms are applied within the IPsec header and trailer.
What those additional headers contain depends upon the protocol, encryption method, authentication, and key exchange algorithm used.
IPv6 extension headers
One of the challenges faced by the designers of the IPv6 protocol was to integrate the security delivered by IPsec into the header structure of the IPv6 protocol without making IPv6 overly complex, cumbersome, and computationally costly to process. The solution was the use of extension headers.
This is a standard IPv6 header:
Notice the 8-bit field called “Next Header.” The value found in this field indicates whether this IPv6 packet has an extension header and, if so, what kind it is. If there are no more IPv6 extension headers, this field contains a number that indicates the Transport Layer protocol being used. For example, a value of 6 indicates that TCP is used, while a value of 17 indicates the use of UDP.
An extension header is an additional header that is inserted after the main IPv6 header but before the IPv6 packet payload. Multiple extension headers can be added to the main IPv6 header depending on the features to be enabled, which is known as chaining extension headers. The following diagram shows an example of an IPv6 packet with only the main IPv6 header and another IPv6 packet with a chain of IPv6 extension headers.
{{banner-9="/design/banners"}}
Like the main IPv6 header, each extension header has a “Next Header” field that indicates if another extension header or the payload follows, which is what allows chaining to be done. Some of the values that can be found in the “Next Header” field include:
- 51: Authentication Header (AH)
- 50: Encapsulation Security Payload Header (ESP)
- 59: No next header
There are currently about a dozen defined extension headers with various values, and more are being added as the need arises. Those that pertain to security are the AH and ESP extension headers listed above.
Authentication Header
The Authentication Header (AH) is defined in RFC4302 and performs three primary functions:
- Message Integrity: It provides verification that the IPv6 packet payload remained unmodified during the entirety of its journey from source to destination.
- Source Authentication: The AH allows certification that the source of the IPv6 packet is indeed the source from which the data is expected.
- Replay Protection: Protection against replay attacks is provided using a sequence number field.
These functions are fulfilled using the fields within the AH structure as shown below:
Here’s how the information within this header delivers message integrity and source authentication:
- Security Parameter Index (SPI): This field identifies all the packets that belong to a particular connection between source and destination and authenticates the packet’s source. Before beginning communication, the source and destination must negotiate an algorithm and key, which are used to authenticate every IPv6 packet based on the value in the SPI.
- Sequence Number: This counter increments by one for each packet sent, which helps to mitigate replay attacks.
- Authentication Data: This is a variable length field that contains an integrity check value (ICV). Using a specific algorithm, a digest is created upon receipt, and if the digest is the same as the ICV, the packet is considered unmodified and is accepted.
The implementation of AH provides numerous practical benefits to a data stream:
- Integrity: It ensures that the payload has not been changed in transit.
- Origin Authentication: The AH verifies that the data has indeed been sent by the expected sender.
- Replay Protection: It protects the data stream from malicious or fraudulent retransmissions or delays.
It’s important to note here that AH does not provide any data confidentiality: Data sent using AH is not encrypted.
{{banner-10="/design/banners"}}
Encapsulation Security Payload Header
The Encapsulation Security Payload (ESP) header is defined in RFC 4303. It can perform the same security functions as AH, but it also adds data confidentiality to the mix. The following diagram illustrates the field structure of the IPv6 extension header used by ESP:
The fields shown above perform the following functions:
- Security Parameter Index (SPI): This value identifies the security association (SA) to which this packet belongs. An SA essentially specifies the security properties that are recognized by the communicating hosts. The SPI is an identifier that allows a receiver to map inbound traffic to an SA.
- Sequence Number: As with the Authentication Header, this is a counter that increments by one for each packet sent and is useful to mitigate replay attacks.
- Payload Data: This is the data that is being transmitted securely.
- Padding and Padding Length: These fields are used to properly align the payload data to the size of the IPv6 packet; they are also used for certain encryption algorithms.
- Next Header: As described before, the contents of this field identify either the next header type or the Transport Layer protocol being employed.
- Authentication Data: Has the same function as in the AH, delivering payload integrity.
Again, from a practical standpoint, the use of ESP addresses numerous practical concerns for data transmissions. Like AH, ESP provides integrity, origin authentication, and replay protection. However, importantly, it also provides strong data confidentiality (encryption), ensuring that even if the data is intercepted in transit, it will be unintelligible and ultimately useless for any malicious purpose.
Note that ESP, unlike AH, adds a trailer that contains the Padding, Padding Length, Next Header, and Authentication Data fields. Any further extension headers that are added after the ESP header are encapsulated within the payload data, and the ESP trailer is appended at the end.
Implementing AH and ESP extension headers
Either of the extension headers can be used alone when securing IPv6 communications, or both headers can be applied together to the same IPv6 packet in an extension header chain. AH authenticates IP headers and their payloads, while ESP authenticates only the IP datagram portion of the IP packet and not the header itself. Conversely, ESP delivers confidentiality via data encryption, while AH does not. As a result, the combination of which protocols to use depends upon the security requirements of the particular communication taking place.
Typically, if both AH and ESP are employed, the extension header format will look something like this:
Comparing IPsec for IPv4 with IPv6
You may wonder if the IPsec implementation of IPv6 is more secure than that of IPv4. The answer is no: IPsec applied to IPv4 and the integrated IPsec as designed for IPv6 both provide the same level of security in all aspects. The actual security mechanisms haven’t changed; they have simply been incorporated into the IPv6 protocol itself.
The primary benefits here are not enhanced security but rather elegance and ease of implementation. As part of the IPv6 header structure, both ESP and AH extension headers can be added without increasing the complexity of the IPv6 header and without having to change the fundamental structure of the IPsec framework.
{{banner-sre="/design/banners"}}
Conclusion
IPv6 has integrated the security features provided by the IPsec security framework into its extension header structure, making the implementation of security more streamlined and elegant. The AH extension header can be used to authenticate packets and ensure data integrity while mitigating replay attacks. Similarly, the ESP extension header delivers all of these advantages, plus the encryption of the actual packet payload.
These options can be used individually or together to provide a more granular set of configurable parameters to achieve the level of security required for your particular network and applications.
