|
|
IPsec (Internet Protocol Security) framework is a set of open standards developed by the IETF.
IPsec is implemented by a set of cryptographic protocols for securing IP traffic.
IPsec framework secures IP traffic operating at the Layer 3 (network layer) of the OSI model, thus securing all network applications and communications that use the IP network.
Using combinations of hashing, symmetric key, and asymmetric key cryptographic algorithms discussed in Chapter 14, the IPsec framework offers the following security services:
Peer Authentication
Data integrity
Data origin Authentication
Replay detection
Access control
Traffic flow confidentiality
As mentioned earlier, IPsec is a set of open standards that is documented in several RFCs. Originally, IPsec was defined in a series of RFCs 1825–1829, published in 1995. As technology evolved, these were updated by newer revisions and made obsolete by RFCs 2401–2412 published in 1998.
In 2005, a third-generation of RFCs 4301–4309 (superset of 2401–2412) was produced to include further advancements in this realm. IPsec VPN technology has changed significantly in the past few years.
Note
The third-generation of RFCs 4301–4309 standardized the abbreviation of IPsec to uppercase IP and lowercase sec.
Tables 15-1 through 15-5 list IPsec-related RFCs arranged by the categories they apply to.
Table 15-1 lists the general IPsec RFCs.
Table 15-2 lists various RFCs related to Encapsulating Security Payload (ESP) and Authentication Headers (AH).
| RFC | Description |
|---|---|
| RFC 4302 | "IP Authentication Header" (proposed standard) |
| RFC 4303 | "Encapsulating Security Payload (ESP)" (proposed standard) |
| RFC 4304 | "Extended Sequence Number Addendum to IPsec DOI for ISAKMP" (proposed standard) |
| RFC 4305 | "Cryptographic Algorithm Implementation Requirements for ESP and AH" (proposed standard) |
Table 15-3 lists various RFCs related to key exchange.
| RFC | Description |
|---|---|
| RFC 4306 | "Internet Key Exchange (IKEv2) Protocol" (proposed standard) |
| RFC 4718 | "IKEv2 Clarifications and Implementation Guidelines" (informational RFC) |
| RFC 4307 | "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2" (IKEv2) (proposed standard) |
| RFC 4308 | "Cryptographic Suites for IPsec" (proposed standard) |
| RFC 2407 | "Internet IP Security Domain of Interpretation for ISAKMP—made obsolete by RFC 4306" (IKEv2) |
| RFC 2408 | "Internet Security Association and Key Management Protocol (ISAKMP)—made obsolete by RFC 4306" (IKEv2) |
| RFC 2409 | "Internet Key Exchange (IKE)—made obsolete by RFC 4306" (IKEv2) |
| RFC 4109 | "Algorithms for IKEv1" (proposed standard) |
| RFC 3715 | "IPsec-NAT Compatibility Requirements" (informational RFC) |
| RFC 3948 | "UDP Encapsulation of IPsec Packets" (proposed standard) |
| RFC 3947 | "Negotiation of NAT-Traversal in the IKE" (proposed standard) |
| RFC 3766 | "Determining Strengths for Public Keys Used for Exchanging Symmetric Keys—Best Current Practice" (BCP 86) |
| RFC 2412 | "OAKLEY Key Determination Protocol" (informational RFC) |
| RFC 2367 | "PF_KEY Key Management API, Version 2" (informational RFC) |
| RFC 2522 | "Photuris: Session-Key Management Protocol" (experimental RFC) |
| RFC 2523 | "Photuris: Extended Schemes and Attributes" (experimental RFC) |
| RFC 3129 | "Requirements for Kerberized Internet Negotiation of Keys" (informational RFC) |
| RFC 4025 | "Method for Storing IPsec Keying Material in DNS" (proposed standard) |
| RFC 4595 | "Use of IKEv2 in the Fiber Channel Security Association Management Protocol" (informational RFC) |
| RFC 3547 | "Group Domain of Interpretation" (proposed standard) |
| RFC 4322 | "Opportunistic Encryption Using the Internet Key Exchange (IKE)" (informational RFC) |
| RFC 4478 | "Repeated Authentication in IKEv2" (experimental RFC) |
Table 15-4 lists various RFCs related to cryptographic algorithms.
| RFC | Description |
|---|---|
| RFC 2405 | "ESP DES-CBC Cipher Algorithm with Explicit IV" (proposed standard) |
| RFC 2451 | "ESP CBC-Mode Cipher Algorithms" (proposed standard) |
| RFC 2104 | "HMAC: Keyed-Hashing for Message Authentication" (informational RFC) |
| RFC 2202 | "Test Cases for HMAC-MD5 and HMAC-SHA-1" (informational RFC) |
| RFC 2403 | "Use of HMAC-MD5-96 Within ESP and AH" (proposed standard) |
| RFC 2404 | "Use of HMAC-SHA-1-96 Within ESP and AH" (proposed standard) |
| RFC 2857 | "Use of HMAC-RIPEMD-160-96 Within ESP and AH" (proposed standard) |
| RFC 2410 | "NULL Encryption Algorithm and Its Use with IPsec" (proposed standard) |
| RFC 1828 | "IP Authentication Using Keyed MD5" (proposed standard) |
| RFC 1829 | "ESP DES-CBC Transform" (proposed standard) |
| RFC 2085 | "HMAC-MD5 IP Authentication with Replay Prevention" (proposed standard) |
| RFC 3173 | "IP Payload Compression Protocol (IPComp)" (proposed standard) |
| RFC 2394 | "IP Payload Compression Using DEFLATE" (informational RFC) |
| RFC 2395 | "IP Payload Compression Using LZS" (informational RFC) |
| RFC 3051 | "IP Payload Compression Using ITU-T V.44 Packet Method" (informational RFC) |
| RFC 3526 | "More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE)" (proposed standard) |
| RFC 3566 | "AES-XCBC-MAC-96 Algorithm and Its Use with IPsec" (proposed standard) |
| RFC 3602 | "AES-CBC Cipher Algorithm and Its Use with IPsec" (proposed standard) |
| RFC 4434 | "AES-XCBC-PRF-128 Algorithm for IKE" (proposed standard) |
| RFC 3686 | "Using AES Counter Mode with IPsec ESP" (proposed standard) |
| RFC 4309 | "Using AES CCM Mode with IPsec ESP" (proposed standard) |
| RFC 4196 | "SEED Cipher Algorithm and Its Use with IPsec" (proposed standard) |
| RFC 4270 | "Attacks on Cryptographic Hashes in Internet Protocols" (informational RFC) |
| RFC 4312 | "The Camellia Cipher Algorithm and Its Use with IPsec" (proposed standard) |
| RFC 4106 | "Use of Galois Message Authentication Code (GMAC) in IPsec ESP" (proposed standard) |
| RFC 4359 | "Use of RSA/SHA-1 Signatures Within ESP 2 and AH" (proposed standard) |
| RFC 4493 | "AES-CMAC Algorithm" (informational RFC) |
| RFC 4494 | "AES-CMAC-96 Algorithm and Its Use with IPsec" (proposed standard) |
| RFC 4615 | "AES-CMAC-PRF-128 Algorithm for IKE" (proposed standard) |
| RFC 4634 | "US Secure Hash Algorithms (SHA and HMAC-SHA)" (Informational RFC) |
| RFC 4231 | "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512" (proposed standard) |
Table 15-5 lists various RFCs related to IPsec policy handling.
| RFC | Description |
|---|---|
| RFC 3585 | "IPsec Configuration Policy Information Model" (proposed standard) |
| RFC 3586 | "IP Security Policy Requirements" (proposed standard) |
IPsec has two methods of propagating the data across a network:
Tunnel mode: Protects data in network-to-network or site-to-site scenarios—for example, Network A in Site1 to Network B in Site2. In tunnel mode, IPsec protects data on behalf of other network entities—that is, encrypt traffic through IPsec peers. Tunnel mode encapsulates and protects the entire IP packet—the payload including the original IP header and a new IP header. In addition, the IPsec header is added as shown in Figure 15-1.
Transport mode: Protects data in host-to-host or end-to-end scenarios—for example, Host A in Site1 to Host B in Site2. Transport mode is used for peer-to-peer scenarios only—that is, encrypt traffic between IPsec peers. In transport mode, IPsec protects the payload of the original IP datagram by excluding the IP header. Unlike tunnel mode, transport mode retains the original IP header and inserts the IPsec header between the original IP header and the payload, as shown in Figure 15-2. Transport mode is available only when the IPsec endpoints are the source and destination of the original IP datagram. Transport mode is commonly used by end systems to protect individual sockets or by intermediate systems to protect already tunneled traffic.
Both tunnel mode and transport mode can be deployed with ESP or AH protocols.
Figure 15-1 depicts how IPsec tunnels are established and how packets are encapsulated in tunnel mode.
Figure 15-2 depicts how IPsec tunnels are established and how packets are encapsulated in transport mode.
As illustrated in Figures 15-1 and 15-2, IPsec adds a new IPsec header to all IP datagrams to provide information for securing the data of the original IP datagram.
There are two types of IPsec headers:
Encapsulating Security Payload (ESP): ESP is an IP-based protocol that uses IP port 50 for communication between IPsec peers. Figure 15-3 shows the ESP header format. ESP is used to protect the confidentiality, integrity, and authenticity of the data and offers anti-replay protection. ESP does not provide protection to the outer IP header, as shown in Figure 15-4. When used for data integrity, it does not include the invariant field in the IP header. ESP is documented in RFC 4303.
Authentication Header (AH): AH is also an IP-based protocol that uses IP port 51 for communication between IPsec peers. Figure 15-5 shows the AH header format. AH is used to protect the integrity and authenticity of the data and offers anti-replay protection. Unlike ESP, AH provides protection to the IP header as shown in Figure 15-6. AH does not provide confidentiality protection. AH is documented in RFC 4302.
Figure 15-3 depicts the ESP header structure. Figure 15-4 shows the packet structure and the security services offered by the ESP protocol, illustrating which parts of the packet are authenticated and encrypted.
Figure 15-5 depicts the AH header structure, and Figure 15-6 shows the packet structure and the security services offered by the AH protocol, illustrating which parts of the packet are authenticated. As mentioned earlier, AH does not offer confidentiality.
ESP and AH can be used either independently or together. In most applications, using only one is adequate to meet the security requirements.
IPsec architecture does not limit the use of individual algorithms when implementing ESP or AH protocol, but provides an open framework to implement industry standard algorithms. Most implementations of IPsec commonly use MD5 or SHA algorithms, which are used for data integrity and authentication. DES, 3DES, and AES, however, are the common protocols used for encryption. Several other algorithms are available, as discussed in Chapter 14.
Both ESP and AH protocols provide an anti-reply mechanism, which is mainly based on sequence numbers combined with authentication to defeat replay attacks. The sender increments the sequence number after each transmission, and the receiver can (optionally) check the sequence number and reject the packet if it is out of sequence.
Without the anti-replay mechanism, an intruder could sniff and replay intercepted encrypted packets to cause unnecessary floods, route flaps, and denial-of-service (DoS) attacks.
IPsec requires secure key determination and key distribution mechanisms. The following two protocols define the framework for this:
Internet Security Association and Key Management Protocol (ISAKMP): ISAKMP describes the framework for key management and defines the procedure and packet format necessary to establish, negotiate, modify, and delete security association (SA). ISAKMP offers the identification of the peers only. It does not offer a key exchange mechanism. ISAKMP is documented in RFC 2408, made obsolete by RFC 4306 (IKEv2).
IKE (Internet Key Exchange): IKE is a hybrid protocol—a combination of ISAKMP, Oakley key exchange, and SKEME protocols—that defines a proper key exchange mechanism. IKE defines the mechanism for creating and exchanging keys. IKE derives authenticated keying material and negotiates SAs that are used for ESP and AH protocols. IKE uses UDP port 500. IKE is documented in RFC 2409, made obsolete by RFC 4306 (IKEv2).
Note
ISAKMP and IKE keywords are used interchangeably in IPsec papers. This chapter uses IKE as the standard convention.
IKE is a two-phase, multimode protocol that offers three methods for authenticating a remote peer:
Preshared key: Uses statically defined keys and is the most common method because of its ease of deployment; however, it is not a scalable and secure method.
Public key signature (rsa-signature): The most secure method and requires Public Key Infrastructure (PKI) infrastructure.
Public key encryption (rsa-nonce): Similar to public key signature, but requires prior knowledge of the peer's public key. This method has limited support.
IKE phase 1 verifies the identity of the remote peer, and two peers establish a secure, authenticated channel to communicate. IKE phase 1 also protects the negotiation of phase 2 communication.
IKE phase 1 negotiates the following:
Techniques for protecting phase 1 itself (using crypto and hash algorithms)
Session key generation parameters (using Diffie-Hellman groups)
Authentication methods (using preshared, public key encryption, or digital signature)
Keying material for IKE phase 2
At the end of phase 1 negotiation, a bidirectional ISAKMP/IKE SA (also known as phase 1 SA) is established for IKE communication.
IKE phase 1 has two modes:
Main mode: The default method in most implementations. Main mode defines six message exchanges for establishing phase 1 SA. Figure 15-7 shows IKE phase 1 negotiation in main mode.
Aggressive mode: A method faster than the main mode because it employs three message exchanges to establish phase 1 SA. Aggressive mode is faster but less secure, has fewer negotiation features, and does not provide identity protection. Figure 15-8 shows IKE phase 1 negotiation in aggressive mode.
The information in Figure 15-7 and 15-8 is taken from the general Cisco security presentation on "Cisco IPsec VPN."
IKE phase 2 protects the user data and establishes SA for IPsec.
IKE phase 2 negotiates the following:
Protection suite (using ESP and AH)
Algorithms in the protection suite (using DES, 3DES, AES, SHA)
Networks or IP traffic that is being protected (called proxy identities or phase 2 identities)
At the end of phase 2 negotiations, two unidirectional IPsec SAs (also known as Phase 2 SA) are established for user data—one for sending and another for receiving encrypted data.
IKE phase 2 has one mode—quick mode. Quick mode uses message exchanges to establish the phase 2 IPsec SA. Phase 2 SA is negotiated for given proxy or phase 2 identities and a given IPsec protocol (ESP). Multiple phase 2 SAs can be established under the same phase 1 SA. Figure 15-9 shows IKE phase 2 negotiation in quick mode.
The information in Figure 15-9 is taken from general Cisco security presentation on "Cisco IPsec VPN."
The concept of an SA is that two devices have agreed on certain policy parameters to be used during their communications session. Therefore, SA is an agreement between two entities on a method to communicate securely. As mentioned earlier, each IKE phase has its own SAs; that is, Phase 1 has IKE/ISAKMP SA, and Phase 2 has IPsec SA. Figure 15-10 summarizes the two phases in IKE and the various modes.
IKEv2 is the next version of the Internet Key Exchange protocol and is expected to be the new proposed standard. IKEv2 offers simpler message exchange with fewer complications and less overhead than its predecessor IKEv1. IKEv2 uses cryptographic mechanisms to protect its own packets that are similar to those used to protect the IP payloads in the IPsec stack ESP.
IKEv2 also uses sequence numbers and acknowledgments to provide reliability and state management and mandates few error-processing logistics.
Unlike IKEv1, which was susceptive to DoS attacks that resulted from processing bogus queries, thereby causing expensive cryptographic overhead, IKEv2 provides better attack resiliency because it addresses these issues by validating the requestor.
The following new features are included in IKEv2:
Certs can be referenced through URL + hash to avoid fragmentation.
EAP (MD-5, OTP, GTC) support.
Remote address acquisition, New Config Payload (CP).
Two kinds of SA: IKE_SA (the SA used by IKE itself) and CHILD_SA (the SA used by IPsec).
Four kinds of message pairs: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, INFORMATIONAL.
New CP (Config Payload) payloads.
IKEv2 is documented in RFC 4306, which is coupled with other related RFCs to complete the IPsec framework.
Figure 15-11 shows how IKEv2 works, illustrating the process of the two new SA creations.
Caution
IKEv2 does not provide downgrade protection; hence an attacker can force IKEv1 negotiation. Also note that IKEv2 is not backward compatible with IKEv1. IKEv2 does not interoperate with IKEv1.
Table 15-6 shows a summary comparison of IKEv1 and IKEv2.
| IKEv1 | IKEv2 | |
|---|---|---|
| UDP port | 500 | 500, 4500 |
| Phases | Phase 1 (6/3 messages) Phase 2 (3 messages) | Phase 1 (4 messages) Phase 2 (2 messages) |
| Keepalives | No | Yes |
| Identity Hiding | Yes in main mode, No in aggressive mode | Yes |
| UDP/NAT | No | Yes |
| SA Negotiation | Responder selects initiator's proposal | Same as IKEV1, proposal structure simplified |
| Number of Msgs | 6–9 | 4–8 |
| EAP/CP | No | Yes |
The Internet Security Association and Key Management Protocol (ISAKMP) profile offers configuration modularity for IKE phase 1 negotiations. It allows mapping of ISAKMP parameters to IPsec tunnels. Applications of the ISAKMP profile include MPLS VPN configurations, router certificate management, and IPsec/QoS configurations.
ISAKMP profiles are commonly used when a device has two or more IPsec tunnels requiring different phase 1 parameters for different sites. The ISAKMP profile is also commonly used with Easy VPN Remote configurations and VRF-aware IPsec configurations.
An ISAKMP profile serves as a repository for IKE phase 1 and IKE phase 1.5 configurations for an individual or group of peers. The security parameters are applied to incoming IKE connections, which uniquely identify devices through the concept of "match identity" criteria. ISAKMP profiles allow you the flexibility to match parameters on a per-connection basis on various properties that are presented by incoming connections, such as a VPN client group name, a peer IP address, or a fully qualified domain name (FQDN), rather than just matching on the peer IP address. The ISAKMP profile applies parameters that are specific to each profile, such as trust points, peer identities, XAUTH AAA list, and keepalive.
Figure 15-12 shows the processing flowchart illustrating where the ISAKMP profile takes place in the IPsec tunnel establishment.
The information in Figure 15-12 is taken from the Cisco white paper on "ISAKMP Profile Overview" at http://www.cisco.com/en/US/products/ps6635/products_white_paper0900aecd8034bd59.shtml.
Note
The ISAKMP profile properties are applied as additional parameters to the ISAKMP policy configuration, as shown in Figure 15-12. Later sections of this chapter provide details of the ISAKMP profile parameters and configuration examples.
The IPsec profile functionality was introduced to associate phase 2 SA parameters to a tunnel interface without using the crypto-map command. With the IPsec profile, encryption is performed after the generic routing encapsulation (GRE) is added to the tunnel packet. The tunnel protection ipsec profile command is used to associate an IPsec profile to a tunnel interface. The IPsec profile can be used in both of the following modes: point-to-point GRE (p-pGRE) and multipoint GRE (mGRE).
An IPsec profile can be used in various implementations; common examples include Dynamic Multipoint VPN (DMVPN) and Virtual Tunnel Interface (IPsec VTI) implementations. Configuration examples in this chapter will show how to implement IPsec profiles.
An IPsec profile concept is similar to crypto-map except that it does not require knowing its peer's address before establishing the tunnel. An IPsec profile does not use the set peer and match address commands. The IOS Software will obtain the set peer and match address parameters dynamically from the tunnel parameters and the Next Hop Resolution Protocol (NHRP) cache. For example, when a p-pGRE is used, the tunnel destination address will be used as the IPsec peer address, whereas when mGRE is used, multiple IPsec peers are possible. Hence, the corresponding NHRP mapping NBMA destination addresses will be used for the peer addresses. The profile must be applied on the tunnel interface on both sides of IPsec peers. The IPsec profile is a scalable approach and can be effectively used for varying requirements.
Cisco introduced the concept of using a dedicated IPsec interface called IPsec VTI (Virtual Tunnel Interface) for highly scalable IPsec-based VPNs. IPsec VTI provides a routable interface for terminating IPsec tunnels. VTI also allows the encrypting of multicast traffic with IPsec.
There are two types of IPsec VTI interfaces:
Static VTI (SVTI): This can be used for site-to-site IPsec-based VPNs. SVTI is a point-to-point designated pathway across a shared media that encapsulates traffic with new packet headers and ensures encrypted packet delivery to specific destinations.
Dynamic VTI (DVTI): This can be used for remote-access VPNs. The DVTI technology replaces dynamic crypto maps and the dynamic hub-and-spoke method for establishing tunnels. Dynamic VTI can be deployed for both the server and remote configurations. DVTI tunnels provide an on-demand separate virtual access interface for each VPN connection.
The router processes IPsec VTI interfaces in the same way it processes any other real interface where QoS, firewall, and other security services can be applied after the tunnel is active.
The fundamental architecture of IPsec VTI is based on the GRE tunnel engine but uses IPsec as a tunneling protocol. The tunnel mode ipsec ipv4 command is used to notify the router that this is an IPsec-based interface, rather than GRE followed by applying the IPsec profile to the tunnel interface by using the tunnel protection ipsec command to choose the type of encryption (transform-set) for the interface. Figure 15-14 illustrates the basic configuration components of IPsec VTI with IPsec profile.
One of the important advantages of using IPsec VTI is that it does not require a static mapping of IPsec sessions to a particular physical interface (crypto map not required), thus allowing the flexibility of sending and receiving encrypted traffic on any physical interface. Traffic that needs to be encrypted is identified by virtue of IP routing, when it is forwarded to or from the VTI tunnel interface as shown in Figure 15-13. Dynamic or static IP routes can be used to route the traffic to the encryption engine.
Figure 15-13 illustrates the packet flow for IPsec VTI tunnel.
Note
The information in Figure 15-13 is compiled from Cisco documentation on "IPsec Virtual Tunnel Interface" at http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a008041faef.html#wp1108974.
Unlike the native IPsec configuration where mirrored ACLs with the crypto map are used to identify the traffic for encryption, IPsec VTI simplifies the trigger mechanism by using the IP routing engine. IPsec VTI does not require the use of ACLs with crypto maps.
The IPsec VTI configuration is very similar to GRE over IPsec configuration with a minor variation. Figure 15-14 shows a basic example of IPsec VTI configuration.
|
|