IPSec protocols. Anatomy of IPsec. Testing the strength of the legendary protocol

The Encapsulating Security Payload (ESP) protocol ensures data confidentiality. In addition, it allows you to identify the sender of the data, as well as ensure data integrity and protection against information reproduction.

The difference between the ESP protocol and the Authentication Header (AH) protocol is that ESP performs data encryption. At the same time, both protocols provide identification, integrity verification and protection against information reproduction. When working with ESP, both end systems use a shared key to encrypt and decrypt data.

If encryption and data identification are used simultaneously, the responding system first identifies the packet, and if the identification is successful, then decrypts the packet. This way of processing packets reduces the load on the system and reduces the risk of security being compromised by a denial of service attack.

Two ways to use ESP

The ESP protocol can be used in two ways: open transmission mode and tunnel mode. In open transmission mode, the ESP header appears after the IP datagram header. If the datagram already has an IPSec header, then the ESP header is placed before this header. The ESP limit switch and identification data, if any, are indicated after the data field.

In open transfer mode, the IP header is not identified or encrypted. In this case, the addresses specified in the header can be intercepted while the datagram is being transmitted over the network. Communication in open mode requires fewer resources than in tunnel mode. However, this mode provides more low level protection. In most cases, when working with the ESP protocol, the open transfer mode is used.

In tunnel mode, a new IP header is created and becomes the outermost header of the datagram. After it comes the ESP header, and then the datagram itself (IP header and data). The ESP trailer and identification data, if any, are added to the end of the data field. If encryption and authentication are used simultaneously, ESP completely protects the original datagram because the datagram becomes the data field in the new ESP packet. The new IP header is not protected. When establishing a connection between gateways, ESP should be used in tunnel mode.

Information security algorithm used by ESP

The ESP protocol uses a symmetric key to encrypt and decrypt data end systems. Before exchanging data, the sender and recipient must agree on the key they will use. The VPN function supports DES, triple DES (3DES), RC5, RC4, AES, or AES-CBC encryption methods.

When using the AES encryption algorithm, you can enable the Extended Sequence Number (ESN). ESN allows you to transfer large amounts of data at high speeds. The VPN connection uses 64-bit sequence numbers instead of the 32-bit numbers over IPSec. Using 64-bit sequence numbers increases the amount of time before a key change occurs, which prevents the sequence number pool from running out and reduces system resource consumption.

The Internet Working Group (IETF) formally describes the algorithms in the following RFCs:

These and other RFCs can be found on the Internet at the following website: http://www.rfc-editor.org.

The ESP protocol supports HMAC-MD5, HMAC-SHA, HMAC-SHA-256 and AES-XCBC-MAC identification algorithms. Both algorithms take variable-length data and a private key as input and use them to produce fixed-length data (or a hash value or MAC). If the hash values ​​calculated for two messages are the same, then there is a high probability that the messages are the same.

The Internet Working Group (IETF) formally describes the algorithms in the following RFCs:

These RFCs can be viewed at the following website: http://www.rfc-editor.org.

VPNs with IPsec provide flexible and scalable connectivity. Interbranch connections can provide secure, high-speed, and reliable remote communications. Using a VPN with IPsec, information from a private network is transmitted securely via public network. This allows you to create a virtual network rather than using a dedicated connection at Layer 2, as shown in the figure. To ensure data confidentiality, traffic is encrypted.

IPsec is an IETF standard that defines how a VPN network can be configured securely using the IP protocol.

IPsec is an open standards framework that defines the rules for secure communications. IPsec is not associated with specific encryption or authentication methods, security algorithms, or key exchange technology. IPsec uses existing algorithms to ensure secure communications. IPsec allows you to create new, better algorithms, the development of which does not require adjustments to existing IPsec standards.

IPsec operates at the network layer to provide security and authentication of IP packets between communicating IPsec devices, also called peers. IPsec allows you to secure the path between a pair of gateways, a pair of computers, or between a gateway and a computer. As a result, IPsec can protect almost any application traffic, since it can implement protection at layers 4 to 7.

All IPsec solutions implemented use an unencrypted Layer 3 header, so there are no routing issues. IPsec operates on top of any Layer 2 protocols such as Ethernet, ATM, and Frame Relay.

The following are the main features of the IPsec protocol:

• IPsec is an open standards framework that is independent of algorithms.

• IPsec provides data confidentiality and integrity, as well as source authentication.

• IPsec acts as a network layer protocol, protecting IP packets and verifying their authenticity.

• IP protection

The figure shows that IPsec security services perform the following important functions:

• 
  
• • Confidentiality (encryption)- online VPN private data is transmitted over a public network. Therefore, ensuring data confidentiality is key. To achieve this, data is encrypted before transmission over the network. Encryption is the process of encoding all data sent from one computer to another into a form that only the receiving computer can decode. If a message is intercepted, an attacker (hacker) will not be able to read it. IPsec provides advanced security features (such as strong encryption algorithms).
  • Data integrity- The recipient can verify that the data was transmitted normally over the Internet and has not been modified in any way. It is important not only to ensure that data is encrypted on a public network, but also to ensure that it has not been modified in transit. IPsec provides a mechanism to check that there have been no changes to the encrypted portion of the packet, the entire header, or the data body of the packet. IPsec guarantees data integrity using checksums (simple redundancy checking is used). If corruption is detected, the packet is discarded.
  • Authentication- allows you to check who was the source of the sent data. This is necessary to protect against attacks that use spoofing (sender spoofing). Authentication helps ensure that a connection to the correct communication partner is established. The recipient can verify the identity of the packet's source by certifying the source of the information. IPsec uses Internet Key Exchange (IKE) technology to authenticate users and devices that can communicate independently of each other. IKE uses various types of authentication (including username and password, one-time password, biometrics, Pre-Shared Key (PSK), and digital certificates).
  • Replay protection- allows you to detect and reject duplicate packets, as well as prevent spoofing. With replay protection, you can ensure that a packet is unique and not duplicated. IPsec packets are secured by comparing the sequence number of received packets to a sliding window at the destination host or security gateway. A packet with a sequence number that comes before the sliding window is considered delayed or duplicated. Delayed and duplicate packets are discarded.

  The abbreviation CIA in many cases brings to mind these three functions: confidentiality, integrity, and authentication.

• IPsec protocol structure

Confidentiality

Confidentiality VPN traffic supported by encryption. Clear (unencrypted) data transmitted over the Internet can be intercepted and read. Encryption is used to maintain data privacy. Digital encryption of data remains unreadable until it is decrypted by an authorized recipient.

To ensure encrypted communication, both the sender and the recipient must know the rules used to convert the original message into an encrypted form. The rules are based on algorithms and corresponding keys. In the context of encryption, an algorithm is a mathematical sequence of actions that combines a message, text, numbers, or all of them with a string of numbers called a key. The output appears as an unreadable encrypted string. The encryption algorithm also determines how the encrypted message is decrypted. Without the correct key, it is almost impossible to decrypt the data.

• 
  

The picture shows that Gail wants to perform an electronic transfer cash via the Internet to Jeremy. On the local side, the document is combined with a key and subjected to an encryption procedure. The output is ciphertext. This ciphertext is then sent over the Internet. On the remote side, the message is again combined with the key and passed through the encryption algorithm in the opposite direction. The output represents the original financial document.

Confidentiality is achieved by encrypting traffic when transmitted via VPN. The degree of security depends on the length of the key in the encryption algorithm and the complexity of the algorithm itself. If a hacker tries to crack a key using a brute-force attack, the number of brute-force options will depend on the length of the key. The processing time for all possible options depends on the computing power of the attacker’s computer. Therefore, the shorter the key, the easier it is to crack it. For example, while it would take a relatively powerful computer approximately one year to crack a 64-bit key, it could take the same computer between 10 and 19 years to crack a 128-bit key.

IPsec encryption algorithms

The degree of security depends on the length of the key in the encryption algorithm. As the key length increases, the likelihood of breaking the cipher decreases. However, the longer the key, the more CPU resources will be required to encrypt and decrypt the data.

DES and 3DES are no longer considered secure, so AES is recommended for IPsec encryption. The highest level of security for VPN encryption between Cisco devices using IPsec is provided by the 256-bit AES option. Additionally, because 512-bit and 768-bit Rivest-Shamir-Edleman (RSA) keys can be compromised, Cisco recommends using 2048-bit keys in the RSA flavor (if used during the IKE authentication phase).

Symmetric encryption

Encryption algorithms such as AES require a shared secret key to perform both encryption and decryption. To decode information, both network devices must know the key. With symmetric key encryption (also called private key encryption), each device encrypts data before it is sent over the network to another device. With symmetric key encryption, you need to know which devices are talking to each other so that each device can be configured with the same key (see Figure 1).

For example, the sender creates a coded message where each letter changes to the letter next two letters down in the alphabet (that is, A becomes C, B becomes D, etc.). In this case, the word SECRET becomes UGETGV. The sender has already told the recipient that the secret key is an offset of 2. When the recipient receives a UGETGV message, his computer decodes the message by backshifting by two letters and receives the word SECRET. Any other user looking at this message sees it in encrypted form. To prevent such a message from looking like gobbledygook, you need to know the secret key.

The following are the features of symmetric algorithms:

• cryptography based on symmetric keys is used;

• the same key is used for encryption and decryption;

• typically used to encrypt the contents of a message.

• Examples: DES, 3DES and AES

How can the encrypting and decrypting devices obtain information about the shared secret key? Shared secret keys could of course be sent to device administrators via email, regular mail, or courier. But another, more reliable method is asymmetric encryption.

Asymmetric encryption

Asymmetric encryption uses different keys for encryption and decryption. Knowing one of the keys prevents a hacker from figuring out the second key and decoding the information. One key is used to encrypt the message, the second is used to decrypt it (see Figure 2). You cannot perform encryption and decryption using the same key.

One of the options asymmetric encryption is public key encryption, where a combination of secret and open (public) keys is used. The recipient provides the public key to any sender with whom the recipient needs to communicate. To encrypt a message, the sender uses a secret key, which is combined with the recipient's public key. In addition, the sender must share its public key with the recipient. To decrypt the message, the recipient will use the sender's public key along with their own private key.

The following are the features of asymmetric algorithms:

• public key cryptography is used;

• different keys are used for encryption and decryption;

• Typically used in digital certificate and key management.

Integrity and hashing algorithms

Hash algorithms are used to ensure the integrity and authentication of VPN traffic. Data integrity and authentication are ensured by hash codes, which ensure that transmitted messages are not tampered with by unauthorized persons. A hash code, also called a message digest, is a number that is created from a string of text. The hash code is smaller than the text itself. It is created using a formula in such a way that obtaining the same hash code value from another text is extremely unlikely.

The original sender creates a hash of the message and sends it along with the message itself. The recipient parses the message and the hash code, creates another hash code based on the received messages, and compares both hashes. If they match, then the recipient can have reasonable confidence in the integrity of the original message.

The picture shows that Gale sent Alex an email remittance in the amount of 100 US dollars. Jeremy intercepted and altered the transfer to show that he was the recipient and the transfer amount was $1,000. In this case, if a data integrity algorithm was used, the hashes will not match each other and the transaction will be invalid.

VPN data is transmitted over the public Internet. As shown in the figure, there is a possibility of interception and modification of this data. To protect against this threat, computers may have hash codes added to the message. If the transmitted hash code matches the received hash code, the integrity of the message is ensured. However, if the hashes do not match, then the message has been modified.

To verify the integrity and authenticity of a message, VPNs use an authentication code without using any additional mechanisms.

Hash-based Message Authentication Code (HMAC) is a mechanism for authenticating messages using hashing functions. HMAC with key exchange is a data integrity algorithm that guarantees message integrity. HMAC has two parameters: the input message and a secret key known only to the message's author and intended recipients. The message sender uses the HMAC function to create a value (message authentication code) generated by processing the secret key and the input message. The message authentication code is sent along with the message. The recipient calculates the message authentication code in the received message using the same key and HMAC function that the sender used. The recipient then compares the calculated result with the received message authentication code. If both values ​​match, the correct message was received and the recipient can be confident that the sender is a member of the community of users using the shared key. The cryptographic strength of the HMAC algorithm depends on the cryptographic strength of the underlying hash function, the size and quality of the key, and the length of the hash function result (in bits).

There are two most common HMAC algorithms:

• MD5- a 128-bit shared secret key is used. The random length message and the 128-bit shared secret key are combined with each other and processed by the HMAC-MD5 hashing algorithm. The result is a 128-bit hash code. The hash code is added to the original message and forwarded to the remote party.

• SHA- SHA-1 uses a 160-bit shared secret key. The variable length message and the 160-bit shared secret key are combined with each other and processed by the HMAC-SHA1 hashing algorithm. The result is a 160-bit hash code. The hash code is added to the original message and forwarded to the remote party.

Note. Cisco IOS also supports 256-, 384-, and 512-bit SHA options.

IPsec authentication

IPsec VPNs support authentication functionality. If your business partners are located at a great distance from you, then it is important to know who you are talking to on the phone, who is sending you an email or fax. The same is true for VPN networks. As indicated in the figure, the identity of the device at the other end of the VPN tunnel must be verified before the communication channel can be considered secure. There are two methods for authenticating the interlocutor:

• PSK- a secret key known in advance to two users who communicate over a secure channel. The pre-shared key (PSK) method uses symmetric key cryptographic algorithms. The PSK key is manually entered on each of the communicating nodes (peers) and is used to authenticate each other. On each side, the PSK is combined with other information to form an authentication key.

The IPsec algorithm uses the RSA (public key cryptographic system) algorithm for authentication in the context of IKE. RSA uses the scheme digital signature, thanks to which each device attaches a digital signature to a set of data and transfers it to another user. The RSA signing algorithm uses a certificate authority (CA) to create a digital certificate with a unique identifier that is assigned to each peer for authentication. The digital identity certificate itself is similar to a PSK key, but provides a much higher level of security. Each initiator and responder in an IKE session that uses RSA signatures sends its own identity value, its digital identity certificate, and an RSA signature value consisting of multiple IKE values. An IKE-negotiated encryption method (such as AES) is used to encrypt all this data.

Another authentication method is the digital signature algorithm (Digital Signature Algorithm, DSA).

IPsec protocol structure

As stated above, the IPsec protocol suite describes a way to exchange messages to secure communication sessions, but it is based on the application of existing algorithms.

Figure 1 shows the two main IPsec protocols:

• Authentication Header (AH)- AH is a special protocol used in cases where confidentiality is not required or prohibited. It provides authentication and data integrity for IP packets sent between two systems. However, AH does not provide confidentiality (encryption) of the data in the packets. All text is transmitted in clear text (without encryption). If only the AH protocol is used (and no other mechanisms are used), then it provides weak protection.

• Encapsulating Security Payload (ESP) is a security protocol that provides confidentiality and authentication by encrypting the IP packet. The process of encrypting an IP packet hides the source and destination data and identifiers. ESP verifies the authenticity of the internal IP packet and the ESP header. Authentication ensures the authenticity of the data source and the integrity of the data. Although encryption and authentication procedures are not required in ESP, you must select at least one of them.

In Fig. Figure 2 shows the components of an IPsec configuration. There are four basic building blocks of the IPsec design that must be selected.

• Privacy (if IPsec with ESP is selected)- the selected encryption algorithm must in the best possible way provide the required level of security: DES, 3DES or AES. AES is strongly recommended (AES-GCM provides the highest level of security).

• Integrity- ensures that the content has not been changed during transmission. To perform this function, hashing algorithms are used. You can choose MD5 and SHA.

• Authentication- Defines how devices at both ends of the VPN tunnel are authenticated. Available options: PSK or RSA.

• Group of DH algorithms- defines the method for generating a shared secret key between nodes. There are several options, but the DH24 provides the highest level of security.

The combination of these building blocks provides confidentiality, integrity, and authentication for IPsec VPNs.

Note. This section provides a general description of IPsec to help you understand how IPsec secures VPN tunnels. The process of setting up IPsec VPN networks is not covered in this course.

(Internet Security Association and Key Management Protocol (ISAKMP) - Management of keys and authenticators for secure connections.

IPsec architecture

IPsec protocols, unlike other well-known protocols SSL and TLS, operate at the network layer (layer 3 of the OSI model). This makes IPsec more flexible so that it can be used to protect any TCP and UDP based protocols. 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 a "superstructure" on top of the IP protocol, and processes generated IP packets in the manner described below. IPsec can ensure the integrity and/or confidentiality of data transmitted over a network.

IPsec uses the following protocols to perform various functions:

• Authentication Header (AH) ensures the integrity of the virtual connection (transmitted data), authentication of the source of information and additional function to prevent packet retransmission
• Encapsulating Security Payload (ESP) can ensure confidentiality (encryption) of transmitted information, limiting the flow of confidential traffic. In addition, it can provide integrity of the virtual connection (transmitted data), authentication of the source of information and the additional function of preventing packet retransmission (Whenever ESP is used, mandatory one or another set of security services data must be used)
• Security Associations (SAs) provide a set of algorithms and data that provide the parameters required for AH and/or ESP operation. The Internet Security Association and Key Management Protocol (ISAKMP) provides the basis for authentication and key exchange, verifying the authenticity of keys.

Security Association

The concept of "Secure Virtual Connection" (SA, "Security Association") is fundamental to the IPsec architecture. An SA is a simplex connection that is formed to carry appropriate 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 in accordance with the concept of inter-terminal connection (point-to-point) and can operate in two modes: transport mode (RTR) 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 token consisting of three elements:

• security parameter index (SPI)
• Destination IP addresses
• security protocol identifier (ESP or AH)

The IPsec module, having these three parameters, can find an entry in the SADB for a specific SA. The list of SA components includes:

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

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

In addition to the SADB, IPsec implementations support an SPD (Security Policy) database. Database security policy data). 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 to match each packet to a specific SA. When a packet is generated, 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) for the packet and its associated security parameter index (SPI) are then determined. After which 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

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

Processing Output IP Packets

If the sending IPsec module determines that the packet is associated with an SA that involves AH processing, then it begins 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 protocol header and before the upper layer protocol headers (usually TCP or UDP). In tunneling mode, the entire original IP packet is framed first by the AH header, then by the IP protocol header. This header is called external, and the header of the original IP packet is called internal. After this, the sending IPsec module must generate a serial number and write it in the field Sequence Number. When an SA is established, the sequence number is set to 0 and incremented by one before each IPsec packet is sent. In addition, a check is made to see if the counter has gone into a loop. If it has reached its maximum value, then it is set back to 0. If the replay prevention service is used, then when the counter reaches its maximum value, the sending IPsec module resets the SA. This ensures protection against packet re-sending - the receiving IPsec module will check the field Sequence Number, and ignore re-arriving 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 recalculate the hash, but without knowing the key, he will not be able to generate the correct checksum. The specific algorithms used to calculate ICV can be found in RFC 4305. Currently, for example, the HMAC-SHA1-96 or AES-XCBC-MAC-96 algorithms can be used. The AH protocol calculates a checksum (ICV) based on the following fields of the IPsec packet:

• IP header fields that have not been modified during translation or have been 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

Processing of input IP packets

After receiving a packet containing an AH protocol message, the IPsec receiving module looks up the corresponding SADB (Security Associations Database) using the recipient's IP address, the security protocol (SA) and the SPI index. If no matching SA is found, the packet is discarded. The Secure Virtual Connection (SA) found indicates whether the packet replay prevention service is being used, i.e. on the need to check the field Sequence Number. If the service is used, the field is checked. For this, the sliding window method is used. The receiving IPsec module generates a window with a width of W. The left edge of the window corresponds to the minimum sequence number( Sequence Number) N of correctly received packet. Package with field Sequence Number, which contains 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. 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 gives a negative result, then the receiving packet is destroyed.

Processing IPsec Output Packets

If the sending IPsec module determines that the packet is associated with an SA that requires ESP processing, it begins processing. Depending on the mode (transport or tunneling mode), the original IP packet is processed differently. In transport mode, the transmitting IPsec module carries out the procedure of framing (encapsulating) the upper-level protocol (for example, TCP or UDP), using the ESP header and ESP trailer, without affecting the header of the source IP packet. In tunneling mode, the IP packet is surrounded by an ESP header and an ESP trailer, and then surrounded by an outer IP header. Next, encryption is carried out - in transport mode, only the protocol message above the underlying layer is encrypted (i.e., everything that was after the IP header in the source packet), in tunneling mode, the entire source IP packet. The sending IPsec module determines the encryption algorithm and secret key from the SA record. IPsec standards allow the use of triple-DES, AES and Blowfish encryption algorithms. Since the plaintext size must be a multiple of a certain number of bytes, such as the block size for block algorithms, before encryption, the necessary addition to the encrypted message is also performed. The encrypted message is placed in the field Payload Data. In the field Pad Length fits the length of the addition. Then, as in AH, it is calculated Sequence Number. After which the checksum (ICV) is calculated. The checksum, unlike the AH protocol, where some fields of the IP header are also taken into account when calculating it, in ESP it is calculated only from the fields of the ESP packet minus the ICV field. It is filled with zeros before the checksum is calculated. The ICV calculation algorithm, as in the AH protocol, is learned by the transmitting IPsec module from the record of the SA with which the packet being processed is associated.

Processing incoming IPsec packets

After receiving a packet containing an ESP protocol message, the IPsec receiving module looks up the corresponding secure virtual connection (SA) in the SADB (Security Associations Database) using the recipient's IP address, security protocol (ESP) and SPI index. If no matching SA is found, the packet is discarded. The Secure Virtual Connection (SA) found indicates whether the packet replay prevention service is being used, i.e. the need to check the Sequence Number field. If the service is used, the field is checked. For this, as in AH, the sliding window method is used. The receiving IPsec module generates a window with a width of 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 received 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 appropriate 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 matches the received one, then the incoming packet is considered valid. If the check gives a negative result, then the receiving packet is destroyed. Next, the packet is decrypted. The IPsec receiving module learns from the SA record which encryption algorithm is used and the secret key. It should be noted that the checksum verification and decryption procedure can be carried out not only sequentially, but also in parallel. In the latter case, the checksum verification procedure must finish before the decryption procedure, and if the ICV check fails, the decryption procedure must also terminate. This allows you to quickly identify corrupted packets, which, in turn, increases the level of protection against denial of service attacks (DOS attacks). Next is the decrypted message in accordance with the field Next Header transferred for further processing.

Usage

The IPsec protocol is used mainly for organizing VPN tunnels. In this case, the ESP and AH protocols operate in tunneling mode. In addition, by configuring security policies in a certain 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 installed and the screen looks at all packets passing through it. If transmitted packets are subject to these rules, firewall processes them accordingly. For example, it can reject certain packets, thereby stopping insecure connections. By setting the security policy accordingly, you can, for example, block Internet traffic. To do this, it is enough to prohibit the sending of packets containing HTTP and HTTPS protocol messages. IPsec can also be used to protect servers - for this, all packets are discarded, except for those necessary for the correct execution of server functions. For example, for a Web server, you can block all traffic except connections through port 80 TCP protocol, or via TCP port 443 in cases where HTTPS is used.

See also

Links

• IPSec Configuration Description (cisco.com)

IN modern world Various VPN technologies are used everywhere. Some (for example, PPTP) are recognized as unsafe over time and gradually die out, others (OpenVPN), on the contrary, are increasing their momentum every year. But the undisputed leader and most recognizable technology for creating and maintaining secure private channels is still IPsec VPN. Sometimes during a pentest you can find a seriously protected network with only the five hundredth UDP port sticking out. Everything else can be closed, patched and reliably filtered. In such a situation, the thought may arise that there is nothing special to do here. But this is not always the case. In addition, there is a widespread idea that IPsec, even in default configurations, is impregnable and provides the proper level of security. This is exactly the situation we will look at in practice today. But first, in order to combat IPsec as effectively as possible, you need to understand what it is and how it works. This is what we'll do!

IPsec from the inside

Before moving directly to IPsec itself, it would be nice to remember what types of VPNs there are. There are a great many classifications of VPNs, but we will not dive deeply into network technologies and will take the simplest one. Therefore, we will divide VPN into two main types - site-to-site VPN connections (they can also be called permanent) and remote access VPN (RA, also temporary).
The first type serves for constant communication of various network islands, for example, a central office with many scattered branches. Well, RA VPN is a scenario when a client connects for a short period of time, gains access to certain network resources, and then safely disconnects after completing the work.

We will be interested in the second option, since in the event of a successful attack, it is possible to immediately gain access to the internal network of the enterprise, which is quite a serious achievement for a pentester. IPsec, in turn, allows you to implement both site-to-site and remote access VPN. What kind of technology is this and what components does it consist of?

It is worth noting that IPsec is not one, but a whole set of different protocols that provide transparent and secure data protection. The specificity of IPsec is that it is implemented at the network layer, complementing it in such a way that everything happens unnoticed for subsequent layers. The main difficulty is that in the process of establishing a connection, two participants in a secure channel need to agree on large number various parameters. Namely, they must authenticate each other, generate and exchange keys (and through an untrusted environment), and also agree on which protocols to encrypt data.

It is for this reason that IPsec consists of a stack of protocols whose responsibility is to ensure the establishment, operation and management of a secure connection. The entire connection establishment process consists of two phases: the first phase is used to ensure the secure exchange of ISAKMP messages already in the second phase. ISAKMP (Internet Security Association and Key Management Protocol) is a protocol that serves to negotiate and update security policies (SA) between participants in a VPN connection. These policies specifically indicate which protocol to use to encrypt (AES or 3DES) and what to authenticate with (SHA or MD5).

Two Main Phases of IPsec

So, we found out that the participants first need to agree on what mechanisms will be used to create a secure connection, so now the IKE protocol comes into play. IKE (Internet Key Exchange) is used to form an IPsec SA (Security Association, those same security policies), in other words, to coordinate the work of participants in a secure connection. Through this protocol, participants agree on what encryption algorithm will be used, what algorithm will be used to check integrity, and how to authenticate each other. It should be noted that today there are two versions of the protocol: IKEv1 and IKEv2. We will only be interested in IKEv1: despite the fact that the IETF (The Internet Engineering Task Force) first introduced it in 1998, it is still very often used, especially for RA VPNs (see Figure 1).

As for IKEv2, its first drafts were made in 2005, it was fully described in RFC 5996 (2010), and only at the end of last year it was announced as an Internet standard (RFC 7296). You can read more about the differences between IKEv1 and IKEv2 in the sidebar. Having dealt with IKE, we return to the IPsec phases. During the first phase, participants authenticate each other and agree on the parameters for establishing a special connection intended only for exchanging information about the desired encryption algorithms and other details of the future IPsec tunnel. The parameters of this first tunnel (also called the ISAKMP tunnel) are determined by the ISAKMP policy. The first step is to agree on hashes and encryption algorithms, then exchange Diffie-Hellman (DH) keys, and only then figure out who is who. That is, the last step is the authentication process, either using a PSK or RSA key. And if the parties come to an agreement, then an ISAKMP tunnel is established, through which the second phase of IKE already passes.

In the second phase, the participants who already trust each other agree on how to build the main tunnel for directly transferring data. They offer each other the options specified in the transform-set parameter, and if they agree, they raise the main tunnel. It is important to emphasize that once it is established, the auxiliary ISAKMP tunnel does not go away - it is used to periodically update the SA of the main tunnel. As a result, IPsec in some way establishes not one, but two tunnels.

How to process data

Now a few words about transform-set. After all, you need to somehow encrypt the data going through the tunnel. Therefore, in a typical configuration, transform-set is a set of parameters that explicitly indicate how the packet should be processed. Accordingly, there are two options for such data processing - the ESP and AH protocols. ESP (Encapsulating Security Payload) deals directly with data encryption and can also provide data integrity verification. AH (Authentication Header), in turn, is only responsible for authenticating the source and checking data integrity.

For example, the command crypto ipsec transform-set SET10 esp-aes will indicate to the router that the transform-set with the name SET10 should only work using the ESP protocol and with encryption by AES algorithm. Looking ahead, I will say that hereinafter we will use Cisco routers and firewalls as targets. Actually, with ESP everything is more or less clear, its job is to encrypt and thereby ensure confidentiality, but why then is AH needed? AH provides data authentication, that is, it confirms that this data came exactly from the one with whom we established the connection and was not changed along the way. It provides what is sometimes called anti-replay protection. IN modern networks AH is practically not used, only ESP can be found everywhere.

The parameters (aka SA) selected to encrypt information in an IPsec tunnel have a lifetime, after which they must be replaced. The default lifetime IPsec SA setting is 86,400 seconds, or 24 hours.
As a result, the participants received an encrypted tunnel with parameters that suited them all, and sent data streams to be encrypted there. Periodically, in accordance with lifetime, the encryption keys for the main tunnel are updated: the participants again communicate via the ISAKMP tunnel, go through the second phase and re-establish the SA.

IKEv1 modes

We've taken a quick look at the basic mechanics of how IPsec works, but there are a few more things we need to focus on. The first phase, among other things, can operate in two modes: main mode or aggressive mode. We have already discussed the first option above, but we are interested in the aggressive mode. This mode uses three messages (instead of six in main mode). In this case, the one who initiates the connection gives all his data at once - what he wants and what he can do, as well as his part of the DH exchange. The responder then immediately completes its portion of the DH generation. As a result, there are essentially only two stages in this mode. That is, the first two stages from main mode (hash agreement and DH exchange) are, as it were, compressed into one. As a result, this mode is much more dangerous due to the fact that a lot of technical information in plaintext. And most importantly, the VPN gateway can send a password hash, which is used for authentication in the first phase (this password is often called a pre-shared key or PSK).

Well, all subsequent encryption occurs without changes, as usual. Why then is this mode still used? The fact is that it is much faster, about twice as fast. Of particular interest to the pentester is the fact that the aggressive mode is very often used in RA IPsec VPN. Another small feature of RA IPsec VPN when using aggressive mode: when the client contacts the server, it sends it an identifier (group name). Tunnel group name (see Figure 2) is the name of an entry that contains a set of policies for a given IPsec connection. This is already one of the features specific to Cisco equipment.

Two phases were not enough

It would seem that this is not a very simple scheme of work, but in reality it is still a little more complicated. Over time, it became clear that PSK alone was not enough to ensure security. For example, in case of compromise workstation employee, the attacker could immediately gain access to the entire internal network of the enterprise. Therefore, phase 1.5 was developed right between the first and second classical phases. By the way, this phase is usually not used in a standard site-to-site VPN connection, but is used when organizing remote VPN connections (our case). This phase contains two new extensions - Extended Authentication (XAUTH) and Mode-Configuration (MODECFG).

XAUTH is an additional user authentication within the IKE protocol. This authentication is also sometimes called IPsec second factor. Well, MODECFG is used to transmit additional information to the client, this could be an IP address, mask, DNS server, etc. It can be seen that this phase simply complements those previously discussed, but its usefulness is undoubted.

IKEv2 vs IKEv1

Both protocols operate on UDP port number 500, but are incompatible with each other; a situation where there is IKEv1 at one end of the tunnel and IKEv2 at the other is not allowed. Here are the main differences between the second version and the first:

• In IKEv2 there are no longer such concepts as aggressive or main modes.
• In IKEv2, the term first phase is replaced by IKE_SA_INIT (an exchange of two messages that ensures the negotiation of encryption/hashing protocols and the generation of DH keys), and the second phase is replaced by IKE_AUTH (also two messages that implement authentication itself).
• Mode Config (what was called phase 1.5 in IKEv1) is now described directly in the protocol specification and is an integral part of it.
• IKEv2 added an additional mechanism to protect against DoS attacks. Its essence is that before responding to each request in establishing a secure connection (IKE_SA_INIT) IKEv2, the VPN gateway sends a certain cookie to the source of such a request and waits for a response. If the source responded - everything is in order, you can start generating DH with it. If the source does not respond (this is what happens in the case of a DoS attack; this technique is reminiscent of TCP SYN flood), then the VPN gateway simply forgets about it. Without this mechanism, with every request from anyone, the VPN gateway would try to generate a DH key (which is a fairly resource-intensive process) and would soon run into problems. As a result, due to the fact that all operations now require confirmation from the other side of the connection, it is impossible to create a large number of half-open sessions on the attacked device.

We're reaching the milestone

Having finally understood the operating features of IPsec and its components, you can move on to the main thing - practical attacks. The topology will be quite simple and at the same time close to reality (see Fig. 3).

The first step is to determine the presence of an IPsec VPN gateway. This can be done by performing a port scan, but there is a small feature here. ISAKMP uses UDP protocol, port 500, and yet the default scanning with Nmap affects only TCP ports. And as a result there will be a message: All 1000 scanned ports on 37.59.0.253 are filtered.

It seems that all ports are filtered and there are no open ports. But after executing the command

Nmap -sU --top-ports=20 37.59.0.253 Starting Nmap 6.47 (http://nmap.org) at 2015-03-21 12:29 GMT Nmap scan report for 37.59.0.253 Host is up (0.066s latency) . PORT STATE SERVICE 500/udp open isakmp

We make sure that this is not the case and that this is indeed a VPN device.

Let's attack the first phase

Now we will be interested in the first phase, aggressive mode and authentication using pre-shared key (PSK). In this scenario, as we remember, the VPN device or responder sends a hashed PSK to the initiator. One of the most famous utilities for testing the IKE protocol is ike-scan, it is included in the distribution kit Kali Linux. Ike-scan allows you to send IKE messages with various parameters and, accordingly, decode and parse response packets. Let's try to probe the target device:

Root@kali:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify

The -A switch indicates that aggressive mode should be used, and -M indicates that the results should be displayed line by line (multiline), for more easy reading. It is clear that no result was obtained. The reason is that you need to specify the same identifier, the name of the VPN group. Of course, the ike-scan utility allows you to set this identifier as one of its parameters. But since it is still unknown to us, let’s take an arbitrary value, for example 0000.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Aggressive Mode Handshake returned

This time we see that the answer was received (see Fig. 5) and we were provided with quite a lot useful information. A fairly important part of the information received is the transform-set. In our case, it states that “Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK”.

All these parameters can be specified for the ike-scan utility using the --trans switch. For example, --trans=5,2,1,2 will indicate that the encryption algorithm is 3DES, hashing HMAC-SHA, authentication method PSK and the second type of DH group (1024-bit MODP). You can view the value correspondence tables at this address. Let's add another key (-P) in order to display the payload of the package directly, or rather the PSK hash.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P

Overcoming the first difficulties

It would seem that the hash has been obtained and you can try to brute it, but everything is not so simple. Once upon a time, in 2005, some Cisco hardware had a vulnerability: these devices gave a hash only if the attacker passed the correct ID value. Now, of course, it is almost impossible to find such equipment and a hashed value is always sent, regardless of whether the attacker sent the correct ID value or not. Obviously, brute force hashing is pointless. Therefore, the first task is to determine the correct ID value in order to obtain the correct hash. And a recently discovered vulnerability will help us with this. The point is that there is a slight difference between the responses during the initial exchange of messages. In short, if the correct group name is used, there are four attempts to continue establishing the VPN connection plus two encrypted phase two packets. While in the case of an incorrect ID, only two packets arrive in response. As you can see, the difference is quite significant, so SpiderLabs (the author of the equally interesting Responder tool) first developed a PoC and then the IKEForce utility to exploit this vulnerability.

What is the strength of IKE

You can install IKEForce in an arbitrary directory by running the command

Git clone https://github.com/SpiderLabs/ikeforce

It works in two main modes - calculation mode -e (enumeration) and brute force mode -b (bruteforce). We'll get to the second one when we look at attacks on the second factor, but we'll deal with the first one now. Before you begin the actual process of determining the ID, you need to set the exact value of transform-set. We have already defined it earlier, so we will specify it with the -t 5 2 1 2 option. As a result, the process of finding the ID will look like this:

Python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2

As a result, it was possible to obtain the correct ID value quite quickly (Fig. 7). The first step has been completed, you can move on.

We receive PSK

Now you need to save the PSK hash to a file using the correct group name, this can be done using ike-scan:

Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk

And now that the correct ID value has been found and the correct PSK hash has been obtained, we can finally start offline brute force. There are quite a lot of options for such brute force - this is the classic psk-crack utility, and John the Ripper (with a jumbo patch), and even oclHashcat, which, as is known, allows you to use the power of the GPU. For simplicity, we will use psk-crack, which supports both direct brute force and dictionary attack:

Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk

But even successfully restoring PSK (see Fig. 8) is only half the battle. At this stage, we need to remember that what awaits us next is XAUTH and the second factor of IPsec VPN.

Dealing with the second IPsec factor

So, let me remind you that XAUTH is an additional security, a second authentication factor, and it is in phase 1.5. There can be several options for XAUTH - this includes verification using the RADIUS protocol, and one-time passwords (OTP), and a regular local user base. We will focus on the standard situation when a local user base is used to check the second factor. Until recently, there was no publicly available tool for brute force XAUTH. But with the advent of IKEForce, this problem received a worthy solution. Launching the XAUTH brute force is quite simple:

Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Program started in XAUTH Brute Force Mode [+]Single user provided - brute forcing passwords for user: admin [*]XAUTH Authentication Successful! Username: admin Password: cisco

In this case, all previously found values ​​are indicated: ID (switch -i), restored PSK (switch -k) and expected login (switch -u). IKEForce supports both brute force search of a login and search through a list of logins, which can be specified with the -U parameter. In case of possible selection blocking, there is the -s option, which allows you to reduce the brute force speed. By the way, the utility comes with several good dictionaries, especially useful for setting the value of the ID parameter.

Login to the internal network

Now that we have all the data, the last step remains - actually penetrating the local network. To do this, we will need some kind of VPN client, of which there are a great many. But in the case of Kali, you can easily use the already pre-installed VPNC. In order for it to work, you need to adjust one configuration file - /etc/vpnc/vpn.conf. If it doesn’t exist, then you need to create and fill in a number of obvious parameters:

IPSec gateway 37.59.0.253 IPSec ID vpn IPSec secret cisco123 IKE Authmode psk Xauth Username admin Xauth password cisco

Here we see that absolutely all the data found in the previous steps was used - the ID value, PSK, login and password of the second factor. After which the connection itself occurs with one command:

Root@kali:~# vpnc vpn

Disabling is also quite simple:

Root@kali:~# vpnc-disconnect

You can check if the connection is working using the ifconfig tun0 command.

How to build reliable protection

Protection against the attacks discussed today must be comprehensive: you need to install patches on time, use strong pre-shared keys, which, if possible, should be replaced with digital certificates. Password policy and other obvious information security elements also play an important role in ensuring security. It should also be noted that the situation is gradually changing, and over time only IKEv2 will remain.

What's the result?

We've covered the RA IPsec VPN audit process in detail. Yes, of course, this task is far from trivial. You need to take many steps, and difficulties may await you at each of them, but if successful, the result is more than impressive. Gaining access to internal network resources opens up the widest scope for further actions. Therefore, those who are responsible for protecting the network perimeter should not rely on ready-made default templates, but carefully think through each security layer. Well, for those who conduct pentests, the detected UDP port five hundred is a reason to conduct a deep analysis of IPsec VPN security and, possibly, get good results.

Internet Protocol Security (IPSec) is called a system in Internet standards. Indeed, IPSec is a consistent set of open standards that today has a well-defined core, and at the same time it can be quite easily expanded with new protocols, algorithms and functions.

The main purpose of IPSec protocols is to ensure secure data transmission over IP networks. The use of IPSec guarantees:

• integrity, i.e. that the data during transmission was not distorted, lost or duplicated;
• authenticity, i.e. that the data was transmitted by the sender who proved that he is who he claims to be;
• confidentiality, i.e. that the data is transmitted in a form that prevents unauthorized viewing.

(Note that, in accordance with the classical definition, the concept of data security includes one more requirement - the availability of data, which in the context considered can be interpreted as a guarantee of their delivery. IPSec protocols do not solve this problem, leaving it to the TCP transport layer protocol.)

SECURED CHANNELS AT DIFFERENT LEVELS

IPSec is only one of many, although the most popular today, technology for secure data transmission over a public (unsecured) network. For technologies of this purpose, a general name is used - secure channel. The term "channel" emphasizes the fact that data protection is provided between two network nodes (hosts or gateways) along some virtual path, laid in a packet switching network.

A secure channel can be built using system tools implemented at different layers of the OSI model (see Figure 1). If a protocol of one of the upper levels (application, presentation or session) is used to protect data, then this method of protection does not depend on which networks (IP or IPX, Ethernet or ATM) are used to transport data, which can be considered an undoubted advantage. On the other hand, the application becomes dependent on a specific security protocol, i.e. for applications such a protocol is not transparent.

A secure channel at the highest, application level has one more drawback - a limited scope. The protocol protects only a very specific network service - file, hypertext or email. For example, the S/MIME protocol exclusively protects email messages. Therefore, a corresponding secure version of the protocol must be developed for each service.

The most well-known secure channel protocol operating at the next presentation level is the Secure Socket Layer (SSL) protocol and its new open implementation Transport Layer Security (TLS). Lowering the protocol level makes it a much more versatile security tool. Now any application and any application-level protocol can use a single security protocol. However, applications still need to be rewritten to include explicit calls to secure channel protocol functions.

The lower down in the stack secure channel facilities are implemented, the easier it is to make them transparent to applications and application protocols. At the network and data link levels, applications' dependence on security protocols disappears completely. However, here we are faced with another problem - the dependence of the security protocol on a specific network technology. Indeed, different parts of a large composite network generally use different link protocols, so it is impossible to lay a secure channel through this heterogeneous environment using a single link-layer protocol.

Consider, for example, the Point-to-Point Tunneling Protocol (PPTP), which runs on link level. It is based on the PPP protocol, which is widely used in point-to-point connections, such as leased lines. The PPTP protocol not only provides security transparency for application-level applications and services, but is also independent of the network layer protocol used: in particular, the PPTP protocol can transport packets both in IP networks and in networks based on the IPX, DECnet protocols or NetBEUI. However, since PPP is not used on all networks (most local networks the Ethernet protocol operates at the data link level, and ATM and frame relay protocols at the global level), then PPTP cannot be considered a universal tool.

IPSec, which operates at the network layer, is a compromise option. On the one hand, it is transparent to applications, and on the other hand, it can work on almost all networks, since it is based on the widely used IP protocol: currently only 1% of computers in the world do not support IP at all, the remaining 99% use it either as a single protocol, or as one of several protocols.

DISTRIBUTION OF FUNCTIONS BETWEEN IPSEC PROTOCOLS

The core of IPSec consists of three protocols: the authentication protocol (Authenti-cation Header, AH), the encryption protocol (Encapsulation Security Payload, ESP) and the key exchange protocol (Internet Key Exchange, IKE). The functions of maintaining a secure channel are distributed among these protocols as follows:

• AH protocol guarantees data integrity and authenticity;
• The ESP protocol encrypts transmitted data, guaranteeing confidentiality, but it can also support authentication and data integrity;
• The IKE protocol solves the auxiliary task of automatically providing channel endpoints with the secret keys necessary for the operation of authentication and data encryption protocols.

As can be seen from the brief description of the functions, the capabilities of the AH and ESP protocols partially overlap. The AH protocol is responsible only for ensuring data integrity and authentication, while the ESP protocol is more powerful, since it can encrypt data, and in addition, perform the functions of the AH protocol (although, as we will see later, it provides authentication and integrity in a slightly reduced form ). The ESP protocol can support encryption and authentication/integrity functions in any combination, i.e., either both, authentication/integrity only, or encryption only.

To encrypt data in IPSec, any symmetric encryption algorithm that uses secret keys can be used. Ensuring data integrity and authentication is also based on one of the encryption techniques - encryption using a one-way function, also called a hash function or digest function.

This function, when applied to encrypted data, results in a digest value consisting of a fixed small number of bytes. The digest is sent in an IP packet along with the original message. The recipient, knowing which one-way encryption function was used to compose the digest, recalculates it using the original message. If the values ​​of the received and calculated digests are the same, this means that the contents of the packet were not subject to any changes during transmission. Knowing the digest does not make it possible to restore the original message and therefore cannot be used for protection, but it does allow you to check the integrity of the data.

The digest is a kind of checksum for the original message. However, there is also a significant difference. The use of a checksum is a means of verifying the integrity of messages transmitted over unreliable communication lines and is not intended to combat malicious activity. In fact, the presence of a checksum in the transmitted packet will not prevent an attacker from replacing the original message by adding a new checksum value to it. Unlike a checksum, a secret key is used when calculating the digest. If a one-way function with a parameter (the secret key) known only to the sender and recipient was used to obtain the digest, any modification to the original message would be immediately detected.

The separation of security functions between the two protocols AH and ESP is caused by the practice used in many countries to restrict the export and/or import of tools that ensure data confidentiality through encryption. Each of these two protocols can be used either independently or simultaneously with the other, so that in cases where encryption is due to current restrictions cannot be used, the system can only be supplied with the AH protocol. Naturally, protecting data only using the AH protocol will in many cases be insufficient, since the receiving side in this case will only be sure that the data was sent by exactly the node from which it was expected and arrived in the form in which it was received. sent. The AH protocol cannot protect against unauthorized viewing along the data path, since it does not encrypt it. To encrypt data, it is necessary to use the ESP protocol, which can also verify its integrity and authenticity.

SAFE ASSOCIATION

In order for the AH and ESP protocols to do their job of protecting the transmitted data, the IKE protocol establishes a logical connection between the two endpoints, which in IPSec standards is called a “Security Association” (SA). Establishing an SA begins with mutual authentication of the parties, because all security measures become meaningless if data is transmitted or received by the wrong person or from the wrong person. The SA parameters you select next determine which of the two protocols, AH or ESP, is used to protect data, what functions the security protocol performs: for example, only authentication and integrity checking or, in addition, protection against false replay. A very important parameter of a secure association is the so-called cryptographic material, i.e. the secret keys used in the operation of the AH and ESP protocols.

The IPSec system also allows for a manual method of establishing a secure association, in which the administrator configures each end node so that they maintain agreed upon association parameters, including secret keys.

The AH or ESP protocol already operates within the established logical connection SA, with its help the required protection of the transmitted data is carried out using the selected parameters.

The secure association settings must be acceptable to both endpoints of the secure channel. Therefore, when using the automatic SA establishment procedure, the IKE protocols running on different sides channel, choose parameters during the negotiation process, just as two modems determine the maximum acceptable exchange rate for both parties. For each task solved by the AH and ESP protocols, several authentication and encryption schemes are offered - this makes IPSec a very flexible tool. (Note that the choice of the digest function to solve the authentication problem does not in any way affect the choice of algorithm for data encryption.)

To ensure compatibility, the standard version of IPsec defines a certain mandatory “tool” set: in particular, one of the one-way encryption functions MD5 or SHA-1 can always be used for data authentication, and the encryption algorithms certainly include DES. At the same time, manufacturers of products that include IPSec are free to expand the protocol with other authentication and encryption algorithms, which they successfully do. For example, many IPSec implementations support the popular Triple DES encryption algorithm, as well as relatively new algorithms - Blowfish, Cast, CDMF, Idea, RC5.

IPSec standards allow gateways to use either one SA to carry traffic from all hosts communicating over the Internet, or to create an arbitrary number of SAs for this purpose, for example, one for each TCP connection. A secure SA is a unidirectional (simplex) logical connection in IPSec, so two SAs must be established for bidirectional communications.

TRANSPORT AND TUNNEL MODES

The AH and ESP protocols can protect data in two modes: transport and tunnel. In transport mode, the transmission of an IP packet through the network is carried out using the original header of this packet, and in tunnel mode, the original packet is placed in a new IP packet and data transmission across the network is carried out based on the header of the new IP packet. The use of one mode or another depends on the requirements for data protection, as well as on the role played in the network by the node that terminates the secure channel. Thus, a node can be a host (end node) or a gateway (intermediate node). Accordingly, there are three schemes for using IPSec: host-to-host, gateway-to-gateway, and host-to-gateway.

In the first scheme, a secure channel, or what is the same thing in this context, a secure association, is established between two end nodes of the network (see Figure 2). The IPSec protocol in this case runs on the end node and protects the data arriving at it. For the host-to-host scheme, the transport mode of protection is most often used, although the tunnel mode is also allowed.

In accordance with the second scheme, a secure channel is established between two intermediate nodes, the so-called Security Gateways (SG), each of which runs the IPSec protocol (see Figure 3). Secure communications can occur between any two endpoints connected to networks that are located behind security gateways. Endpoints are not required to support IPSec and transmit their traffic unprotected through trusted enterprise Intranets. Traffic directed to public network, passes through a security gateway, which provides its protection using IPSec, acting on its own behalf. Gateways can only use tunnel mode.