IPsec Overview
===========

It is important to remember that IPsec can protect only the IP layer and up (transport layer and user data). IPsec cannot extend its services to the data link layer. If protection of the data link layer is needed, then some form of link encryption is needed. Such encryption is typically performed within a trusted infrastructure, where the security of the link can be assured. Such encryption is
not feasible in the Internet because intermediate links are not controlled by the end users.

Often, the use of encryption is assumed to be a requirement of IPsec. In reality, encryption, or data confidentiality, is an optional (although heavily implemented) feature of IPsec. IPsec consists of the following features, which are further explained later in this chapter:

■ Data confidentiality
■ Data integrity
■ Data origin authentication
■ Anti-replay

The features, or services, of IPsec are implemented by a series of standards-based protocols. It is important that the implementation of IPsec is based on open standards to ensure interoperability between vendors. The IPsec protocols do not specify any particular authentication, encryption algorithms, key generation techniques, or security association (SA) mechanisms. The three main protocols that are used by IPsec are as follows:

■ Internet Key Exchange (IKE)
■ Encapsulating Security Payload (ESP)
■ Authentication Header (AH)



AH authenticates the entire packet after the Layer 2 header. If ESP authentication is used, the outer IP header is not authenticated. Also note that if ESP performs both encryption and authentication, encryption occurs first, and then the encrypted contents along with the ESP headers are authenticated.

All these features (confidentiality and integrity) will lose its meanings when peer authentication failed.

1. Username and password
2. OTP (one time password)
3. Biometrics
4. Preshared keys
5. Digital Certificates

Internet Key Exchange (IKE)
================

The IKE protocol, as described earlier, is a means of dynamically exchanging IPsec parameters and keys. IKE makes IPsec scalable by automating the key exchange/update process needed to repel password attacks against the IPsec sessions. IKE helps to automatically establish security associations (SAs) between two IPsec endpoints. An SA is an agreement of IPsec parameters between two peers.

IKE actually uses other protocols to perform peer authentication and key generation:

■ ISAKMP—The Internet Security Association and Key Management Protocol defines
procedures on how to establish, negotiate, modify, and delete SAs. All parameter negotiation is handled through ISAKMP, such as header authentication and payload encapsulation (headers and modes were discussed earlier). ISAKMP performs peer authentication, but it does not involve key exchange.
■ Oakley—The Oakley protocol uses the Diffie-Hellman algorithm to manage key exchanges across IPsec SAs. Diffie-Hellman is a cryptographic protocol that permits two end points to exchange a shared secret over an insecure channel.

IKE has two phases of key negotiation: phase 1 and phase 2. Phase 1 negotiates a security association (a key) between two IKE peers. The key negotiated in phase 1 enables IKE peers to communicate securely in phase 2. During phase 2 negotiation, IKE establishes keys (security associations) for other applications, such as IPSec.

Phase 1 negotiation can occur using one of two modes: main mode and aggressive mode. Main mode tries to protect all information during the negotiation, meaning that no information is available to a potential attacker. When main mode is used, the identities of the two sides are hidden. Although this mode of operation is very secure, it is relatively costly in terms of the time it takes to complete the negotiation. Aggressive mode takes less time to negotiate keys between peers; however, it gives up some of the security provided by main mode negotiation. For example, the identities of the two parties trying to establish a security association are exposed to an eavesdropper.

The two modes serve different purposes and have different strengths. Main mode is slower than aggressive mode, but main mode is more secure and more flexible because it can offer an IKE peer more security proposals than aggressive mode. Aggressive mode is less flexible and not as secure, but much faster.

Main mode has six packets exchanged while aggressive mode just has three packets exchanged.

Main mode process
>>>>>>>>>>>>>>>>>

• In main mode, the first two exchanges negotiate the security parameters used to establish the IKE tunnel. The two endpoints exchange proposals in the form of transform sets. The use of transform sets is explained later in this chapter.
• The second pair of packets exchanges the Diffie-Hellman public keys needed to create the secure IKE tunnel. This tunnel is used later for the exchange of keys for the IPsec security associations (SA) (for phase 2).
• The final pair of packets performs peer authentication. Remember that a hash function is used to confirm identity and ensure that no rogue devices are permitted to establish a secure communications channel to your site.

Aggressive mode process
>>>>>>>>>>>>>>>>>

• The first packet goes from the initiator to the receiver. It sends security policy proposals, the Diffie-Hellman public key, a nonce (which is signed and returned for identity validation), and a means to perform authentication.
  
• The second packet goes from the receiver back to the initiator. It contains the accepted security policy proposal, its Diffie-Hellman public key, and the signed nonce for authentication.
  
• The final packet is a confirmation from the initiator to the receiver.
  

In Cisco IOS software, the two modes are not configurable. The default action for IKE authentication (rsa-sig, rsa-encr, or preshared) is to initiate main mode; however, in cases where there is no corresponding information to initiate authentication, and there is a preshared key associated with the host name of the peer, Cisco IOS software can initiate aggressive mode. Cisco IOS software will respond in aggressive mode to an IKE peer that initiates aggressive mode.

Phase 1 IKE policies, that is, IKE transform set consists of the following main attributes: (main and aggressive mode)

■ IKE encryption algorithm (DES, 3DES, or AES)
■ IKE authentication algorithm (MD5 or SHA-1)
■ IKE key (preshare, RSA signatures, nonces)
■ Diffie-Hellman version (1, 2, or 5)
■ IKE tunnel lifetime (time and/or byte count)

Diffie-Hellman will generate a shared-key. The shared secret key, SKEYID, is used in the derivation of three other keys: SKEYID_a, SKEYID_e, and SKEYID_d. Each key has a separate purpose. SKEYID_a is the keying material used during the authentication process. The SKEYID_e key is the keying material used in the encryption process and the SKEY_d key is keying material used to derive keys for non-Internet Security Association and Key Management Protocol (non-ISAKMP) SAs. All four keys are calculated during IKE Phase 1.

Phase 2 IPsec transform set consists of different attributes as follows: (quick mode)

■ IPsec protocol (ESP or AH)
■ IPsec encryption type (DES, 3DES, or AES)
■ IPsec authentication (MD5 or SHA-1)
■ IPsec mode (tunnel or transport)
■ IPsec SA lifetime (seconds or kilobytes)

A security association (SA) is a group of security services (parameters) agreed upon between two IPsec peers. As discussed earlier, these security parameters are exchanged during IKE phase 2 in transform sets. Once each IPsec endpoint agrees upon the common services to use, the IPsec SAs are constructed.

Each IPsec SA is a one-way connection between two IPsec peers. In most cases, effective network communications requires bidirectional traffic flow. Thus, a complete IPsec connection between two endpoints consists of two IPsec SAs—one incoming and one outgoing. Each of these SAs uses the same security parameters agreed upon in the IPsec transform sets. However, each SA is tracked and maintained separately.

Each SA is referenced by a Security Parameter Index (SPI). The SPI travels with each IPsec packet and is used to reference and confirm the security parameters upon arrival at the far end. The use of the SPI eliminates the need to send the security parameters with each IPsec packet.

Each IPsec client uses an SA Database (SAD) to track each of the SAs that the client participates in. Remember that for any remote client, there will be two SAs. The SAD contains the following information about each IPsec connection (SA):

■ Destination IP address
■ SPI number
■ IPsec protocol (ESP or AH)

The inbound SPI will be identical to the outbound SPI on peer router.
The outbound SPI will be identical to the inbound SPI on peer router.

A second database, the Security Policy Database (SPD), contains the security parameters that were agreed upon for each SA (in the transform sets). For each SA, this database contains:

■ Encryption algorithm (DES, 3DES, or AES)
■ Authentication algorithm (MD5 or SHA-1)
■ IPsec mode (tunnel or transport)
■ Key lifetime (seconds or kilobytes)

The use of both the SAD and the SPD allows any IPsec client to quickly track IPsec attributes for any incoming or outgoing packets to any remote client.

After configuration, the tied interface ip address will be used as source ip address of IPsec VPN. Of course, we can use the following command to define source ip address:

Router (config)# crypto map map-name local-address interface-id


Nat-Tranversal

1. NAT-T support detection. Verndor-ID payload is sent.
2. NAT-T existence detection. NAT-D payload is sent.

Source ip and port hashed payload
Destination ip and port hashed payload

If, upon receipt, both ends recalculate the hashes and the hashes match the payload hash, each peer knows that no NAT device exists on the network path between them. If the payload hash and recalculated hashes do not match (that is, someone translated the address or port), then each peer needs to perform NAT traversal to get the IPsec packet through the network.

These two actions happen in IKE phase 1.

In IKE phase 2 (Quick Mode), both ends will decide if NAT-Tranversal will be used.


How these lifetimes work
=================

Assuming that the particular crypto map entry does not have lifetime values configured, when the router requests new security associations it will specify its global lifetime values in the request to the peer; it will use this value as the lifetime of the new security associations. When the router receives a negotiation request from the peer, it will use the smaller of either the lifetime value proposed by the peer or the locally configured lifetime value as the lifetime of the new security associations. (Use smaller one lifetime in both IKE SA and IPsec SA)

The security association (and corresponding keys) will expire according to whichever comes sooner, either after the number of seconds has passed (specified by the seconds keyword) or after the amount of traffic in kilobytes is passed (specified by the kilobytes keyword). Security associations that are established manually (via a crypto map entry marked as ipsec-manual) have an infinite lifetime.

A new security association is negotiated before the lifetime threshold of the existing security association is reached, to ensure that a new security association is ready for use when the old one expires. The new security association is negotiated either 30 seconds before the seconds lifetime expires or when the volume of traffic through the tunnel reaches 256 kilobytes less than the kilobytes lifetime (whichever comes first).

If no traffic has passed through the tunnel during the entire life of the security association, a new security association is not negotiated when the lifetime expires. Instead, a new security association will be negotiated only when IPSec sees another packet that should be protected.

Crypto access list in crypto map entry
==============

If you configure multiple statements for a given crypto access list which is used for IPSec, in general the first permit statement that is matched will be the statement used to determine the scope of the IPSec security association. That is, the IPSec security association will be set up to protect traffic that meets the criteria of the matched statement only. Later, if traffic matches a different permit statement of the crypto access list, a new, separate IPSec security association will be negotiated to protect traffic matching the newly matched access list statement.

crypto map to-lan2 10 ipsec-isakmp
 set peer 192.168.4.1
 set transform-set r1sec
 match address 100

!
!
access-list 100 permit ip host 10.10.1.2 host 10.10.4.1
access-list 100 permit ip 10.10.1.0 0.0.0.255 10.10.4.0 0.0.0.255

Data traffic matches first entry will create a IPsec SA.
Data traffic matches second entry will create a new IPsec SA. (Both use same transform-set specified)

R3#sh crypto engine connections active
Crypto Engine Connections

   ID Interface  Type  Algorithm           Encrypt  Decrypt IP-Address
    9 Se2/0      IPsec 3DES+SHA                  0        4 192.168.4.1
   10 Se2/0      IPsec 3DES+SHA                  4        0 192.168.4.1
========================================================================
   11 Se2/0      IPsec 3DES+SHA                  0        4 192.168.4.1
   12 Se2/0      IPsec 3DES+SHA                  4        0 192.168.4.1
 1002 Se2/0      IKE   MD5+DES                   0        0 192.168.4.1

Any unprotected inbound traffic that matches a permit entry in the crypto access list for a crypto map entry flagged as IPSec will be dropped, because this traffic was expected to be protected by IPSec.

So we need to use Image Crypto Access Lists at Each IPSec Peer as much as possible.

Manual Crypto map entry
===============

crypto map to-lan2 10 ipsec-isakmp
 set peer 192.168.4.1
 set transform-set r1sec new-sec
 match address 100
crypto map to-lan2 20 ipsec-manual
 set peer 192.168.4.1
 set session-key inbound esp 1000 cipher AAFF authenticator AAFF
 set session-key outbound esp 1000 cipher AAFF authenticator AAFF
 set transform-set r1sec
 match address 100

Manual crypto map can only set up single peer, single transform set, and only the first permit entry in access list will be used, the rest will be ignored. Meanwhile, you need to manually define keys used for encapsulation and authentication.

Dynamic Crypto map
================

Dynamic crypto maps are only available for use by IKE.

Dynamic crypto maps are not used by the router to initiate new IPSec security associations with remote peers. Dynamic crypto maps are used when a remote peer tries to initiate an IPSec security association with the router. Dynamic crypto maps are also used in evaluating traffic.

So if outbound traffic matches a permit statement in an access list and the corresponding SA is not yet established, the traffic would simply be dropped (because dynamic crypto maps are not used for initiating new SAs).

How to create dynamic crypto map

crypto dynamic-map mobile 10
 set transform-set r1sec new-sec         -> This is the only required parameter
!
!
!
crypto map to-lan2 10 ipsec-isakmp
 set peer 192.168.4.1
 set transform-set r1sec new-sec
 match address 100
crypto map to-lan2 20 ipsec-manual
 set peer 192.168.4.1
 set session-key inbound esp 1000 cipher AAFF authenticator AAFF
 set session-key outbound esp 1000 cipher AAFF authenticator AAFF
 set transform-set r1sec
 match address 100
crypto map to-lan2 30 ipsec-isakmp dynamic mobile