Understanding IPSec VPN


The Internet Security Association and Key Management Protocol, also called IKE, is the negotiation protocol that lets two hosts agree on how to build an IPSec Security Association. Each ISAKMP negotiation is divided into two sections called Phase1 and Phase2.
Phase 1 creates the first tunnel to protect later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data travelling across the secure connection.

To set the terms of the ISAKMP negotiations, you create an ISAKMP policy. It includes the following:
  • An authentication method, to ensure the identity of the peers.
  • An encryption method, to protect the data and ensure privacy.
  • A Hashed Message Authentication Codes method to ensure the identity of the sender and to ensure that the message has not been modified in transit.
  • A Diffie-Hellman group to set the size of the encryption key.
  • A time limit for how long the security appliance uses an encryption key before replacing it.
Transform set combines an encryption method and an authentication method. During the IPSec security association negotiation with ISAKMP, the peers agree to use a particular transform set to protect a particular data flow. The transform set must be the same for both peers.

A transform set protects the data flows for the access list specified in the associated crypto map entry. You can create transform sets in the security appliance configuration, and then specify a maximum of 11 of them in a crypto map or dynamic crypto map entry.

A tunnel group is a set of records that contain tunnel connection policies. You configure a tunnel group to identify AAA servers, specify connection parameters, and define a default group policy. The security appliance stores tunnel groups internally.



 IPSec's operation can be broken down into five main steps

  • Interesting traffic initiates the IPSec process— Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.
  • IKE phase one— IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase two.
  • IKE phase two— IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.
  • Data transfer— Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database.
  • IPSec tunnel termination— IPSec SAs terminate through deletion or by timing out.




Step 1: Defining Interesting Traffic


The access lists are assigned to a crypto policy such that permit statements indicate that the selected traffic must be encrypted, and deny statements can be used to indicate that the selected traffic must be sent unencrypted.



Step 2: IKE Phase One

The basic purpose of IKE phase one is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges. IKE phase one performs the following functions:


  • Authenticates and protects the identities of the IPSec peers
  • Negotiates a matching IKE SA policy between peers to protect the IKE exchange
  • Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys
  • Sets up a secure tunnel to negotiate IKE phase two parameters


IKE phase one occurs in two modes:

  • Main mode
  • Aggressive mode

Main Mode

Main mode has three two-way exchanges between the initiator and receiver.
  • First exchange—The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer.
  • Second exchange—This exchange uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces, which are random numbers sent to the other party, signed, and returned to prove their identity.
  • Third exchange—This exchange verifies the other side's identity. The identity value is the IPSec peer's IP address in encrypted form




Aggressive Mode

In the aggressive mode, fewer exchanges are done and with fewer packets. In the first exchange, almost everything is squeezed into the proposed IKE SA values, the Diffie-Hellman public key, a nonce that the other party signs, and an identity packet, which can be used to verify the initiator's identity through a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides have exchanged information before there is a secure channel. Therefore, it is possible to sniff the wire and discover who formed the new SA. However, aggressive mode is faster than main mode.




Step 3: IKE Phase Two

The purpose of IKE phase two is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase two performs the following functions:

  • Negotiates IPSec SA parameters protected by an existing IKE SA
  • Establishes IPSec security associations
  • Periodically renegotiates IPSec SAs to ensure security
  • Optionally performs an additional Diffie-Hellman exchange


IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in phase one. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that provide replay protection. The nonces are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs.

Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires. Base quick mode is used to refresh the keying material used to create the shared secret key based on the keying material derived from the Diffie-Hellman exchange in phase one.

Perfect Forward Secrecy

If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman exchange is performed with each quick mode, providing keying material that has greater entropy (key material life) and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use and exacting a performance cost.




Step 4: IPSec Encrypted Tunnel

After IKE phase two is complete and quick mode has established IPSec SAs, information is exchanged by an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA



Step 5: Tunnel Termination

IPSec SAs terminate through deletion or by timing out. An SA can time out when a specified number of seconds have elapsed or when a specified number of bytes have passed through the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are needed for a flow, IKE performs a new phase two and, if necessary, a new phase one negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire so that a given flow can continue uninterrupted


*   *   *   *   *





Additional Information regarding IPSec VPN


Tunnel Mode vs Transport Mode
IPSec VPN can be configured in two different modes, Tunnel mode and Transport mode.

Tunnel Mode encrypts everything beyond layer 3 and above and add it's own layer 3 headers.

Transport Mode encrypts everything beyond layer 4 and above. Thus the source and destination IP addresses are untouched.




Using DPD and Cisco IOS Keepalive Features with Multiple Peers in the Crypto Map
DPD and IOS keepalive features can be used in conjunction with multiple peers in the crypto map to allow for stateless failover. DPD allows the router to detect a dead IKE peer, and when the router detects the dead state, the router deletes the IPsec and IKE SAs to the peer. If you configure multiple peers, the router switches over to the next listed peer for a stateless failover.




Steps during IPSec tunnel formation

1. Negotiate isakmp policies
2. Exchange DH keys
3. Establishes SA for isakmp IKE phase 1
4. Exchanges session keys for encryption (symetric encryption keys)

5. Identity verified through preshare key or certificate

6. Establishes SA for IPSec IKE phase 2
7. Exchanges session keys for encryption of data traffic (symetric encryption keys)





Types of encryption:

SYMMETRIC: each peer uses the same key to encrypt and decrypt the data. (Shared secret). Symmetric encryption algorithm is friendly with processor and causes less overhead on it.

ASYMMETRIC: A peer uses one key to encrypt and another key to decrypt (Public/Private). Asymmetric encryption algorithm is very intense on processors and causes very high overhead on it.





Related Links.
http://www.ciscopress.com/articles/article.asp?p=24833&seqNum=6


Comments

Post a Comment

Popular posts from this blog

Specifying SSH port in Ansible Inventory

There may be some instances where you set a custom port for SSH on your network device. If ssh port for hosts is different than the default port 22, it can be specified in the inventory file with colon (:) after hostname. #vi inventory # Inventory file for Ansible   [XE] ios-xe-mgmt.cisco.com:8181 ios-xe-mgmt-latest.cisco.com:8181   [XR] sbx-iosxr-mgmt.cisco.com:8181
Read more

Ansible-Playbook to display output of multiple show commands (using stdout_lines with Loop)

 In this playbook, we we'll see how we can get display of multiple show commands in stdout_lines format. We can make use of loops (or with_items) for submitting multiple commands, but debug output with stdout_lines does not gives the formatted result as it would give for single command. So in case of multiple commands, we can debug the output of each command separately in stdout_lines format.
Read more

Filtering Routes in BGP using Route-maps and Prefix-list

Image
Order of preference of attributes in BGP The order of preference varies based on whether the attributes are applied for inbound updates or outbound updates. For inbound updates the order of preference is:     route-map     filter-list     prefix-list, distribute-list For outbound updates the order of preference is:     prefix-list, distribute-list     filter-list     route-map NOTE: The attributes prefix-list and distribute-list are mutually exclusive, and only one command (neighbor distribute-list or neighbor prefix-list) can be applied to each inbound or outbound direction for a particular neighbor. Scenario: We own the AS500 and advertising a network block of 192.0.2.0/24 and 180.179.179.0/16 to two different ISPs. Objectives: Configure router R1 to establish eBGP neighbor relationship with ISP1. Configure router R1 to establish eBGP neighbor relationship with ISP2. Advertise  192.0.2.0/24 network to ISP1 only. Advertise 180.179.179.0/16 network to ISP2 only. Receive routes having n
Read more

Ansible Playbook for Network OS Upgrade with pre and post checks

You have 100s of network switches or routers that you need to upgrade. How much time would it take for you to do the upgrades? There are a lot number of sub-tasks involved while upgrading IOS image of a Cisco router or a switch. This time of upgradation can be reduced through automation from various Enterprise Configuration Management tools that also have ability to upgrade network OS. Though these tools give an easy to use graphical interface, but this requires you to have appropriate license and also restricts you to customize your upgrade process.
Read more

Bypassing Proxy Server in Google Chrome

Image
There may be times when you might want to use Google Chrome and do not wish to use the proxy settings for which you are bound to use in Internet Explorer because of your company policies. If you try to change proxy settings in Google Chrome, by default it will open the System Internet Properties dialogue box, and most of the times, change in proxy setting options is restricted by domain group policy. So here is an alternate way to remove or disable proxy settings in Google Chrome. 1. Right click the GoogleChrome.exe and create it's shortcut. 2. Open the properties of the shortcut of GoogleChrome.exe created in previous step. 3. Here you have to edit the Target of this shortcut. You have to add   --proxy-server=""  after the existing path. You are done. Now enjoy the web browsing without any restrictions.
Read more

VMware NSX Traffic Flow — East-West & North-South

Image
Understanding how traffic is flowing in NSX environment is an important aspect to successfully maintain and troubleshoot networks having NSX. In this post we'll understand hop-by-hop flow of traffic in East-West and North-South directions. East-West: VMs on Same Subnet, Same Host VM-1 has IP address 172.16.20.6 and VM-2 has IP address 172.16.20.7 VM-1 vNIC è Logical Switch (Segment ID 5002) è VM-2 vNIC
Read more

Export or Backup Azure Network Security Groups into CSV using PowerShell

There could be many use cases where you may want to export Network Security Groups into CSV. You might have question, how to export or backup Azure Network Security Groups into CSV. Here is the PowerShell script that you can use to export Azure Network Security Groups into CSV using PowerShell script. This script will export Network Security Group along with rules of all Active subscriptions into a CSV.
Read more

Ansible-playbook for backing up running config of Cisco IOS

This ansible-playbook can be used to backup running configuration from Cisco IOS devices. You can refer to my earlier post Getting Started with your first ansible-playbook for Network Automation  to know about the parameters used in this playbook. Inventory file # Inventory file for Ansible [XE] ios-xe-mgmt.cisco.com:8181 ios-xe-mgmt-latest.cisco.com:8181 [XR] sbx-iosxr-mgmt.cisco.com:8181 [all:vars] ansible_network_os=ios Playbook --- - name: Define Parameters   hosts: XE   gather_facts: no   connection: network_cli   tasks:    - name: backup the config      ios_config:       backup: yes      register: backup_config    - name: Store the config to directory      copy:       src: "{{ backup_config.backup_path }}"       dest: "/tmp/backups/{{ inventory_hostname }}" Running the playbook [prashant@Prashant-VM01 ~]$ ansible-playbook play03.yml -i /home/prashant/inventory -u developer -k SSH password: PLAY [Define Parameters] **********************************************
Read more