VPN Global Configuration
| Screen Objective | This screen allows the user to configure the VPN Global Configuration. |
| Navigation |
|
| Fields |
|
| Buttons |
|
IPSec involves many component technologies and encryption methods. Yet IPSec's operation can be broken down into five main steps:
- "Interesting traffic" or IPSec Policy Configuration initiates the IPSec process. Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.
- IKE phase 1— IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase 2.
- IKE phase 2— 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.
IKE phase 1 occurs in two modes: main mode and aggressive mode.
When a distributed operational network uses public transport links for the inter-site connectivity, the traffic must be encrypted to ensure its confidentiality and its integrity. Such Virtual VPN connection is executed over an IPSec encrypted link. An IPSec policy determines the ‘interesting traffic’ i.e. the type or subset of the customer traffic to be encrypted.
Internet Security Association and Key Management Protocol (ISAKMP) defines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SA). A SA is a relationship between two or more entities that describes how the entities will utilize security services to communicate securely. In endpoint-to-endpoint Transport Mode, both end points of the IP connection implement IPSec.
Internet Key Exchange (IKE) protocol is a component of IPSec used for performing mutual authentication and establishing and maintaining Security Associations (SAs) (RFC 7296)
Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. Since IKE always negotiates pairs of SAs, the term "SA" is generally used to refer to a pair of SAs (e.g., an "IKE SA" or an "IPSec SA" is in reality a pair of one-way SAs). The first SA, the IKE SA, is used to protect IKE traffic. The second SA provides IPSec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPSec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPSec SA.
- the IKE SA is also referred to as a Phase 1 SA, and
- the IPSec SA is referred to as a Phase 2 SA.
The basic purpose of IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges. IKE phase 1 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 2 parameters
IKE Phase 1 occurs in two modes: main mode and aggressive mode.
To authenticates and protect the identities of the IPSec peer, the encryption algorithms are as follows:
- DES-CBC—Data Encryption Standard (DES) is a symmetric secret-key block algorithm. It has a block size of 64 bits. Use of ESP DES-CBC in the Internet environment is far greater than sending the datagram as clear text but is not a good encryption algorithm for the protection of even moderate value information in the face of such equipment. Triple DES is better choice for such purposes.
- Triple DES (3DES)— this DES variant processes each block three times, each time with a different key which makes it more secure than DES-CBS.
- Advanced Encryption Standard (AES) is a symmetric content encryption algorithm. AES-128 uses 128 bits key-length to encrypt/decrypt a block of message, whereas AES-192 & AES-256 uses 192 & 256 bits key-length to encrypt/decrypt the message.
Diffie and Hellman Key Exchange
Diffie and Hellman (DH) describe a method for two parties to agree upon a shared secret number, called ZZ, in such a way that the secret will be unavailable to eavesdroppers. This method requires that both the sender and recipient of a message have key pairs (private and public). By combining one's private key and the other party's public key, both parties can compute the same shared secret number ZZ.
For example, let’s identify the communicating parties as party A and party B. Prior to their communication, the parties agree between them on a large prime number p, and a generator (or base) g (where 0 < g < p).
Party A chooses a secret integer xa (her private key) and then calculates ya = g ^ xa mod p (which is her public key). Party B chooses a private key xb, and calculates his public key in the same way as yb = g ^ xb mod p.
Both parties then send each other their public keys. Both parties know their public keys but not their private keys because calculating them is a hard mathematical problem (known as the discrete logarithm problem). However, they can calculate:
ZZ = g ^ (xb * xa) mod p = (yb ^ xa) mod p = (ya ^ xb) mod p, where ZZ is their shared secret as defined by X9.42. For more details, refer to RFC 2631 [8].
Any eavesdropper who was listening in on the communication knows p, g, and both parties public keys ya and yb. But the eavesdropper will be unable to calculate the shared secret from these values.
This secret number can then be converted into cryptographic keying material (KM). The KM is typically used as a key-encryption key to encrypt (wrap) a content-encryption key which is in turn used to encrypt the message data (the VPN GRE traffic).This key is kept secret and never exchanged over the insecure channel.
The DH groups are identified by the length of the keys in bits. The larger the key (higher group id) the higher is the security but as well the resources required are higher and the user should consider performance degradation.
The Exchange Modes in which IKE Phase 1 occurs are 2 types: Main and Aggressive.
- Session begins with the initiator sending a proposal to the responder describing what encryption and authentication protocols are supported, the life time of the keys, and if Phase 2 perfect forward secrecy should be implemented. The proposal may contain several offerings. The responder chooses from the offerings and replies to the initiator.
- The next exchange passes Diffie-Hellman public keys and other data. All further negotiation is encrypted within the IKE SA.
- The third exchange authenticates the ISAKMP session. Once the IKE SA is established, IPSec negotiation (Quick Mode) begins.
In Aggressive mode, the negotiation is quicker as the session is completed in only 3 messages. The disadvantage is in that the identity of the peers is not protected.
- The initiator send a request with all required SA information.
- The responder replies with authentication and its ID.
- The initiator authenticates the session in the follow-up message.
The weakness of using the aggressive mode is that both sides have exchanged information before there's a secure channel.
- 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
A negotiated shared IPSec Phase 2 policy includes:
- IPSec Security protocols—when IKE is
not used to establish SAs, a single
transform set must be used. Before a transform set can be included
in a crypto map entry, it must be defined. A transform set specifies
one or two IPSec security protocols (either Encapsulation Security
Protocol (ESP) or Authentication Header (AH). To select a transform
set, consider the following:
- For data confidentiality, include an ESP.
- For data authentication for the outer IP header as well as the data, include an AH.
- For data authentication (either using ESP or AH), choose from the MD5 or SHA (HMAC keyed hash variants) authentication algorithms. The SHA algorithm is generally considered stronger than MD5, but is slower.
- Encryption—AES Counter mode (AES-CTR) are used are also used. AES-CTR use ESP confidentiality mechanism and require the encryptor to generate a unique per-packet value and to communicate this value to the decryptor. AES-CTR must be used in conjunction with an authentication function, such as HMAC-SHA.
- Authentication
- IPSec Mode—options are tunnel ad transport modes
- Perfect Forward Secrecy— Perfect forward secrecy (PFS) means that an encryption system automatically and frequently changes the keys it uses to encrypt and decrypt information, such that if the latest key is compromised, it exposes only a small portion of the user’s sensitive data.
A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. It is an attempt to subvert security by someone who records legitimate communications and repeats them in order to impersonate a valid user, and to disrupt or cause negative impact for legitimate connections.
IPSec provides anti-replay protection against an attacker who duplicates encrypted packets with the assignment of a monotonically increasing sequence number to each encrypted packet. The receiving IPSec endpoint keeps track of which packets it has already processed on the basis of these numbers with the use of a sliding window of all acceptable sequence numbers.
ACK Packets
This section lists off some details of how ACK packets work with theimplementation of IPSec.
- Every 60 seconds the switch sends an ACK packet
- If an ACK is not received, the DPD packet (R_U_THERE) will be retransmitted every 15 seconds for 5 transmissions (75 seconds in total).
- At the end, the endpoint can identify that the other is down in a time between 75 seconds up to 135 seconds.
- When interesting traffic is seen by the switch on either side, the tunnel will try to go up automatically and then will start sending the interesting traffic.
