IPv6 Packet Security
Unlike IPv4, IPsec security is mandated in the IPv6 protocol specification,
allowing IPv6 packet authentication and/or payload encryption via the Extension
Headers. However, IPsec is not automatically implemented, it must be configured
and used with a security key exchange.
IPv6 Packet Structure
The IPv6 header is not variable, as in IPv4, but has a simple, efficient fixed
40-byte length. Minimum packet size is 1280 bytes, from 40 bytes of header plus
1240 bytes of payload.
Next Header Field
The Next Header field defines the type of header immediately following the
current one. It is usually the payload, but sometimes Extension Headers provide
valuable functions. Encryption capabilities are defined by the Authentication
and Encapsulated Security headers.
Protocol numbers in required order of use
000 Hop-by-hop – must be examined by every node on path to destination
043 Routing header – list of nodes that should be visited on path
060 Destination options – processed by routers along path
044 Fragment header – packet was fragmented at source if too large for path
051 Authentication header – part of IPsec
050 Encapsulated security payload – IPsec
060 Destination options – processed at destination
Right: A simple IPv6 packet (top row) with a TCP
header and data payload. The second row shows the packet with an additional
Routing header, third row has Routing and Fragment headers.
IPv6 Packet Encryption
IPsec defines cryptography-based security for both IPv4 and IPv6 in RFC 4301.
IPsec support is an optional add-on in IPv4, but is a mandatory part of IPv6.
It provides two security headers which can be used separately or together:
Authentication Header (AH) and Encapsulating Security Payload (ESP), used in
conjunction with security key exchange.
AH provides connectionless integrity, data-origin authentication and protection
against replay attacks. It authenticates with an Integrity Check Value (ICV)
calculated over the payload, the header, and unchanging fields of the IPv6
header and options. AH does not provide privacy and confidentiality of packet
contents. See RFC 2402.
Encapsulating Security Payload
ESP also provides connectionless integrity, data-origin authentication,
protection against replay attacks, limited traffic flow confidentiality, but
also provides privacy and confidentiality through encryption of the payload.
See RFC 2406.
IPSec operates in two different modes: Transport mode (host-to-host) and Tunnel
mode (gateway-to-gateway or gateway-to-host).
Transport mode: the IPv6 header of the original packet is used, followed
by the AH or ESP header, then the payload.
Extension headers (Hop-by-Hop, Routing, Fragmentation) immediately follow their
IP headers, except for Destination Options, which can appear before or after AH
or ESP. ('TCP' below indicates any upper layer protocol.)
Tunnel mode: a new IPv6 header encapsulates the AH or ESP header and the
original IP header and payload.
AH in Transport & Tunnel Modes
AH authenticates the packet and the outermost IPv6 addresses (except for
mutable fields), but does not encrypt payloads. AH cannot be used to traverse
NATs, as it calculates the integrity check value (ICV) over source and
destination addresses: NATs translate addresses, so would invalidate ICVs.
ESP in Transport & Tunnel Modes
ESP authentication does not include the outermost IPv6 headers, but in Tunnel
mode it protects the original headers. ESP is used to build virtual private
network tunnels between sites. It permits NAT traversal, as it does not use the
outermost address values in the ICV calculation. If AH and ESP are used
together, ESP is applied first, then AH authenticates the entire new packet.
The Security Association
Security Association is a record of the authentication algorithm, encryption
algorithm, keys, mode (transport or tunnel), sequence number, overflow flag,
expiry of the SA, and anti-replay window. The SA is held in a database at each
endpoint, indexed by outer destination address, IPsec protocol (AH or ESP), and
Security Parameter Index value.
Selection of SA can be manually (pre-shared keys) but preferably is automated
with Internet Key Exchange (IKE, IKEv2). IKE uses Diffie-Hellman techniques to
create a shared secret encryption key used to negotiate SA data. For key
exchange, IKE depends on a Public Key Infrastructure (PKI), which is not yet
widespread. The framework and syntax for key exchange is ISAKMP (Internet
Security Association and Key Management Protocol). See RFC 2408.