IPsec Fundamentals

explains IPsec fundamentals and how to configure and verify IPsec.

• IPsec is a framework of open standards for creating highly secure virtual private networks (VPNs).
• IPsec provides security services such as peer authentication, data confidentiality, data integrity and replay detection.

IPSec Security Services

IPSec Packet Headers

IPsec uses two different packet headers to deliver security:

• Authentication Header – The authentication header ensures that the original data packet (before encapsulation) has not been modified during transport on the public network. The authentication header does not support encryption, and is not recommended unless authentication is all that is desired.
• Encapsulating Security Payload (ESP) – ESP ensures that the original payload (before encapsulation) maintains data confidentiality by encrypting the payload and adding a new set of headers during transport across a public network.

IPSec Packet Transport

Traditional IPsec provides two modes of packet transport:

• Tunnel mode – Encrypts the entire original packet and adds a new set of IPsec headers. These new headers are used to route the packet and also provide overlay functions.

• Transport mode – Encrypts and authenticates only the packet payload. This mode does not provide overlay functions and routes based on the original IP headers.

IPSec Encryption, Hashing and Keying

IPsec supports encryption, hashing, and keying methods to provide security services:

• Data Encryption Standard (DES) – A 56-bit symmetric data encryption algorithm that can encrypt the data sent over a VPN. This algorithm is very weak and should be avoided.
• Triple DES (3DES) – A data encryption algorithm that runs the DES algorithm three times with three different 56-bit keys. Using this algorithm is no longer recommended. The more advanced and more efficient AES should be used instead.
• Advanced Encryption Standard (AES) – A symmetric encryption algorithm used for data encryption that was developed to replace DES and 3DES. AES supports key lengths of 128 bits, 192 bits, or 256 bits and is based on the Rijndael algorithm.

IPSec Encryption, Hashing and Keying (Cont.)

• Message Digest 5 (MD5) – A one-way, 128-bit hash algorithm used for data authentication. Cisco devices use MD5 HMAC, which provides an additional level of protection against MitM attacks. Using this algorithm is no longer recommended, and SHA should be used instead.
• Secure Hash Algorithm (SHA) – A one-way, 160-bit hash algorithm used for data authentication. Cisco devices use the SHA-1 HMAC, which provides additional protection against MitM attacks.
• Diffie-Hellman (DH) – An asymmetric key exchange protocol that enables two peers to establish a shared secret key used by encryption algorithms such as AES over an unsecure communications channel.
• RSA signatures – A public-key (digital certificates) cryptographic system used to mutually authenticate the peers.
• Pre-Shared Key – A security mechanism in which a locally configured key is used as a credential to mutually authenticate the peers

Transform Sets

A transform set is a combination of security protocols and algorithms. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

Table 16-4 Allowed Transform Set Combinations

Transform Sets (Cont.)

Transform Sets (Cont.)

Internet Key Exchange

• Internet Key Exchange (IKE) is a protocol that performs authentication between two end- points to establish security associations (SAs), also known as IKE tunnels.
• There are two versions of IKE: IKEv1 (specified in RFC 2409) and IKEv2 (specified in RFC 7296).
• Internet Security Association Key Management Protocol (ISAKMP) is a framework for authentication and key exchange between two peers to establish, modify, and tear down SAs.
• For Cisco platforms, IKE is analogous to ISAKMP, and the two terms are used interchangeably.

Internet Key Exchange (Cont.)

IKEv1 defines two phases of key negotiation for IKE and IPsec SA establishment:

• Phase 1 – Establishes a bidirectional SA between two IKE peers, known as an ISAKMP SA. Because the SA is bidirectional, once it is established, either peer may initiate negotiations for phase 2.
• Phase 2 – Establishes unidirectional IPsec SAs, leveraging the ISAKMP SA established in phase 1 for the negotiation. Phase 1 negotiation can occur using main mode (MM) or aggressive mode (AM). The peer that initiates the SA negotiation process is known as the initiator, and the other peer is known as the responder.

IKE Phase 1 Negotiation Modes

Main mode (MM) consists of six message exchanges and protects information during the negotiation so as not to expose it to eavesdropping. The six MM message exchanges:

• MM1 – First message containing the SA proposals.
• MM2 – Sent from the responder with the matching SA proposal.
• MM3 – Initiator starts the DH key exchange.
• MM4 – Responder sends its own key to the initiator.
• MM5 – Initiator starts authentication by sending peer its IP address.
• MM6 – Responder sends back a similar packet and authenticates the session. At this point, the ISAKMP SA is established.

IKE Phase 1 Negotiation Modes (Cont.)

Aggressive mode (AM) consists of a three-message exchange and takes less time to negotiate keys between peers. However, it doesn’t offer the same level of encryption security provided by MM negotiation, and the identities of the two peers trying to establish a security association are exposed to eavesdropping. These are the three aggressive mode messages:

• AM1 – In this message, the initiator sends all the information contained in MM1 through MM3 and MM5.
• AM2 – This message sends all the same information contained in MM2, MM4, and MM6.
• AM3 – This message sends the authentication that is contained in MM5.

IKE Phase 2 Session Establishment

Phase 2 uses the existing bidirectional IKE SA to securely exchange messages to establish one or more IPsec SAs between the two peers. The method used to establish the IPsec SA is known as quick mode (QM). Quick mode uses a three-message exchange:

• QM1 – The initiator (which could be either peer) can start multiple IPsec SAs in a single exchange message. This message includes agreed-upon algorithms for encryption and integrity decided as part of phase 1, as well as what traffic is to be encrypted or secured.
• QM2 – This message from the responder has matching IPsec parameters.
• QM3 – After this message, there should be two unidirectional IPsec SAs between the two peers.

Perfect Forward Secrecy (PFS) is an additional function for phase 2 that is recommended but is optional because it requires additional DH exchanges that consume additional CPU cycles. The goal of this function is to create greater resistance to crypto attacks and maintain the privacy of the IPsec tunnels by deriving session keys independently of any previous key.

IKEv2

IKEv2 is an evolution of IKEv1 that includes many changes and improvements. In IKEv2, communications consist of request and response pairs called exchanges and are sometimes just called request/response pairs.

1. IKE_SA_INIT negotiates cryptographic algorithms, exchanges nonces, and performs a DH exchange. This single exchange is equivalent to IKEv1’s first two pairs of messages MM1 to MM4.
2. IKE_AUTH authenticates the previous messages and exchanges identities and certificates. Then it establishes an IKE SA and a child SA (the IPsec SA). This is equivalent to IKEv1’s MM5 to MM6 as well as QM1 and QM2.

It takes a total of four messages to bring up the bidirectional IKE SA and the unidirectional IPsec SAs, as opposed to six with IKEv1 aggressive mode or nine with main mode.

Differences Between IKEv1 and IKEv2

Differences Between IKEv1 and IKEv2 (Cont.)

Table 16-5 Major Differences Between IKEv1 and IKEv2

IPsec VPN Solutions

Cisco IPsec VPN Solutions:

• Site-to-Site (LAN-to-LAN) IPsec VPNs – Site-to-site IPsec VPNs are the most versatile solution for site-to-site encryption because they are the only solution to allow for multivendor interoperability. Difficult to manage in large networks.
• Cisco Dynamic Multipoint VPN (DMVPN) – Simplifies configuration for hub-and-spoke and spoke-tospoke VPNs in Cisco networks. It accomplishes this by combining multipoint GRE (mGRE) tunnels, IPsec, and Next Hop Resolution Protocol (NHRP).
• Cisco Group Encrypted Transport VPN (GET VPN) – Developed specifically for enterprises to build any-to-any tunnel-less VPNs (where the original IP header is used) across service provider MPLS networks or private WANs. Provides encryption over private networks which addresses regulatorycompliance guidelines.
• Cisco FlexVPN – FlexVPN is Cisco’s implementation of the IKEv2 standard, featuring a unified VPN solution that combines site-to-site, remote access, hub-and-spoke topologies and partial meshes (spoke-to-spoke direct). Remains compatible with legacy VPN implementations using crypto maps.
• Remote VPN Access – Remote VPN access allows remote users to securely VPN into a corporate network. It is supported on IOS with FlexVPN (IKEv2 only) and on ASA 5500-X and FirePOWER firewalls.

Configuring IPsec VPNs

Even though crypto maps are no longer recommended for tunnels, they are still widely deployed and should be understood. The steps to enable IPsec over GRE using crypto maps are as follows:

• Step 1. Configure a crypto ACL to classify VPN traffic by using these commands: ip access-list extended acl _name permit gre host {tunnel-source IP} host {tunnel-destination IP}

• Step 2. Configure an ISAKMP policy for IKE SA by using the command crypto isakmp policy priority. Within the ISAKMP policy configuration mode, encryption, hash, authentication, and the DH group can be specified with the following commands:
  • encryption {des | 3des | aes | aes 192 | aes 256}
  • hash {sha | sha256 | sha384 | md5}
  • authentication {rsa-sig | rsa-encr | pre-share} group {1 | 2 | 5 | 14 | 15 | 16 | 19 | 20 | 24}

The keyword priority uniquely identifies the IKE policy and assigns a priority to the policy, where 1 is the highest priority.

• Step 3. Configure PSK by using the command crypto isakmp key keystring address peeraddress [mask]. The keystring should match on both peers. For peeraddress [mask], the value 0.0.0.0 0.0.0.0 can be used to allow a match against any peer.
• Step 4. Create a transform set and enter transform set configuration mode by using the command crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]. In transform set configuration mode, enter the command mode [tunnel | transport] to specify tunnel or transport modes.
• Step 5. Configure a crypto map and enter crypto map configuration mode by using the command crypto map map-name seq-num [ipsec-isakmp]. In crypto map configuration mode, use the following commands to specify the crypto ACL to be matched, the IPsec peer, and the transform sets to be negotiated:
  • match address acl-name set peer {hostname | ip-address}
  • set transform-set transform-set-name1 [transform-setname2…transform-set-name6]
• Step 6. Apply a crypto map to the outside interface by using the command crypto map mapname

Configuring IPsec Site-to-Site VPN

Verifying Site-to-Site VPN

Commands that can provide information to verify the operation of a site-to-site VPN include:

• show interface tunnel100 | include Tunnel protocol
• show ip ospf neighbor
• show ip route ospf
• show crypto isakmp sa
• show crypto ipsec sa

Configuring VTI over IPsec Site-to-Site Tunnel

Example 16-9 shows the configuration changes that need to be made to the GRE over IPsec configuration to enable VTI over IPsec. The same commands can be used to verify VTI over IPsec as with the IPsec over GRE tunnel.

• show interface tunnel100 | include Tunnel protocol
• show ip ospf neighbor
• show ip route ospf
• show crypto isakmp sa
• show crypto ipsec sa

Other useful information:

• Full ENCOR Course
• CCNP Enterprise Certificate Information
• 350-401 ENCOR Exam Questions and Solutions
• 350-401 ENCOR Exam Topics