IPsec (IP security)- a set of protocols for the safe transmission of traffic over an IP network. Perhaps the most complex and extensive protocol stack supported by the VPNKI system.

Includes three main protocols:

• AH (Authentication Header) - integrity management of transmitted data and authentication

• ESP (Encapsulating Security Payload) - data encryption

• ISAKMP (Internet Security Association and Key Management Protocol) - management of connection establishment, mutual authentication of each other's end nodes and exchange of secret keys

Main ports used and protocol numbers

• UDP, port 500 (IKE, key management)
• UDP protocol, port 4500 (IPSEC NAT-Traversal mode)
• ESP protocol value 50 (for IPSEC)
• AH protocol value 51 (for IPSEC)

In general, the IPsec suite of protocols is not easy in terms of its use cases, which are quite multifaceted. However, the basic feature of all interaction on this protocol is the concept of SA (Security Association) - this is a set of parameters about how the parties will further use certain properties of the protocols from the IPsec composition.

It is also worth mentioning about the two main modes of operation of IPsec - tunnel and transport. Roughly speaking, in transport mode, only the payload of an IP packet is encrypted, while in tunnel mode, all data, including IP headers, is encrypted.

Authentication

Communication between two nodes begins with the establishment of an SA. More precisely, from two associations - for the AH and ESP protocol, both in one direction and in the other. SA starts with authentication and then the parties negotiate future session parameters:

• for AH protocol - used authentication algorithm, keys, key lifetime and other parameters,
• for the ESP protocol - encryption and authentication algorithms, keys, initialization parameters, key lifetimes and other parameters.

Here, the parties agree on the tunnel or transport mode of operation of IPsec.

By the end of the process, you should have several SAs installed, but ... a little more detail on how it really is.

Phase 1 and Phase 2

In IPsec, everything happens in Phases.

In phase 1, the establishment of the SA of the first phase occurs. In the first phase, the parties agree on the identification method, encryption algorithm, hashing algorithm and Diffie Hellman group. This phase can be passed by exchanging three unencrypted packets (aggressive mode) or six unencrypted packets - standard mode. If all goes well, a Phase 1 SA called the IKE SA is created and transitioned to the second phase.

In phase 2, the parties agree on the policy and the keys themselves are created. This phase, unlike the first one, is completely encrypted and it begins only if the first phase is successfully completed. Because the traffic in this phase is fully encrypted, it becomes difficult to troubleshoot, but if everything goes well, a Phase 2 SA called the IPSec SA is created. At this point, it can be said that the tunnel has been established.

Data compression

IPsec does not include its own data compression mechanism, however, you can use the IPcomp mechanism that compresses the contents of an IP packet before it is sent to the IPsec process. Some IPsec daemons support enabling this mechanism from the ipsec.conf configuration files (for example, the Strongswan package)

Automatic VPN connection health check

Inside IPsec, there is no standard tool for checking the health of the connection (such as ping), so the operation of the tunnel can be checked by external means.

Disconnecting VPN connection and changing keys

The keys agreed in two phases must work for the time specified by the policy. This means that the parties may have to go through the rekeying procedure, otherwise the negotiated SAs will disintegrate. As stated above, the parties hold the keys through a Phase 1 (IKE) and Phase 2 (IPsec) process. The procedures for changing them are different, as are the timers that are responsible for this. In order not to interrupt communication during the key change process, the parties first agree on the parameters of the new SA and only after this successful procedure destroy the old SA.

In IPsec, at each of the phases, there are several ways to change keys - with or without authentication, but we will not focus much on this. There are simply too many nuances for this procedure, which depend on the software versions and the ratio of timers - for IKE and IPsec.

0 This article provides an overview of the IP Security (IP Security) and related IPSec protocols available in Cisco products and used to create virtual private networks (VPNs). In this article, we will define what IPSEC is and what security protocols and algorithms are at the heart of IPSEC.

Introduction

IP Security is a suite of protocols dealing with encryption, authentication and security during the transport of IP packets; it now has nearly 20 standards proposals and 18 RFCs.

Cisco VPN products use IPSec, the industry standard for providing rich VPN capabilities. IPSec offers a mechanism for secure transmission of data over IP networks, ensuring the confidentiality, integrity, and reliability of data transmitted over unsecured networks such as the Internet. IPSec provides the following VPN capabilities on Cisco networks:

• Data confidentiality... The sender of IPSec data has the ability to encrypt packets before they are sent over the network.
• Data integrity... The recipient of the IPSec data has the ability to authenticate the parties communicating with it (devices or software where the IPSec tunnels start and end) and the IPSec packets sent by those parties to ensure that the data has not been modified in transit.
• Data source authentication... The recipient of the IPSec data has the ability to authenticate the source of the received IPSec packets. This service depends on the data integrity service.
• Playback protection... The recipient of the IPSec data can detect and reject the played packets, preventing them from being tampered with and from mediating attacks.

IPSec is a standards-based set of security protocols and algorithms. IPSec and its associated security protocols conform to open standards supported by the Internet Engineering Task Force (IETF) and described in RFCs and IETF drafts. IPSec operates at the network layer to provide security and authentication for IP packets sent between IPSec devices (parties) such as Cisco routers, PIX Firewalls, Cisco VPN clients and concentrators, and many other products that support IPSec. IPSec support scales from the smallest to very large networks.

Security Association (SA)

IPSec offers a standard way to authenticate and encrypt communications between communicating parties. To secure communications, IPSec uses industry-standard encryption and authentication algorithms (ie, mathematical formulas) called transforms. IPSec uses open standards for encryption key negotiation and connection management to enable interoperability between parties. IPSec technology provides methods for allowing IPSec parties to "negotiate" consistent use of services. Security associations are used in IPSec to specify the parameters to be negotiated.

Defense Association(Security Association - SA) is an agreed policy or method of processing data that is supposed to be exchanged between two devices of communicating parties. One of the components of such a policy may be the algorithm used to encrypt the data. Both parties can use the same algorithm for both encryption and decryption. The valid SA parameters are saved in the Security Association Database (SAD) of both sides.

Two computers on each side of the SA store the mode, protocol, algorithms, and keys used in the SA. Each SA is used in one direction only. Two SAs are required for bidirectional communication. Each SA implements one mode and protocol; thus, if two protocols are to be used for one packet (such as AH and ESP), then two SAs are required.

Internet Key Exchange (IKE) is a hybrid protocol that provides a dedicated service for IPSec, namely, authentication of the IPSec parties, negotiation of IKE and IPSec security association parameters, and key selection for encryption algorithms used within IPSec. IKE relies on the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley, which are used to control the generation and processing of encryption keys used in IPSec transformations. IKE is also used to form security associations between potential IPSec parties.
Both IKE and IPSec use security associations to specify communication parameters.
IKE supports a set of various primitive functions for use in protocols. Among them are the hash function and the pseudo-random function (PRF).

Hash function Is a collision resistant feature. Collision resistance is understood as the fact that it is impossible to find two different messages m1 and m2 such that

H (m1) = H (m2), where H is a hash function.

As for the pseudorandom functions, at present, instead of special PRFs, a hash function is used in the HMAC construction (HMAC is a message authentication mechanism using hash functions). To determine the HMAC, we need a cryptographic hash function (denote it as H) and a secret key K. We assume that H is a hash function where data is hashed using a compression procedure applied sequentially to a sequence of blocks of data. We will denote by B the length of such blocks in bytes, and the length of the blocks obtained as a result of hashing as L (L
ipad = byte 0x36, repeated B times;
opad = byte 0x5C repeated B times.

To calculate the HMAC from the "text" data, you need to perform the following operation:

H (K XOR opad, H (K XOR ipad, text))

It follows from the description that IKE uses HASH values ​​to authenticate the parties. Note that HASH in this case means exclusively the Payload name in ISAKMP, and this name has nothing to do with its content.

IPSec infrastructure

IPSec VPNs can be built with a wide variety of Cisco devices — Cisco routers, CiscoSecure PIX Firewalls, CiscoSecure VPN client software, and Cisco 3000 and 5000 Series VPN Concentrators. Cisco routers have built-in VPN support with corresponding Cisco software rich capabilities IOS, which reduces the complexity of network solutions and reduces the overall cost of VPN while building multi-layered protection of the services provided. PIX Firewall is a high-performance network device that can serve tunnel endpoints with high bandwidth and excellent firewall functionality. The CiscoSecure VPN client software supports the most stringent remote access VPN requirements for e-commerce and mobile access applications by offering complete IPSec standards and reliable interoperability between Cisco routers and PIX Firewalls.

How IPSec works

IPSec relies on a number of technology solutions and encryption techniques, but the general action of IPSec can be summarized as the following main steps:

• Step 1. Start the IPSec process. Traffic that requires encryption according to the IPSec security policy negotiated by the IPSec parties starts the IKE process.
• Step 2. Phase I of IKE... The IKE process authenticates the IPSec parties and negotiates the parameters of the IKE security associations, which creates a secure channel for negotiating the parameters of the IPSec security associations during the second phase of IKE.
• Step 3. Second phase of IKE... The IKE process negotiates the IPSec security association parameters and establishes the appropriate IPSec security associations for the communicating party devices.
• Step 4. Data transfer... The exchange of data between the IPSec communicating parties is based on the IPSec parameters and keys stored in the security association database.
• Step 5. Shutting Down the IPSec Tunnel... IPSec security associations are terminated either by being removed or by exceeding their lifetime.

The following sections will describe these steps in more detail.

(The Internet Key Exchange (IKE)) - Key exchange.

RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) - Zero encryption algorithm and its use.

RFC 2411 (IP Security Document Roadmap) - Further development of the standard.

RFC 2412 (The OAKLEY Key Determination Protocol) - Key compliance checking.

IPsec architecture

IPsec, unlike other well-known SSL and TLS protocols, operates at the network layer (layer 3 of the OSI model). This makes IPsec more flexible so that it can be used to secure any TCP and UDP based protocol. IPsec can be used to provide security between two IP hosts, between two Security Gateways, or between an IP host and a Security Gateway. The protocol is an "add-on" to the IP protocol, and processes the generated IP packets in the manner described below. IPsec can ensure the integrity and / or confidentiality of data transmitted over the network.

IPsec uses the following protocols to perform various functions:

• Authentication Header (AH) provides the integrity of the virtual connection (transmitted data), authentication of the source of information and an additional function to prevent packet retransmission
• Encapsulating Security Payload (ESP) can provide confidentiality (encryption) of transmitted information, limiting the flow of confidential traffic. In addition, it can provide the integrity of the virtual connection (transmitted data), authentication of the information source and the additional function of preventing retransmission of packets (Whenever ESP is used, it is mandatory to use one or another set of security services)
• The Security Association (SA) provide a bunch of algorithms and data that provide the parameters required for AH and / or ESP to work. The Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for authentication and key exchange, key authentication.

Security Association

The concept of "Secure Virtual Connection" (SA, "Security Association") is fundamental to the IPsec architecture. SA is a simplex connection that is formed to carry the corresponding traffic over it. When implementing security services, an SA is formed based on the use of the AH or ESP protocols (or both at the same time). SA is defined according to the point-to-point concept and can operate in two modes: transport mode (PTP) and tunneling mode (RTU). Transport mode is implemented with SA between two IP nodes. In tunneling mode, the SA forms an IP tunnel.

All SAs are stored in the SADB (Security Associations Database) of the IPsec module. Each SA has a unique marker consisting of three elements:

• Security Parameter Index (SPI)
• Destination IP addresses
• security protocol identifier (ESP or AH)

The IPsec module, given these three parameters, can look up the SADB entry for a specific SA. The list of SA components includes:

Serial number 32-bit value that is used to form the field Sequence Number in the headings AH and ESP. Sequence Number Counter Overflow A flag that signals the overflow of the serial number counter. Replay Attack Suppression Window Used to define retransmission of packets. If the value in the field Sequence Number does not fall within the specified range, then the packet is destroyed. Information AH used authentication algorithm, required keys, key lifetime, and other parameters. ESP information encryption and authentication algorithms, required keys, initialization parameters (for example, IV), key lifetimes and other parameters IPsec mode of operation tunnel or transport MTU The maximum packet size that can be transmitted over a VC without fragmentation.

Since secure virtual connections (SAs) are simplex, at least two SAs are required to establish a duplex link. In addition, each protocol (ESP / AH) must have its own SA for each direction, that is, the AH + ESP bundle requires four SAs. All this data is located in SADB.

• AH: Authentication Algorithm.
• AH: secret key for authentication
• ESP: encryption algorithm.
• ESP: secret encryption key.
• ESP: use authentication (yes / no).
• Key exchange options
• Routing restrictions
• IP filtering policy

In addition to the SADB database, IPsec implementations support the Security Policy Database (SPD). An SPD entry consists of a set of IP header field values ​​and Upper Layer Protocol header fields. These fields are called selectors. Selectors are used to filter outgoing packets in order to match each packet with a specific SA. When a packet is formed, the values ​​of the corresponding fields in the packet (selector fields) are compared with those contained in the SPD. The corresponding SAs are found. The SA, if any, is then determined for the package and its associated Security Parameters Index (SPI). Then IPsec operations (AH or ESP protocol operations) are performed.

Examples of selectors that are contained in the SPD:

• Destination IP address
• Sender IP address
• IPsec protocol (AH, ESP, or AH + ESP)
• Sender and Receiver ports

Authentication Header

Authentication Header format

Offsets	Octet 16	0								1								2								3
Octet 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Next Header								Payload Len								Reserved
4	32
8	64	Sequence Number
C	96	Integrity Check Value (ICV) …
…	…

Next Header(8 bits) Type of protocol header following the AH header. Using this field, the receiving IP-sec module learns about the protected upper-level protocol. The values ​​of this field for different protocols can be found in RFC 1700. Payload Len(8 bits) This field specifies the total size of the AH header in 32-bit words, minus 2. However, when using IPv6, the header length must be a multiple of 8 bytes. Reserved(16 bits) Reserved. Filled with zeros. Security Parameters Index(32 bits) Index of security parameters. The value of this field, together with the destination IP address and security protocol (AH protocol), uniquely identifies the secured virtual connection (SA) for this packet. SPI value range 1 ... 255 is reserved by IANA. Sequence Number(32 bits) Sequential number. Serves to protect against retransmission. The field contains a monotonically increasing parameter value. Although the recipient can opt out of the packet retransmission protection service, it is mandatory and is always present in the AH header. The sending IPsec module always uses this field, but the receiver may not process it. Integrity Check Value

The AH protocol is used for authentication, that is, to confirm that we are communicating with exactly who we think we are and that the data we receive is not corrupted in transit.

Outbound IP Packet Processing

If the sending IPsec module determines that the packet is associated with an SA that assumes AH processing, then it starts processing. Depending on the mode (transport or tunneling mode), it inserts the AH header into the IP packet differently. In transport mode, the AH header is placed after the IP header and before the upper layer protocol headers (Typically TCP or UDP). In tunneling mode, the entire original IP packet is framed first by the AH header, then by the IP header. This header is called external, and the header of the original IP packet is called internal. After that, the transmitting IPsec module must generate a sequential number and write it down in the field Sequence Number... When SA is established, the sequence number is set to 0, and is incremented by one before each IPsec packet is sent. In addition, there is a check to see if the counter has looped. If it reaches its maximum value, it is reset to 0. If the anti-retransmission service is used, when the counter reaches its maximum value, the sending IPsec module resets the SA. Thus, protection against repeated packet transmission is ensured - the receiving IPsec module will check the field Sequence Number, and ignore retry packets. Next, the ICV checksum is calculated. It should be noted that here the checksum is calculated using a secret key, without which an attacker will be able to re-calculate the hash, but without knowing the key, he will not be able to form the correct checksum. The specific algorithms used to compute the ICV can be found in RFC 4305. Currently, the algorithms HMAC-SHA1-96 or AES-XCBC-MAC-96 can be used, for example. The AN protocol calculates the checksum (ICV) for the following fields in the IPsec packet:

• IP header fields that have not been modified during the broadcast, or are identified as the most important
• AH-header (Fields: "Next Header", "Payload Len," Reserved "," SPI "," Sequence Number "," Integrity Check Value ". The" Integrity Check Value "field is set to 0 when calculating ICV
• upper layer protocol data

If the field can change during transport, then its value is set to 0 before calculating the ICV. Exceptions are fields that can change, but the value of which can be predicted upon receipt. When calculating ICV, they are not filled with zeros. An example of a modifiable field would be the checksum field, an example of a modifiable but predefined field could be the recipient's IP address. A more detailed description of which fields are taken into account when calculating the ICV can be found in the RFC 2402 standard.

Processing of incoming IP packets

After receiving a packet containing an AH message, the receiving IPsec module searches for a corresponding Security Associations Database (SADB) secure virtual connection (SA) using the destination IP address, Security Protocol (AH), and SPI. If no matching SA is found, the packet is discarded. A found secure virtual connection (SA) indicates whether the packet retransmission prevention service is being used, i. E. on the need to check the field Sequence Number... If the service is used, then the field is checked. For this, the sliding window method is used. The IPsec receiving module forms a window of width W. The left edge of the window corresponds to the minimum sequential number ( Sequence Number) N correctly received packet. Package with a field Sequence Number, which contains a value starting from N + 1 and ending with N + W, is accepted correctly. If the received packet is on the left border of the window, it is destroyed. The IPsec receiving module then calculates the ICV from the corresponding fields of the received packet using the authentication algorithm it learns from the SA record and compares the result with the ICV value located in the "Integrity Check Value" field. If the calculated ICV value coincides with the received one, then the incoming packet is considered valid and is accepted for further IP processing. If the check is negative, then the receive packet is discarded.

Encapsulating Security Payload format

Offsets	Octet 16	0								1								2								3
Octet 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Security Parameters Index (SPI)
4	32	Sequence Number
8	64	Payload data
…	…
…	…
…	…									Padding (0-255 octets)
…	…																	Pad Length								Next Header
…	…	Integrity Check Value (ICV) …
…	…

Security Parameters Index(32 bits) Index of security parameters. The value of this field, together with the destination IP address and security protocol (AH protocol), uniquely identifies the secured virtual connection (SA) for this packet. SPI value range 1 ... 255 is reserved by IANA for future use. Sequence Number(32 bits) Sequential number. Serves to protect against retransmission. The field contains a monotonically increasing parameter value. Although the recipient may refuse the packet retransmission protection service, it is always present in the AH header. The sender (the sending IPsec module) MUST always use this field, but the receiver may not need to process it. Payload data(variable) This field contains data according to the "Next Header" field. This field is required and consists of an integer number of bytes. If the algorithm used to encrypt this field requires data for synchronizing cryptoprocesses (for example, the "Initialization Vector"), then this field can contain this data explicitly. Padding(0-255 octets) Addition. It is necessary, for example, for algorithms that require the plaintext to be a multiple of a certain number of bytes), for example, the block size for a block cipher. Pad Length(8 bits) Padding size (in bytes). Next Header(8 bits) This field defines the type of data contained in the "Payload data" field. Integrity Check Value Check sum. Must be a multiple of 8 bytes for IPv6, and 4 bytes for IPv4.

Output IPsec Packet Processing

If the sending IPsec module determines that the packet is associated with an SA that expects ESP processing, then it starts processing. Depending on the mode (transport or tunneling mode), the original IP packet is processed differently. In transport mode, the sending IPsec module performs the upper layer protocol framing (encapsulation) procedure (for example, TCP or UDP) using the ESP header and the ESP trailer, without affecting the header of the original IP packet. In tunneling mode, the IP packet is framed by an ESP header and an ESP trailer, and then framed by an external IP header. Next, encryption is performed - in transport mode, only the protocol message above the underlying layer is encrypted (that is, everything that was after the IP header in the original packet), in tunneling mode, the entire original IP packet is encrypted. The sending IPsec module determines the encryption algorithm and secret key from the SA record. The IPsec standards allow the use of triple-DES, AES, and Blowfish encryption algorithms. Since the size of the plaintext must be a multiple of a certain number of bytes, for example, the block size for block algorithms, the necessary addition of the encrypted message is also performed before encryption. The encrypted message is placed in the field Payload Data... In field Pad Length fits the length of the padding. Then, as in AH, it computes Sequence Number... Then the checksum (ICV) is calculated. The checksum, in contrast to the AH protocol, where some fields of the IP header are also taken into account when calculating it, in ESP is calculated only by the fields of the ESP packet minus the ICV field. Before calculating the checksum, it is filled with zeros. The algorithm for calculating ICV, as in the AH protocol, the sending IPsec module learns from the record about the SA with which the packet being processed is associated.

Processing of incoming IPsec packets

After receiving a packet containing an ESP message, the receiving IPsec module looks for the corresponding secure virtual connection (SA) in the Security Associations Database (SADB) using the destination IP address, security protocol (ESP) and SPI index. If no matching SA is found, the packet is discarded. A found secure virtual connection (SA) indicates whether the packet retransmission prevention service is being used, i. E. the need to check the Sequence Number field. If the service is used, then the field is checked. For this, as well as in AH, the sliding window method is used. The receiving IPsec module forms a window of width W. The left edge of the window corresponds to the minimum Sequence Number N of a correctly received packet. A packet with a Sequence Number field containing a value ranging from N + 1 to N + W is accepted correctly. If the received packet is on the left border of the window, it is destroyed. Then, if the authentication service is used, the IPsec receiving module calculates the ICV from the corresponding fields of the received packet using the authentication algorithm it learns from the SA record and compares the result with the ICV value located in the Integrity Check Value field. If the calculated ICV value coincides with the received one, then the incoming packet is considered valid. If the check is negative, then the receive packet is discarded. Next, the packet is decrypted. The IPsec receiver learns from the SA record which encryption algorithm and secret key is used. It should be noted that the checksum check and decryption procedure can be carried out not only sequentially, but also in parallel. In the latter case, the checksum verification procedure should end before the decryption procedure, and if the ICV verification fails, the decryption procedure should also stop. This allows for faster detection of bad packets, which in turn improves protection against denial of service (DOS) attacks. Further, the decrypted message in accordance with the field Next Header forwarded for further processing.

Usage

IPsec is used primarily for VPN tunnels. In this case, the ESP and AH protocols operate in tunneling mode. In addition, by customizing security policies in a specific way, the protocol can be used to create a firewall. The point of a firewall is that it controls and filters packets passing through it in accordance with specified rules. A set of rules is established, and the screen looks at all packets passing through it. If the transmitted packets are subject to these rules, the firewall processes them accordingly. For example, it can reject certain packets, thereby terminating insecure connections. By adjusting the security policy accordingly, you can, for example, deny Internet traffic. To do this, it is enough to prohibit the sending of packets in which messages of the HTTP and HTTPS protocols are embedded. IPsec can also be used to protect servers by dropping all packets except those needed to properly perform server functions. For example, for a Web server, you can block all traffic except for connections over TCP port 80, or over TCP port 443 in cases where HTTPS is used.

see also

Links

• IPSec Configuration Description (cisco.com)

Virtual Private Networks (VPN)
Software	Chaply Check Point VPN-1 Cisco Systems VPN Client CloudVPN CryptoLink Gbridge Hamachi Jabpunch Microsoft Forefront Unified Access Gateway n2n NetworkManager OpenVPN Openswan pLan OpenVPN Edition (ZeroGC Gaming Client) rp-pppoe Social VPN strongSwan Tinc tcpcrypt Vyatta Wippien
Mechanisms
Supplier managed

Security mechanisms in

IPsec is not a single protocol, but a system of protocols designed to protect data at the network layer of IP networks. This article will describe the theory of using IPsec to create a VPN tunnel.

Introduction

VPN based on IPsec technology can be divided into two parts:

• Internet Key Exchange Protocol (IKE)
• IPsec protocols (AH / ESP / both)

The first part (IKE) is the negotiation phase, during which the two VPN peers decide which methods will be used to protect the IP traffic sent between them. In addition to this, IKE is also used for connection management by introducing the concept of Security Associations (SA) for each connection. SAs are directed only one way, so a typical IPsec connection uses two SAs.

The second part is the IP data that needs to be encrypted and authenticated before being transmitted by the methods agreed in the first part (IKE). There are different IPsec protocols that can be used: AH, ESP, or both.

The sequence of establishing a VPN over IPsec can be summarized as:

• IKE Negotiates IKE Layer Security
• IKE Negotiates IPsec Layer Security
• protected data is transmitted via VPN IPsec

IKE, Internet Key Exchange

To encrypt and authenticate data, you need to select the encryption / authentication method (algorithm) and the keys used in them. The task of the Internet Key Exchange protocol, IKE, in this case boils down to distributing these "session keys" and agreeing on algorithms that will protect data between VPN points.

The main tasks of IKE:

• Authenticating each other's VPN points
• Organization of new IPsec connections (through the creation of SA pairs)
• Management of current connections

IKE keeps track of connections by assigning a Security Associations, SA to each one. SA describes the parameters of a specific connection, including IPsec protocol (AH / ESP or both), session keys used to encrypt / decrypt and / or authenticate data. SA is unidirectional, so multiple SAs are used per connection. In most cases, when only ESP or AH is used, only two SAs are created for each of the connections, one for inbound traffic and one for outbound traffic. When ESP and AH are used together, four SAs are required.

The IKE negotiation process goes through several stages (phases). These phases include:

1. IKE Phase-1:
   - Negotiating the protection of the IKE itself (ISAKMP tunnel)
2. IKE Phase 2 (IKE Phase-2):
   - IPsec protection negotiated
   - Receiving data from the first phase to generate session keys

IKE and IPsec connections are limited in duration (in seconds) and in the amount of data transferred (in kilobytes). This is done to improve security.
The duration of an IPsec connection is generally shorter than IKE. Therefore, when the IPsec connection expires, a new IPsec connection is re-created through the second phase of the negotiation. The first phase of negotiation is only used when re-establishing an IKE connection.

For IKE negotiation, the IKE Proposal is introduced, which is a proposal for how to secure data. A VPN point initiating an IPsec connection sends a list (offer) that specifies different methods for securing the connection.
Negotiations can be conducted both on the establishment of a new IPsec connection, and on the establishment of a new IKE connection. In the case of IPsec, the protected data is the traffic sent through the VPN tunnel, and in the case of IKE, the protected data is the data of the IKE negotiations themselves.
The VPN point that received the list (offer) selects the most suitable one from it and indicates it in the response. If none of the offers can be selected, the VPN gateway will refuse.
The offer contains all the necessary information for choosing an encryption and authentication algorithm, etc.

Phase I IKE - IKE Security Negotiation (ISAKMP Tunnel)
In the first phase of negotiation, VPNs authenticate each other based on a Pre-Shared Key. The hash algorithm is used for authentication: MD5, SHA-1, SHA-2.
However, before authenticating each other, so as not to transmit information in clear text, VPN peers perform the exchange of Proposals, described earlier. Only after an offer that suits both VPN points is selected, the VPN point of each other is authenticated.
Authentication can be done in different ways: through Pre-Shared Keys, certificates or. Shared keys are the most common authentication method.
Phase I IKE negotiation can occur in one of two modes: main and aggressive. The main mode is longer, but also more secure. Six messages are exchanged in its process. Aggressive mode is faster, limited to three messages.
The main work of the first phase of IKE lies in Diffie-Hellman key exchange. It is based on public key encryption, each side encrypts the authentication parameter (Pre-Shared Key) with the public key of the neighbor, which, having received this message, decrypts it with its private key. Another way to authenticate parties to each other is by using certificates.

Phase II IKE - IPsec Security Negotiation
In the second phase, the choice of how to protect the IPsec connection is made.
The second phase uses the keying material extracted from the Diffie-Hellman key exchange that took place in the first phase. Based on this material, session keys are created, which are used to protect data in the VPN tunnel.

If the mechanism is used Perfect Forwarding Secrecy (PFS) then a new Diffie-Hellman key exchange will be used for each second phase negotiation. Slightly reducing the speed of work, this procedure ensures that the session keys are independent of each other, which increases protection, because even if one of the keys is compromised, it cannot be used to brute force the rest.

There is only one mode of operation of the second phase of the IKE negotiation, it is called quick mode. During the negotiation of the second phase, three messages are exchanged.

At the end of the second phase, a VPN connection is established.

IKE parameters.
During connection establishment, several parameters are used, without negotiation of which it is impossible to establish a VPN connection.

• Endpoint identification
  How nodes authenticate each other. The most commonly used is a shared key. Shared key based authentication uses the Diffie-Hellman algorithm.
• Local and remote network / host
  Specifies the traffic that will be sent through the VPN tunnel.
• Tunnel or transport mode.
  IPsec can operate in two modes: tunnel and transport. The choice of the mode depends on the protected objects.
  Tunnel mode it is used for protection between remote objects, i.e. The IP packet is completely encapsulated in a new one and only the connection between the two VPN points will be visible to an outside observer. The real source and destination IP addresses will only be visible after the packet is decapsulated when it is received at the VPN receiving point. Therefore, tunnel mode is most commonly used for VPN connections.
  Transport mode protects the IP packet data (TCP, UDP, and upper layer protocols), and the original IP packet header itself will be preserved. Thus, the observer will see the original source and destination, but not the transmitted data. This mode is most often used when securing a local network connection between hosts.
• Remote gateway
  The VPN point is the recipient of the secure connection, which will decrypt / authenticate data from the other side and send it to its final destination.
• IKE operating mode
  IKE negotiation can work in two modes: basic and aggressive.
  The difference between the two is that in aggressive mode, fewer packets are used, which allows for faster connection establishment. On the other hand, the aggressive mode does not transmit some negotiation parameters, such as Diffie-Hellman groups and PFS, which requires them to be preliminarily configured identically on the connection points.
• IPsec protocols
  There are two IPsec protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP), which perform encryption and authentication functions.
  ESP allows you to encrypt, authenticate individually or simultaneously.
  AH only allows authentication. The difference with ESP authentication is that AH authenticates the external IP header as well, allowing you to confirm that the packet really came from the source indicated in it.
• IKE encryption
  Specifies the IKE encryption algorithm to use and its keys. Various symmetric encryption algorithms are supported, for example: DES, 3DES, AES.
• IKE authentication
  The authentication algorithm used in the IKE negotiation. Can be: SHA, MD5.
• IKE Diffie-Hellman (DH) groups
  The DF group used for IKE key exchange. The larger the group, the larger the size of the exchange keys.
• IKE connection lifetime
  It is indicated both by time (seconds) and by the size of the transferred data (kilobytes). As soon as one of the counters reaches the threshold value, a new first phase is started. If no data has been transferred since the IKE connection was created, no new connections will be created until one of the parties wants to create a VPN connection.
• PFS
  With PFS disabled, the key generation material will be retrieved in the first phase of the IKE negotiation at the time of the key exchange. In the second phase of the IKE negotiation, session keys will be generated based on the received material. With PFS enabled, when creating new session keys, the material for them will be used every time a new one. Thus, if the key is compromised, it is not possible to create new keys based on it.
  PFS can be used in two modes: the first PFS on keys will trigger a new key exchange in the first phase of IKE every time a negotiation is started
  second phase. The second mode, PFS on identities, will remove the first phase SAs every time after the second phase negotiate, thereby ensuring that no second phase negotiation is encrypted with the same key as the previous one.
• IPsec DH groups
  DF group data are similar to those used in IKE, only they are used for PFS.
• IPsec encryption
  The algorithm used to encrypt data. Used when using ESP in encryption mode. Algorithm example: DES, 3DES, AES.
• IPsec authentication
  The algorithm used to authenticate the transmitted data. Used in case of AH or ESP in authentication mode. Algorithm example: SHA, MD5.
• IPsec Lifetime
  The VPN connection lifetime is indicated both by time (seconds) and by the size of the transferred data (kilobytes). The counter that is the first to reach the limit will start the regeneration of session keys. If no data has been transferred since the IKE connection was created, no new connections will be created until one of the parties wants to create a VPN connection.

IKE Authentication Methods

• Manual mode
  The simplest of the methods, in which IKE is not used, and authentication and encryption keys, as well as some other parameters, are set manually on both VPN connection points.
• Pre-Shared Keys (PSK)
  Pre-entered shared key on both VPN connection points. The difference from the previous method is that it uses IKE, which allows endpoints to be authenticated and uses changing session keys instead of fixed encryption keys.
• Certificates
  Each VPN point uses: its own private key, its own public key, its own certificate including its own public key and signed by a trusted certification authority. Unlike the previous method, it avoids entering a single shared key at all points of the VPN connection, replacing it with personal certificates signed by a trusted authority.

IPsec protocols

IPsec protocols are used to protect the transmitted data. The choice of the protocol and its keys occurs during the IKE negotiation.

AH (Authentication Header)

AH provides the ability to authenticate the transmitted data. For this, a cryptographic hash function is used in relation to the data contained in the IP packet. The output of this function (hash) is sent along with the packet and allows the remote VPN point to validate the integrity of the original IP packet, confirming that it has not been modified along the way. In addition to the IP packet data, AH also authenticates part of its header.

In transport mode, AH embeds its header after the original IP packet.
In tunnel mode, AH inlines its header after the outer (new) IP header and before the inner (original) IP header.

ESP (Encapsulating Security Payload)

ESP is used for encryption, for authentication, or both with respect to an IP packet.

In ESP transport mode, the protocol inserts its header after the original IP header.
In ESP tunnel mode, the header is after the outer (new) IP header and before the inner (original).

The two main differences between ESP and AH are:

• ESP, in addition to authentication, also provides encryption (AH does not provide this)
• ESP in tunnel mode only authenticates the original IP header (AH also authenticates the external one).

Working behind NAT (NAT Traversal)
A separate specification has been implemented to support work behind NAT. If the VPN endpoint supports this specification, IPsec supports NAT, however there are certain requirements.
NAT support has two parts:

• At the IKE level, end devices communicate with each other about support, NAT Traversal, and the version of the supported specification.
• At the ESP layer, the generated packet is encapsulated in UDP.

NAT Traversal is only used if both endpoints support it.
Definition of NAT: Both VPN peers send hashes of their IP addresses along with the UDP port of the source of the IKE negotiation. This information is used by the recipient to determine if the source IP address and / or port has changed. If these parameters have not been changed, then the traffic does not pass through NAT and the NAT Traversal mechanism is not needed. If the address or port has been changed, then there is NAT between the devices.

Once the endpoints determine that NAT Traversal is needed, the IKE negotiation moves from UDP port 500 to port 4500. This is done because some devices incorrectly handle an IKE session on port 500 when using NAT.
Another problem arises because the ESP protocol is a transport layer protocol and sits directly on top of IP. Because of this, the concepts of TCP / UDP port are not applicable to it, which makes it impossible for more than one client to connect to the same gateway through NAT. To solve this problem, the ESP is packed into a UDP datagram and sent to port 4500, the same port that IKE uses when NAT Traversal is enabled.
NAT Traversal is built into the protocols that support it and works out of the box.

We have already discussed the concept of IPSec, in this article we will take a closer look at IPSec.

So the name IPSec comes from IP Security.
IPSec is a collection of protocols and algorithms that are used to protect IP packets at the Layer3 level.

IPSec allows you to guarantee:
- Confidentiality - using encryption
- Data integrity - via Hashing and HMAC \
- Authentication - through the use of Digital Signatures or Pre-shared key (PSK).

Let's list the main IPsec protocols:
■ ESP and AH: The two main protocols used in IPsec.
Encapsulating Security Payload (ESP), can do whatever is required for IPsec, and
Authentication Header (AH), can do everything except encryption, encryption of the data - that's why ESP is most often used.
■ Encryption algorithms for confidentiality: DES, 3DES, AES.
■Hashing algorithms for integrity: MD5, SHA.
■ Authentication algorithms: Pre-shared keys (PSK), RSA digital signatures.
■ Key management: An example would be Diffie-Hellman (DH), which can be used to
dynamically generate symmetrical keys to be used by symmetrical algorithms; PKI,
which supports the function of digital certificates issued by trusted CAs; and Internet
Key Exchange (IKE), which does a lot of the negotiating and management for us for
IPsec to operate.

Why IPSec is needed

Consider the following simple topology for connecting two offices.

We need to ensure the connection of the two offices and fulfill the following goals:

• Confidentiality- provided through data encryption.
• Data integrity- provided through hashing, or through Hashed Message Authentication Code (HMAC), - methods to ensure that the data has not been changed.
• Authentication- provided using pre-shared keys (PSK) or digital signatures... And when using HMAC, authentication happens all the time.
• Antireplay protection- all VPN packets are numbered, which protects them from being repeated.

IPSec protocols and ports

IKEv1 Phase 1	UDP port 500	IKEv1 Phase 1 uses UDP: 500 for its negotiation.
NAT-T (NAT Traversal)	UDP port 4500	NAT Traversal is used by devices to traverse NAT. If both devices connect to each other through NAT: they want to put a fake UDP port 4500 header on each IPsec packet (before the ESP header) to survive a NAT device that otherwise may have a problem tracking an ESP session (Layer 4 protocol 50)
ESP	Layer 4 Protocol 50	All IPSec packets are Layer 4 protocol of ESP (IP Protocol # 50), which encapsulates all data. ESP is usually used (not AH). In case of using NAT-T, the ESP header is covered by the second UDP header.
AH	Layer 4 protocol 51	AH packets are Layer 4 protocol of AH (IP Protocol # 51). AH does not support payload encryption and is therefore rarely used.

IPSec operation

To establish a secure VPN connection, IPSec uses the protocol Internet Key Exchange (IKE).
IKE is a framework provided by Internet Security Association, and Key Management Protocol (ISAKMP)

So in our configuration, both routers will act as VPN gateway or IPsec peers.

Suppose a user on the 10.0.0.0 network sends a packet to the 172.16.0.0 network.
Since the tunnel has not yet been created, R1 will initiate negotiations with the second router R2.

Step 1: Negotiate the IKEv1 Phase 1 Tunnel

The first step between routers rises Internet Key Exchange (IKE) Phase 1 tunnel.
Such a tunnel is not intended for the transmission of user data, but is used for service purposes, to protect management traffic.

Raising the IKE Phase 1 tunnel can be performed in two modes:
- main mode
- aggressive mode
Main mode requires the exchange of a large number of packets but is considered more secure.

To raise the IKE Phase 1 tunnel, the following elements must be negotiated:

• Hash algorithm: It could be message digest 5 algorithm (MD5) or Secure Hash
  Algorithm (SHA).
• Encryption algorithm: Digital Encryption Standard (DES)(weak, not recommended) Triple DES (3DES)(slightly better) or Advanced Encryption Standard (AES)(recommended) AES can use keys of different lengths: the longer the more secure.
• Diffie-Hellman (DH) group to use: The DH “group” refers to the modulus size (length of
  the key) to use for the DH key exchange. Group 1 uses 768 bits, group 2 uses 1024, and
  group 5 uses 1536. More secure DH groups are part of the next-generation encryption
  (NGE):
  - Group 14 or 24: Provides 2048-bit DH
  - Groups 15 and 16: Support 3072-bit and 4096-bit DH
  - Group 19 or 20: Supports the 256-bit and 384-bit ECDH groups, respectively

  DH's job is to generate keying material (symmetric keys). These keys will be used to transfer data.
  DH itself is asymmetrical, but it generates keys symmetrical.

• Authentication method: can be in the form pre-shared key (PSK) or RSA signatures
• Lifetime: IKE Phase 1 tunnel lifetime. The only parameter that may not match. The shorter the Lifetime, the more often the keys will be changed, and the safer it is.

Step 2: Run the DH Key Exchange

After the routers agree on the IKE Phase 1 policy, they can start the DH key exchange process. DH allows two devices that do not yet have a secure connection to securely exchange symmetric keys, which will be used by symmetric algorithms such as AES.

Step 3: Authenticate the Peer

The last thing that will be done in IKE Phase 1 is mutual authentication of hosts, which can be done by two methods (PSK or RSA digital signatures)
If authentication is successful, the IKE Phase 1 tunnel is considered up. The tunnel is bi-directional.

Step 4: IKE Phase 2

After the IKE Phase 1 tunnel has risen, the routers begin to lift the IKE Phase 1 tunnel.
As already mentioned, the IKE Phase 1 tunnel is a purely service, management tunnel and all negotiation traffic passes through it to raise the IKE Phase 2 tunnel.
The IKE Phase 2 tunnel also uses hashing and encryption algorithms.
Raising the IKE Phase 2 tunnel can be done in one mode:
- quick mode

The IKE Phase 2 tunnel is actually two unidirectional tunnels, i.e. we can say that they are created:
One IKE Phase 1 tunnel, which is the bidirectional used for housekeeping.
And two IKE Phase 2 tunnels, which are unidirectional, and which are used to encrypt payload traffic.
All of these tunnels are also referred to as security agreements between the two VPN peers or security associations (SA).
Each SA has its own unique number.

Now, after the IKE Phase 2 tunnel has been raised, all packets leaving the external interfaces will be encrypted.

Configuration example

Let's consider an example of IPsec configuration using this diagram as an example.

1. Configure Interesting Traffic
   First, we need to define the traffic that we will encrypt.
   Router R1

   ip access-list extended VPN-ACL permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

   Router R2

   ip access-list extended VPN-ACL permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

2. Configure Phase 1 (ISAKMP)
   Phase 1 sets up a tunnel used for business purposes: sharing secret keys, authenticate, negotiate IKE security policies, etc.
   Several isakmp policies with different priorities can be created.

   Router R1

   crypto isakmp key secretkey address 200.200.200.1

   Router R2

   crypto isakmp policy 1 encryption 3des hash md5 authentication pre-share group 2

   crypto isakmp key secretkey address 100.100.100.1

   Here key is the PSK (Preshared Key) used by routers for IKE Phase 1 authentication.

3. Configure Phase 2 (IPSEc)
   The purpose of the IKE Phase 2 Tunnel is to transfer payload traffic between the hosts of the two offices.
   The Phase 2 Tunnel parameters are grouped into sets called transform sets.
   Router R1

   crypto ipsec transform-set TRSET esp-3des esp-md5-hmac! crypto map VPNMAP 10 ipsec-isakmp set peer 200.200.200.1 set transform-set TRSET match address VPN-ACL! interface FastEthernet0 / 0 crypto map VPNMAP

   Router R2

   crypto ipsec transform-set TRSET esp-3des esp-md5-hmac! crypto map VPNMAP 10 ipsec-isakmp set peer 100.100.100.1 set transform-set TRSET match address VPN-ACL! interface FastEthernet0 / 0 crypto map VPNMAP

   Both hosts used crypto ipsec transform-set TRSET esp-3des esp-md5-hmac.
   This means that 3des will be used for encryption and md5-hmac for authentication.

   crypto map is posted to the interface. CryptoMap monitors traffic that meets specified conditions. Our crypto map will work with a router with an address of 100.100.100.1, set by the ACL for internal traffic, and will apply transform-set TRSET to this traffic.

IPSec Verification

In general, the list of useful commands is as follows:
show crypto isakmp policy
show crypto map
show crypto isakmp sa detail
show crypto ipsec sa
show crypto engine connections active

In practice, the following are most useful: