This blog is going to take you through the steps of a Site-to-Site VPN lifecycle. I am assuming any one reading would already be familiar with the idea of VPN and how to secure a VPN tunnel using IPSEC.
This is going to be a detailed blog which comes from my own notes. The steps and sequence followed comes from the "CCNP ISCW Official Exam Certification Guide". Throughout the article the word VPN is used for Site-to-Site VPN connection.
There are a number of steps involved in creating and terminating a VPN, five to be exact. However these steps require me to further explain the concepts encountered in each. Lets list down the steps by numbers and follow each one by one:
1. Indentify interesting traffic
2. IKE Phase One
3. IKE Phase Two
4. Secure Data Transmission
5. Terminating VPN connection
1. Indentify interesting traffic
Interesting here does not refer to bizzare traffic, but rather any traffic that the IPSec VPN end device (router) should invest its resources in. Which means when we define any traffice interesting only that traffic would be encrypted and sent through a secure channel. All other traffic may still pass through the interface but it would not enjoy the benefit of being called secure.
2. IKE Phase One
IKE Phase One is actually the second step of VPN lifecycle. Internet Key Exchange protocol which is one of the protocols used by IPSec (along with ESP and/or AH) is a way to estabilish some rules by exchange of data, before the actual data can flow through the tunnel. IKE has two modes of operation Main mode and Aggressive Mode. Agressive mode requires a few less steps than main mode. Lets talk about each of them seperatly.
Main ModeWhen we use the main mode in IKE phase one, the initiator first sends a packet to the other peer that contains some security parameters for the creation of an "IKE Tunnel". These security parameters or a proposal is in the form of Transform sets (explained later). Remote peer matches the current transform set with the its own transform sets and replies with the chosen proposal. Next both the peers exchange the Diffie-Hellman keys required to create the IKE Tunnel. This tunnel would later be used in the phase 2 of IKE for secure IPSec security associations. The final interaction is to authenticate the other peer.
Aggressive ModeThis mode reduces the number of packets exchanged. First the initiator sends security proposal, Diffie-Hellman public key, a nonce and means to authenticate. The remote peer replies back with the chosen proposal along with its own Diffie-Hellman key and a signed nonce. The third and final interaction is the initiators reply of confirmation.
IKE Transform Set
IKE peers need to agree upon on a number of parameters. These parameters can be sent individually, however that won't be a good approach. So these parameters are grouped together in what we call a Transform Set. A single unique value can create a different Transform Set. There may be multiple transform sets but both the peers would only agree on one of them. All the values contained in the Transform set must match on both ends else the process stops and no IPsec tunnel is created.
If multiple matching transform sets are found, the first match is used. The sequence is determined by the number assigned to each transform set. It goes from lower to higher, so it is a good practice to always assign smaller numbers to more secure transform sets.
There are 5 parameters that must be co-ordinated:
- IKE Encryption Algorithm(Des, 3Des, Aes)
- IKE authentication Algorithm(MD5 or SHA-1)
- IKE Key (Pre-share, RSA, Nonces)
- Diffie-Hellman version (1,3 or 5)
- IKE Tunnel lifetime (seconds or byte count)
Diffie-Hellman Key Exchange
once the IKE policies have been agree upon key material is exchanged between two ends using DH protocol, which allows us to send secret keys on an insecure channel. Since this key is the basis for the rest of the VPN, its secrecy is highly important. Cisco routers only allow the usage of version 1, 3 and 5, but there are actually 7 groups.
Peer Authentication
The last step in the IKE Phase one is to authenticate the peers. Remeber if the authentication fails IPsec tunnel is not created. There are three ways to do peer authentication.
Pre-shared Keys are configured on each end which must be the same.
RSA Certificates can be used that are signed and verified by a trust Certification Authority.
Nonces is a "nonsense" random number generated by each peer then encrypted and sent to the other end. This is more like One time Password.
3. IKE Phase Two
The first step of IKE (IKE SA) creates a secure channel for IPSec parameters negotiation. Phase two does the following :
- Negotiate IPSec parameters using IPSec transform set
- IPSec SA's (Unidirectional)
- Periodic renegotiation of the IPSec SA's
- An additional Diffie-Hellman exchange (Optional)
Second phase of the IKE process only operates in "quick mode". First the peers agree upon security parameters. Once agreed security associations can be created. These security associations are unidirectional. Quick mode uses nonces to generate new key material and also monitors the expiration of SA's.
IPSec Transform Set
The concept of a transform set remains the same as discussed previously in IKE Transform sets. The only difference is the number and type of parameters. IPSec transform set has five parameters:
- IPSec protocol (ESP or AH)
- IPSec encryption (Des, 3Des, Aes)
- IPSec authentication (MD-5, SHA-1)
- IPSec mode (Tunnel, Transport)
- IPSec SA lifetime (seconds or bytes)
Security Assosciation (SA)
In the IKE Phase 2 the security association are unidirectional which means each end has an incoming and outgoing security association for bidirectional communication. Each SA is tracked by a SPI (Security parameter Index). This way we don't have to send every security parameter with each packet, instead the SPI is sent with the packet. At the other end this SPI is used to reference 2 types of databases maintained by each peer. The first database called an SAD (Security association database) which contains the destination IP address, SPI number and IPSec protocol being used. The second database called SPD (Security policy database) and it contains Encryption algorithm, Authentication algorithm, IPSec mode and Key lifetime.
4. Secure Data Transfer
Once the IPSec SA's have been created all the interesting traffic can through the tunnel securely.
5. Termination
Termination of an IPSec VPN connection is caused by two conditions. Either the lifetime defined expires or an administrator brings down the tunnel manually. In any case the SA is deleted from the SPA and SPD. Parameters may be copied to another SPI in case secure data continues to flow.
This is the lifecycle of a Site-to-Site VPN. I will walk through the steps required to configure it on a cisco router in my next blog.