The package and unpacking process of ESP message in Web security--ipsec transmission mode

Introduction to Web Security

--the process of loading and unpacking ESP packets in IPSec transfer mode

One, IPsec

(a) introduction

Internet Security Protocol ( English:Internet Protocol Security, abbreviated to IPSEC), is to protect the IP Protocol's Network transport Protocol family (a collection of interrelated protocols) by encrypting and authenticating the IP Protocol (Internet Protocol) packet.

IPSec consists of two main parts: (1) Establishing a key exchange protocol for a secure packet stream, and (2) a protocol to protect packet flow. The former is the Internet Key Exchange (IKE) protocol. The latter includes encapsulated Security Payload Protocol (ESP protocol) or Authentication Header protocol (AH Protocol) protocol for encrypting packet Flow, which is used to guarantee data confidentiality, source reliability (authentication), no connectivity integrity, and provide anti-replay services.

(ii) design Intent

IPSec is designed to provide (1) ingress Security for Ingress communication, in which the security of packet communication is provided by a single node to multiple machines (or even the entire LAN), and (2) to the end-to-end packet traffic security, which is done by the computer as the endpoint. Any of these patterns can be used to build a virtual private network (VPN), which is one of the most important uses of IPSec . It should be noted that the above two modes of operation are very different in the implementation of security.

The development of Internet-wide end-to-end communication security is slower than expected, partly because it is not widespread or is not universally trusted. The public key infrastructure can be formed (DNSSEC was originally generated), partly because many users were unable to fully identify their needs and available options, causing them to be imposed as inclusions in the seller's products (which would also be widely adopted) Another part may be attributed to the degradation of the network response (or the expected degradation), just as the bandwidth loss caused by the flooding of the information is being sold.

(iii) comparison with other Internet protocols

The IPSec protocol works on the third layer of the OSI model , making it suitable for the protection of TCP or UDP-based protocols (such as Secure Sockets Layer (SSL), which cannot protect the traffic flow of the UDP layer) when used alone. This means that, compared to the transport layer or higher-level protocols, theIPSec protocol must handle the problem of reliability and fragmentation, which also increases its complexity and processing overhead. in contrast, SSL/TLS relies on higher-level TCP (the fourth layer of the OSI) to manage reliability and fragmentation.

Second, ESP

(i) Introduction to ESP and transmission modes

ESP(Encapsulating Security payloads), encapsulating the Security Payload Protocol, one of two types of protocols supported by IPSEC. This protocol can be used to measure data integrity, source authentication and encryption, as well as prevent replay attacks during data transmission.

Transport mode, two ways for IPSec to work with tunnel mode. Unlike tunnel mode, when IPSec is working in transmission mode, the new IP header is not generated, but instead the original IP header is used to protect only the actual transmitted data, not the entire IP message. In the processing method, the original IP message will be untied first, and then add a new ESP or AH protocol header in front of the data, and then replace the original IP header, that is, the original IP packet was modified and then transmitted.

(ii) ESP package in transfer mode

in transport mode, the ESP package has an approximate structure and detailed structure as follows:

      

(iii) ESP Package and unpacking process in transfer mode

1, packaging process:

The package process, which is the processing of out-of-office packets.

For transfer mode applications running on IPV4, the ESP header is inserted into an out-of-office IP packet immediately after the IP header, including any options that the IP header may have. The Protocol field of the IP header is copied to the "Next Header" field of the ESP header, and the rest of the fields of the ESP header are filled in the-spi field is assigned to the SPI of the specific SA from SADB, which is used to process the package; the Fill Sequence Number field is the next value in the sequence, and the fill data is inserted. Its value is assigned, and the padding length value is also assigned. Subsequently, the IP header's protocol field gets the value of ESP, or 50. In addition to the header insertion position, the IPv6 processing rule is essentially similar to IPV4. The ESP header can be inserted after any one of the expansion headers (which may be modified during routing).

Select the dongle (encryption algorithm) from the appropriate SA to encrypt the package (from the beginning of the load data to the "Next Header" field). The package is then validated with the authenticator in the appropriate SA (from the beginning of the ESP header to the encrypted ciphertext in the middle, up to the end of the ESP). The result of the validator is then inserted in the Validation data field at the end of the ESP. The last step in processing an out-of-office packet is to recalculate the checksum of the IP header in front of the esp.

In transport mode, when you want to emit a packet:

1. Add the trailing (ESP trailer) information at the end of the original IP message. As shown, the trailer contains three parts. By the selected encryption algorithm may be block encryption, then when the last piece length is not enough to fill (padding), with the padding length (PAD length) to facilitate the solution of the package to find the piece of data to fill. The next header is used to indicate the type of data message being encrypted, such as TCP.

2, the original IP packet and the 1th step to get the ESP tail as a whole to encrypt. Specific cryptographic algorithms and keys are given by SA.

3. Add the ESP header for the encrypted data obtained in step 2nd.

The ESP header consists of two parts, SPI and serial number (Sequence numbers). Encrypted data is called "Enchilada" with ESP header.

4. Additional Integrity measurement results (icv,integrity check value).

A summary of the "enchilada" obtained in the third step is obtained, and an integrity metric is appended to the end of the ESP message.

5, get the original IP header. So you can send it.

2, unpacking process.

The unpacking process, which is the processing of the received packets.

After receiving an ESP packet, if the packet is not processed, it will not know whether it is in the channel mode or the transfer mode. Depending on the SA that handles this package, you know exactly what mode it is in.

If the received IPSec packet is a fragment, it must be preserved until the rest of the package is finished.

We cannot process an incomplete IPSec package because it may result in a failure to perform the initial school check.

After receiving the ESP package, the first thing to do is to check if the SA that handles this package exists, which is the basic IPSec requirement, not ESP proprietary. If there is no SA, the package will be discarded. Input processing can begin only if the SA exists. Once the validation has passed a valid SA, it can be used to start the processing of the package.

First check the serial number. If the serial number of this package is valid-that is, it is not a duplicate (replay) package, nor does it appear to the right of the serial number window contained in s A-it begins processing. Because the E S P authentication cipher is not plaintext, the next step is to authenticate the package. With the appropriate key, pass the complete ESP package (except for the authentication data, of course) to the authenticator (which is taken from SA). If the result can match the data contained in the Authentication data field (taking into account any fragmentation that the authentication algorithm might require), the package can be authenticated. Next is decryption. The ESP packet can be decrypted by the key and password algorithm taken from the SA, which is between the start of the load data and the next one. One of the simplest tests to determine the decryption success is to check its padding. Because the padding content has a decisive meaning-either a one-way increment from 1, or an encryption algorithm-the validation of the padding will determine if the package has been successfully decrypted.

After a successful transfer of authentication and decryption checks, a preliminary validation of the resulting packet can be performed. If the SA used to process this packet indicates that in a particular mode-either channel mode or transfer mode-only the ESP package can be processed, then the applicability of the package must also be verified. If the package does not match the required pattern, it must be discarded.

For the transfer mode, the upper layer protocol header is synchronized with the IP header, the next header field of the ESP header is copied to the IP header's protocol field, and a new IP checksum is computed, while for the channel mode, the external IP header and the ESP header are thrown away-what we need is this unpacked package. At this point, another validity test must be performed.

If it is a delivery mode packet, it is transferred to a high level protocol layer-for example, TCP or udp-, which handles the packet.

The unpacking process is as follows:

1. After receiving the data message, it is found that the protocol type is 50, so we know that this is an IPSec package. First, look at the ESP header, which determines the SA corresponding to the data message via the SPI inside.

2. Calculate the summary of the "Enchilada" section, and compare it with the ICV at the end, if the same is true for the data. Otherwise it can be concluded that the received message is not the original message.

3. Check the SEQ sequence number to ensure that the data is "fresh".

4. Decrypt the encrypted data, or "enchilada", according to the encryption algorithm and key provided by SA. Get the original IP packet with the ESP tail (trailer).

5. Depending on the length of the fill in the ESP's tail, we can find out the length of the fill field and get the original IP message when we delete it.

6. Finally transfer to a high level protocol layer-such as TCP or udp--by which they handle the packet.

(iv) Expansion: ESP package and unpacking process in transfer mode

Packaging Process:

1. Add the trailing (ESP trailer) information at the end of the original IP message. As shown, the trailer contains three parts. By the selected encryption algorithm may be block encryption, then when the last piece length is not enough to fill (padding), with the padding length (PAD length) to facilitate the solution of the package to find the piece of data to fill. The next header is used to indicate the type of data message being encrypted, such as TCP.

2. Encrypt the original IP packet as well as the ESP tail obtained in step 1th as a whole. Specific cryptographic algorithms and keys are given by SA.

3. Add the ESP header for the encrypted data obtained in step 2nd. As shown, the ESP header consists of two parts, SPI and ordinal (Sequence number). Encrypted data is called "Enchilada" with ESP header.

4. Additional Integrity measurement results (icv,integrity check value). A summary of the "enchilada" obtained in the third step, with an integrity metric attached to the ESP message

The tail.
5. Add the new IP header. The newly constructed IP header is attached to the front of the ESP message to form a new IP message. Note that the destination address for this new IP header can be different from the source address. The protocol type is 50, indicating that it contains an IPSec message.

Unpacking process:

1. When the receiving party receives the data message, it discovers that the protocol type is 50, so it knows that this is an IPSec package. First, look at the ESP header, which determines the SA corresponding to the data message via the SPI inside.

2. Calculate the summary of the "Enchilada" section, and compare it with the ICV at the end, if the same is true for the data. Otherwise it can be concluded that the received message is not the original message.

3. Check the SEQ sequence number to ensure that the data is "fresh".

4. Decrypt the encrypted data, or "enchilada", according to the encryption algorithm and key provided by SA. Get the original IP packet with the ESP tail (trailer).

5. Depending on the length of the fill in the ESP's tail, we can find out the length of the fill field and get the original IP message when we delete it.

6. Finally, according to the original IP packet to the destination address to be forwarded.

Resources:

#传输模式下ESP的装包和拆包过程 #

Http://blog.sina.com.cn/s/blog_64ffd1280101egtj.html

Package and unpacking process for ESP messages in #IPSec传输模式/tunnel mode #

http://blog.csdn.net/johnson_puning/article/details/14163751

#IPsec #

Http://zh.wikipedia.org/wiki/IPsec

The package and unpacking process of ESP message in Web security--ipsec transmission mode