Chapter 6 – IPsec and Mobile IP
This chapter covers two advanced protocols for TCP/IP, Mobile IP and IPsec. Both of these protocols are available for IPv4 and for IPv6 based networks, but in both cases, there are significant issues with NAT in existing IPv4 networks that severely complicate implementation and deployment. Of course, these issues are not a problem in IPv6 based networks. There are other aspects of IPv6 (support for multicast and link-local addresses) that make both protocols work better on IPv6 than on IPv4. Both of these protocols are quite powerful and add strong incentives for organizations to begin supporting IPv6 sooner rather than later.
6.1 – Internet Protocol Layer Security (IPsec)
The official name for this technology (as used by the IETF) is The Security Architecture for the Internet Protocol. Since it takes place in the Internet Layer, protocols at the Transport and Application Layers need not even be aware of it, and do not need to be modified to use it. In effect, you build secure tunnels at the IP layer that the higher layer protocols go through unmodified. Compare with SSL/TLS where the application layer is heavily impacted, both in the design and implementation stage (many changes to source code and application design), and in deployment stage (obtaining and installing server digital certificates into the server application). You could say that applications get a “free ride” over IPsec, gaining security features (without having to include any support for security themselves) simply by running over Internet Layer links secured with IPsec.
By security we are here referring to three specific aspects of security:
* privacy (keeping others from being able to view the content of your transmissions), accomplished using the Encapsulating Security Payload (ESP) feature
* authentication (knowing for sure who the packets came from), accomplished with the Authentication Header (AH) feature
* message integrity (knowing if someone has made any changes to the data field or certain of the header fields, including the source and destination addresses), also accomplished with the Authentication Header (AH) feature
The AH and ESP features are mutually independent. You can make use of neither, either or both, depending on your requirements. If you need only authentication and message integrity, you can use only AH. If you need only privacy, you can use only ESP. If you require both, you can use both AH and ESP (there is no conflict between them).
Note however, that since AH protects the source and destination addresses in the IP header and the source and destination ports in the TCP or UDP header, any changes at all to these fields will be detected as tampering (to AH there is no way to distinguish malicious tampering from changes your own network makes to these fields). This means AH will report the changes to IP addresses and ports in the header by NAT to be an attack. It is possible to combine NAT traversal with IPsec (as discussed in RFC 3715, “IPsec-Network Address Translation (NAT) Compatibility Requirements”), but this greatly complicates the creation and deployment of IPsec applications, and introduces new security issues which may outweigh the benefits of using IPsec in the first place. IPsec is not very suitable for use on existing IPv4 networks since NAT is so widely deployed. Many network professionals have gotten a bad impression of it, but this is because of NAT in IPv4 networks, not any shortcoming of IPsec. There is no other technology for building VPNs supported by the IETF. IPsec works great in IPv6 networks. This is because of better support in IPv6 headers to some extent, but primarily because there is no NAT.
Any security features at this level (which must be performed once per packet) must be very lightweight (they cannot use mechanisms that require a lot of CPU power). This rules out the use of asymmetric key cryptography (as used in digital signatures and digital envelopes), at least on a per packet basis. Use of asymmetric key cryptography would cause severe degradation of network throughput. Fortunately, there is a lightweight alternative to digital signatures, which is Hash-based Message Authentication Codes (essentially a key driven message digest), which is used in AH. Encryption is handled using only symmetric key encryption and decryption with the same symmetric key for many packets. The key can be manually distributed (shared secret deployment) or securely distributed via the Internet Key Exchange (IKE) protocol, which does use asymmetric key cryptography (but IKE is used infrequently – the exchanged key is used to encrypt or decrypt a large number of packets before another key is exchanged). Even with these lightweight algorithms, there can still be an impact on network throughput (especially on systems with lower performance CPUs). Network Interface Cards (NICs) are available that include hardware acceleration of the IPsec algorithms (HMAC generation and checking, as well as symmetric key encryption/decryption). These allow wire speed network throughput even on systems with low performance CPUs.
6.1.1 – Relevant Standards for IPsec
The following standards are relevant to IPsec and IKE (also see Appendix A on Cryptography and PKI):
* RFC 2407, “The Internet IP Security Domain of Interpretation for ISAKMP”, November 1998
(Standards Track, Obsoleted by RFC 4306)
* RFC 2408, “Internet Security Association and Key Management Protocol (ISAKMP)”, November
1998 (Standards Track, Obsoleted by RFC 4306)
* RFC 2409, “The Internet Key Exchange (IKE)”, November 1998 (Standards Track, Obsoleted by RFC 4306)
* RFC 2410, “The NULL Encryption Algorithm and Its Use With IPsec”, November 1998 (Standards Track)
* RFC 2411, “IP Security Document Roadmap”, November 1998 (Informational)
* RFC 2412, “The Oakley Key Determination Protocol”, November 1998 (Informational)
* RFC 2709, “Security Model with Tunnel-mode IPsec for NAT Domains”, October 1999 (Informational)
* RFC 3193, “Securing L2TP using IPsec”, November 2001 (Standards Track)
* RFC 3554, “On the Use of Stream Control Transmission Protocol (SCTP) with IPsec”, July 2003 (Standards Track)
* RFC 3456, “Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode”, January 2003 (Standards Track)
* RFC 3457, “Requirements for IPsec Remote Access Scenarios”, January 2003 (Informational)
* RFC 3554, “On the Use of Stream Control Transmission Protocol (SCTP) with IPsec”, July 2003 (Standards Track)
* RFC 3566, “The AES-XCBC-MAC-96 Algorithm and Its Use with IPsec”, September 2003 (Standards Track)
* RFC 3585, “IPsec Configuration Policy Information Model”, August 2003 (Standards Track)
* RFC 3602, “The AES-CBC Cipher Algorithm and Its Use with IPsec”, September 2003 (Standards Track)
* RFC 3715, “IPsec-Network Address Translation (NAT) Compatibility Requirements”, March 2004 (Informational)
* RFC 3776, “Using IPsec to Protect IPv6 Signaling Between Mobile Nodes and Home Agents”, June 2004 (Standards Track)
* RFC 3884, “Use of IPsec Transport Mode for Dynamic Routing”, September 2004 (Informational)
* RFC 3947, “Negotiation of NAT-Traversal in the IKE”, January 2005 (Standards Track)
* RFC 3948, “UDP Encapsulation of IPsec ESP Packets”, January 2005 (Standards Track)
* RFC 4025, “A Method for Storing IPsec Keying Material in DNS”, March 2005 (Standards Track)
* RFC 4106, “The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)”, June 2005 (Standards Track)
* RFC 4109, “Algorithms for Internet Key Exchange version 1 (IKEv1)”, May 2005 (Standards Track)
* RFC 4196, “The SEED Cipher Algorithm and Its use with IPsec”, January 2006 (Standards Track)
* RFC 4301, “Security Architecture for the Internet Protocol”, December 2005 (Standards Track)
* RFC 4302, “IP Authentication Header”, December 2005 (Standards Track)
* RFC 4303, “IP Encapsulating Security Payload (ESP)”, December 2005 (Standards Track)
* RFC 4304, “Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)”, December 2005 (Standards Track)
* RFC 4306, “Internet Key Exchange (IKEv2) Protocol”, December 2005 (Standards Track)
* RFC 4307, “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)”, December 2005 (Standards Track)
* RFC 4308, “Cryptographic Suites for IPsec”, December 2005 (Standards Track)
* RFC 4309, “Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)”, December 2005 (Standards Track)
* RFC 4312, “The Camellia Cipher Algorithm and Its Use With IPsec”, December 2005 (Standards Track)
* RFC 4430, “Kerberized Internet Negotiation of Keys (KINK)”, March 2006 (Standards Track)
* RFC 4322, “Opportunistic Encryption using the Internet Key Exchange (IKE)”, December 2005
(Informational)
* RFC 4434, “The AES-XCBC-PRF-128 Algorithm for the Internet Exchange Protocol (IKE)”, February 2006 (Standards Track)
* RFC 4494, “The AES-CMAC-96 Algorithm and Its Use with IPsec”, June 2006 (Standards Track)
* RFC 4543, “The Use of Galois Message Authentication Code (GMAC) in IPsec ERP and AH”, May 2006 (Standards Track)
* RFC 4555, “IKEv2 Mobility and Multihoming Protocol (MOBIKE)”, June 2006 (Standards Track)
* RFC 4615, “The Advanced Encryption Standard-Cipher-based Message Authentication Code- Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)”, August 2006 (Standards Track)
* RFC 4718, “IKEv2 Clarifications and Implementations Guidelines”, October 2006 (Informational)
* RFC 4807, “IPsec Security Policy Database Configuration MIB”, March 2007 (Standards Track)
* RFC 4809, “Requirements for an IPsec Certificate Management Profile”, February 2007 (Informational)
* RFC 4835, “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)”, April 2007 (Standards Track)
* RFC 4868, “Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec”, May 2007 (Standards Track)
* RFC 4869, “Suite B Cryptographic Suites for IPsec”, May 2007 (Informational)
* RFC 4877, “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture”, April 2007 (Standards Track)
* RFC 4891, “Using IPsec to Secure IPv6-in-IPv4 Tunnels”, May 2007 (Informational)
* RFC 4894, “Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec”, May 2007 (Informational)
* RFC 4945, “The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX”, August 2007 (Standards track)
* RFC 5265, “Mobile IPv4 Traversal across IPsec-Based VPN Gateways”, June 2008 (Standards Track)
* RFC 5374, “Multicast Extensions to the Security Architecture for the Internet Protocol”, November 2008 (Standards Track)
* RFC 5386, “Better-Than-Nothing Security: An Unauthenticated Mode of IPsec”, November 2008 (Standards Track)
* RFC 5406, “Guidelines for Specifying the Use of IPsec Version 2”, February 2009 (Best Current Practice)
* RFC 5529, “Modes of Operation for Camellia for Use with IPsec”, April 2009 (Standards Track)
* RFC 5566, “BGP IPsec Tunnel Encapsulation Attribute”, June 2009 (Standards Track)
* RFC 5660, “IPsec Channels: Connection Latching”, October 2009 (Standards Track)
* RFC 5755, “An Internet Attribute Certificate Profile for Authorization”, January 2010 (Standards Track)
6.1.2 – Security Association, Security Association Database and Security Parameter Index
A Security Association (SA) is a collection of which protocols and algorithms to use for authentication and encryption, together with the keys used, for communication in one direction between two IPsec enabled nodes (e.g. From Alice to Bob). A different SA is created for communication in the other direction, between the same two nodes (e.g. from Bob to Alice). Each pair of communicating IPsec nodes require an SA for each direction that data will be sent between them (normally both directions). Each node stores both SAs for a connection in its SADB. It refers to the SA for outgoing traffic when it sends packets, and the SA for incoming traffic when it receives packets. When a secure connection is set up the first time (or if anything is changed) then the relevant Security Associations are negotiated and stored.
A Security Association Database (SADB) is a collection of Security Associations, on a given node. Each IPsec enabled node has its own SADB (this is not stored in a central DBMS, and in fact does not resemble what most people would call a Database – it’s really more of a simple table). As the node negotiates Security Associations with other nodes, it stores each new one into its SADB.
The Security Parameter Index (SPI) is an index into the SADB. An SPI together with a destination IP address uniquely identifies a particular security association.
6.1.3 – IPsec Transport Mode and IPsec Tunnel Mode
There are two modes in which a given IPsec connection can operate: Transport Mode and Tunnel Mode. In Transport Mode, with AH, only the packet payload plus certain fields in the packet headers (including source and destination IP addresses and source and destination port numbers) are authenticated. This means the contents of the payload and those header fields are included in the calculation of the AH cryptographic checksum using HMAC. None of those fields are modified in any way by IPsec. Therefore the original addresses are used for routing of the packet. However, if NAT modifies any of these header fields as the packet goes through a NAT gateway (which is the normal behavior of NAT) then the cryptographic checksum will fail when the packet is received (after all, someone has tampered with the packet contents).
In IPv4 Transport Mode, the AH packet header is inserted after the IP header, but before the TCP header, as follows:
In IPv6 Transport Mode, the original IP packet header comes first, followed by one or more extension headers, one of which is the new AH header, followed by the TCP (or UDP) header, then data field (payload).
In Transport Mode with ESP, only the TCP header and the data field (payload) are encrypted. No other header fields are encrypted, or the packet could not be delivered. Transport mode is used only for host- to-host communications. No IPsec gateway is required. Any node involved in a Transport Mode IPsec connection must have support for IPsec Transport Mode. If automated key exchange is to be used, those nodes must also support a common Key Exchange protocol (IKEv1, IKEv2 or KINK). If available, IKEv2 is preferred. If IKE is used, each node requires an appropriate IPsec digital certificate that binds the public key to their IP address(es). If KINK is used, then a Kerberos Key Distribution Center must be available to all nodes using it.
In IPv4 Transport Mode with ESP, the original IP header comes first, followed by the ESP header, followed by the TCP (or UDP) header, followed by the data. With ESP, after the data field, there is an ESP Trailer and an Integrity Check Value (ICV). Encryption is done on the TCP header, the Data field (payload) and the ESP Trailer. Integrity (for the ICV) covers those fields plus the ESP header.
In IPv6 Transport Mode with ESP, the original IP header comes first, followed by one or more extension headers, one of which is the ESP extension header, followed by the original TCP header, then the data field (the packet payload). As with IPv4, there is an ESP trailer, and an ESP ICV. Encryption is done on any extension headers after the ESP extension header, the TCP header, the Data field (payload) and the ESP Trailer. Integrity (for the ICV) covers those fields plus the ESP header.
In Tunnel Mode (with AH and/or ESP), the entire original IP packet (all headers plus the payload) are encrypted and/or authenticated. The result is encapsulated into a new IP packet with new headers. This encapsulation is added to packets on the way out by an IPsec tunnel gateway, and removed on the way at the other end of the network path by another IPsec tunnel gateway. In between, it looks like a normal IPv4 (or IPv6) packet that has an odd looking payload, and is routed like any other packet. The IP version of the inner packet does not have to be the same as the IP version of the outer packet. You can tunnel IPv6 packets over IPv4, or IPv4 packets over IPv6. The node you connect to must support the version(s) of IP you send to it, though. After the encapsulation is removed and the authentication and/or encryption are removed, the resulting packet is forwarded to the inside of the tunnel gateway, where it continues on to its destination.
In IPv4 Tunnel Mode with AH, the outer IP header comes first (possibly with options), followed by the new AH header, followed by the original entire packet.
In IPv6 Tunnel Mode with AH, the outer IP header comes first, followed by one or more extension headers, including the AH extension header, followed by the original entire packet (which itself may contain extension packet headers, but they won’t be processed until after the packet is de-tunneled).
In IPv4 Tunnel Mode with ESP, the outer IP header comes first, followed by the ESP header, followed by any options from the original packet header, followed by the TCP (or UDP) header, followed by the data field (payload). Again, the data is followed by an ESP Trailer and ESP ICV. Encryption covers everything after the ESP header, up to and including the ESP trailer. The integrity value covers all of that plus the ESP header.
In IPv6 Tunnel Mode with ESP, the outer packet IP packet header comes first followed by any new packet header extensions, followed by the ESP header, then the entire original packet. As before, the data field (payload) is now followed by the ESP trailer and the ESP ICV. Encryption covers everything after the ESP header, up to and including the ESP trailer. The integrity value covers all of that plus the ESP header.
The IPsec tunnel processing can be physically located inside a gateway firewall or router, or it can be a in a node that does just IPsec tunneling, on the inside of an existing router or firewall. All IPsec related processing (generating or validating the HMAC cryptographic checksum and/or packet encryption/decryption) takes place in the tunneling IPsec node. IPsec Tunnel Mode is primarily used for network-to-network tunnels, but it can be used for host-to-network communications (e.g. a road warrior connecting into the home network securely), or even host-to-host communications (e.g. for private chat or VoIP). If any host (as opposed to a gateway) is involved in an IPsec Tunnel Mode connection, those nodes would need to support IPsec tunnel mode. If the tunnel is built between two gateway nodes (network-to-network tunnel), then any other node in the either network can send things through that tunnel without having to know anything about IPsec. If automated key exchange is to be used, the participating nodes must also support a common Key Exchange protocol (IKEv1, IKEv2 or KINK). If available, IKEv2 is preferred. If IKE is used, each node requires an appropriate IPsec digital certificate that binds the public key to their IP address(es). If KINK is used, then a Kerberos Key Distribution Center must be available to all nodes using it.
An IPsec tunnel must be set up in the sending and receiving nodes so that the sending node knows what address to put in the outer packet header. This configuration would specify things like “all traffic destined for 123.45.56.00/24 is to be tunneled and sent to the gateway located at 123.45.67.1”, or “Accept IPsec tunneled traffic from the node which is located at 87.65.34.21, de-tunnel it, and route the inside packet onto the LAN”. Regardless of what transport the original traffic used (TCP or UDP), the tunneled traffic will be over UDP. This introduces additional overhead, and can complicate the built-in error recovery mechanism in TCP. The IP addresses in the outer packet header are not authenticated.
If IPv4 tunneled traffic crosses any router, the addresses of all nodes musts be valid global unicast IP addresses (although this could be simulated using BINAT with a node that has a private IP address behind a NAT gateway). It would be possible to create an IPsec path over IPv4 entirely within a routing domain using private IP addresses. Basically there must be a flat address space (or a reasonable facsimile thereof) over the entire path of the connection. A classic problem with VPNs connecting nodes in disjoint private networks is that the private address spaces in the two networks must not overlap. If two companies are both using 10.0.0.0/8 as their private addresses, either VPNs will not work between them, or at least one network must renumber (e.g. to 172.16.0.0/12). If you have an HQ network and several branch offices, you might want to use 10.0.0.0/16 for HQ, 10.1.0.0/16 for the first branch office, 10.2.0.0/16 for the second branch office, etc. This would allow up to 256 branch offices, each with up to 65,535 nodes. This way, if you do want to build VPNs between them someday, there will not be any overlap.
6.1.4 – IPsec over IPv6
In IPv6, none of the issues related to NAT arise, since all nodes can easily obtain global unicast IPv6 addresses, and the entire world is a single flat address space. IPsec works beautifully over IPv6, and this is one of the strongest arguments for migrating to Dual Stack sooner rather than later. Use the IPv6 side for protocols that require a flat address space, such as IPsec, SIP, P2P, etc. Use the IPv4 side for legacy applications like web surfing, e-mail, etc. You can gradually move those over to IPv6 as well.
The IPv6 packet header design supports IPsec very well. There are two packet header extensions defined, one for AH and one for ESP. The AH extension header will be inserted if and only if AH is used on that packet. For details, see RFC 4302, “IP Authentication Header”. The ESP extension header will be inserted if and only if ESP is used on that packet. For details, see RFC 4303, “IP Encapsulating Security Payload (ESP)”.
6.1.5 – IPsec in Multicast Networks
It is possible to deploy IPsec in a multicast network. Security Association negotiation is rather more complicated in a one-to-many connection than in a one-to-one connection. RFC 5374, “Multicast Extensions to the Security Architecture for the Internet Protocol” covers the details. IPsec in multicast networks could allow content providers to control access to multicast content using ESP and some clever key management. For example, each valid subscriber could be issued a unique IPsec digital certificate (tied to their set top box) that would allow decrypting the symmetric session key used to encrypt the content. If they don’t pay their bill, their certificate could be revoked.
6.1.6 – Using IPsec to secure L2TP Connections
L2TP (Layer 2 Tunneling Protocol) itself does not provide either privacy or authentication. RFC 3193, “Securing L2TP using IPsec” specifies how to use IPsec in conjunction with it to add privacy (with ESP) and/or authentication (with AH) to an L2TP based system.
6.2 – Internet Key Exchange (IKE)
The Internet Key Exchange (IKEv1 and IKEv2) is based on ISAKMP (Internet Security Association and Key Management Protocol), which is a framework for key exchange. It uses parts of the Oakley and SKEME (Secure Key Exchange MEchanism for Internet) protocols within this framework. Oakley describes a series of key exchanges, known as modes, and specifies things such as perfect forward secrecy for keys, identity protection and authentication. It is discussed in RFC 2412, “The Oakley Key Determination Protocol”. SKEME(Secure Key Exchange MEchanism for Internet) is a key exchange technique which provides anonymity and quick key refreshment. There is no RFC that covers SKEME, but there are some papers available online. There is coverage of the parts of Oakley and SKEME used in IKE in RFCs 2408 and 2409.
IKE uses the Diffie-Hellman Key Agreement protocol (see Appendix A) to securely exchange a shared secret, from which symmetric session keys for AH and ESP are derived. IKE is also used to mutually authenticate nodes to each other. Authentication can be accomplished with a pre-shared secret (manually distributed to each node), or by use of IPsec digital certificates (ones that bind IPv4 and/or IPv6 addresses to the public key). Each pair of nodes that use IPsec use IKE to do key exchange and mutual authentication, which results in setting up a Security Association (SA) at each end for the other node in the pair.
IKE is usually implemented as a daemon process (a software application that starts running when the computer boots, and stays running until shutdown) on each IPsec enabled node, in user space. IKE communicates via UDP over port 500. There is no client or server role, the communication is between peers. Either node of a pair can initiate an IKE connection, and the other node will accept it. The AH and ESP packet processing is embedded in the TCP/IP stack (specifically in the IP layer), which usually runs in kernel space.
There are two phases in an IKE connection, called (imaginatively enough) Phase 1 and Phase 2.
IKE Phase 1 establishes an encrypted, authenticated communication channel between the two parties. It first uses the Diffie-Hellman Key Agreement protocol, which produces a shared secret. A symmetric session key is derived from the shared secret by both parties, which is used to encrypt further IKE exchanges. The goal of Phase 1 is to create a bidirectional ISAKMP Security Association (SA). Mutual Authentication can be accomplished using either a pre-shared secret, or via cryptographic challenge/response using IPsec public key digital certificates. Either a pre-shared secret, or an IPsec certificate must be installed on each IPsec enabled node when the system is deployed. Phase 1 can operate in either Main Mode or Aggressive Mode. Main Mode protects the identities of the nodes, but takes longer. Aggressive mode is faster, but does not protect the identities of the nodes.
IKE Phase 2 uses the secure channel established in Phase 1 to negotiate additional Security Associations (SAs) for services such as IPsec. The output of Phase 2 is a pair of unidirectional SAs (one for traffic from Alice to Bob and one for traffic from Bob to Alice). On each node, one of these SAs is used for inbound traffic and the other one for outbound traffic. Phase two operates in