A method and device for configuring an IPSEC network

Abstract

The invention discloses a configuration method and device of an IPSEC network, and relates to the technical field of communication networks. The configuration method of the IPSEC network uses a method of filling IPSEC values ​​with an extended community attribute of BGP. Since the BGP protocol is established based on a TCP connection, and the TCP connection is reliable and can ensure the data sequence, the custom extended community attribute of BGP is adopted. The IPSEC Client extracts IPSEC parameter information according to the filling value of the first 6 bytes of the Update message, notifies the IPSEC module to automatically send down the corresponding IPSEC configuration parameters, and sends down the IPSEC policy enable of the interface, triggering the establishment of the IPSEC tunnel, so as to realize the automatic sending down of the IPSEC configuration of the CPE end, and the problem of packet loss during the SA aging process can be avoided by the filling value of the last 4 bytes of the Update message.

Description

Technical Field

[0001] The present invention relates to the technical field of communication networks, and in particular to a configuration method and device for an IPSEC network. Background Art

[0002] In SDWAN networks, in order to ensure the security of data transmission, IPSEC, that is, Internet Protocol security, is often used to encrypt data messages. The establishment of an IPSEC tunnel still requires manual delivery of IPSEC parameter configuration to the CPE. The establishment of an IPSEC tunnel involves two IKE negotiation stages. If any parameter is inconsistent at both ends of the IPSEC tunnel, that is, VCPE and CPE, the negotiation will fail in the first phase exchange process of IPSEC or the second phase exchange process of IKE. In order to prevent the negotiation failure of the exchange process, it is necessary to delete the IPSEC parameter configuration layer by layer and re-deliver the nested parameters.

[0003] However, when there are many IPSEC tunnels in the network, the configuration workload will be huge, the process will be cumbersome, time-consuming and labor-intensive. Moreover, after the IPSEC tunnel is built, the IPSEC SA will be renegotiated after reaching a certain traffic threshold or time threshold. In this process, one party may have updated the SA and used the new SA for encryption, but the other end still uses the old SA due to the delay of the renegotiated IPSEC SA message in the network, resulting in inconsistency between the SAs of the two parties and the inability to decrypt the message and cause it to be discarded. Summary of the invention

[0004] Technical issues solved

[0005] In view of the deficiencies in the prior art, the present invention provides a configuration method and device for an IPSEC network, which solves the problem that the IPSEC configuration at the CPE end cannot be automatically sent down and packets are lost during the SA aging process.

[0006] Technical Solution

[0007] To achieve the above object, the present invention is implemented by the following technical scheme: a configuration method of an IPSEC network, comprising the following steps:

[0008] The first step is that the server configures the IPSEC parameters and sends a BGP Update message to the IPSEC Client.

[0009] Step 2: Determine whether to enable the BGP custom extension function. If not, do not trigger the BGP module to send the Update message and manually send the IPSEC parameters.

[0010] If yes, IPSEC parameters are delivered and an IPSEC tunnel is established based on the first six bytes of the custom extended community attribute VALUE value in the BGP Update message;

[0011] Step 3: Based on the last four bytes of the custom extended community attribute VALUE value in the Update message, determine whether the new SPI value is consistent with the old SPI value. If they are consistent, the Server and Client use the new SPI to encrypt the data message.

[0012] Furthermore, in the second step, issuing IPSEC parameters according to the first six bytes of the VALUE value and establishing an IPSEC tunnel specifically includes the following steps:

[0013] S1. The server fills the corresponding tag value into the first six bytes of the VALUE field in the custom community attribute of the BGP Update message according to the IKE algorithm parameter combination of the two stages;

[0014] S2. The client receives the Update message, extracts the IPSEC parameter information according to the tag value in the BGP extended community attribute, and notifies the IPSEC module to issue the corresponding IPSEC configuration parameters and enable the IPSEC policy.

[0015] S3. Trigger the IPSEC module to conduct two-stage negotiation, i.e., establish an IPSEC tunnel.

[0016] Further, the two phases in S1 include a first phase IKE security protocol and a second phase IKE security protocol, and the first phase IKE security protocol and the second phase IKE security protocol both have different negotiation parameters;

[0017] The negotiation parameters in the first phase of the IKE security protocol include authentication algorithm type, DH group, encryption algorithm type, integrity algorithm type, random function algorithm type, SA life cycle, and IKE version;

[0018] The negotiation parameters in the second phase IKE security protocol include encapsulation mode, security protocol, authentication algorithm and encryption algorithm.

[0019] Furthermore, the number of parameter combinations preset in S1 is no more than 64, and the preset parameter combinations are uniformly marked with corresponding binary values.

[0020] Further, one of the preset parameter combinations is that the authentication algorithm type in the first phase negotiation parameters of IKE is md5, the DH Group group is group12, the encryption algorithm type is 3des, the integrity algorithm type is aes-xcbc-96, the random function algorithm is aes-xcbc-128, the SA life cycle is 36000s, and the IKE version is V1;

[0021] In the second phase negotiation parameters of IKE, the encapsulation mode is tunnel, the security protocol is ESP encapsulation, the ESP authentication algorithm is sha1, and the ESP encryption algorithm is 3des;

[0022] Mark the above combination as 000000.

[0023] Furthermore, the third step of solving the problem of packet loss when IPsec SA ages specifically includes the following steps:

[0024] S1, determine whether the IPSEC SA of the client side reaches 2 / 3 of the flow threshold or 2 / 3 of the time threshold;

[0025] If yes, IPSEC re-negotiation is initiated to negotiate a new SA, but the old SA is still used to encrypt the message;

[0026] S2. The client fills the negotiated SPI value into the last 4 bytes of the VALUE value in the Update message, and sends an Update message to the server.

[0027] S3. After receiving the Update message, the server determines whether the SPI carried in the message is consistent with the SPI of the other end in the newly created IPSECSA of the local end;

[0028] If yes, the server will fill the local SPI value into the last four bytes of the custom community attribute VALUE value in the Update message and send it to the client. At the same time, the server device uses the new SPI to encrypt the data message.

[0029] S4. After receiving the Update message from the Server, the Client uses the new SPI to encrypt the data message.

[0030] Furthermore, the user-defined extended community attribute is stored in a Path Attributes with a variable length, and the Path Attributes consists of three parts: Attr.TYPE, Attr.Length and Attr.Value;

[0031] The Attr.TYPE consists of two parts: Attr.Flags and Attr.Type Code.

[0032] Furthermore, the upper four bits of Attr.Flags are composed of O, T, P and E, the upper four bits are all set to 1, and the lower four bits are all set to 0 when sending and ignored when receiving.

[0033] Furthermore, the Attr.Length value is filled with 10.

[0034] A configuration device for an IPSEC network includes a parameter configuration module, a first execution module and a second execution module, wherein:

[0035] Parameter configuration module, used to configure IPSEC parameter information and send BGP Update message to IPSEC Client;

[0036] The first execution module is used to determine whether to enable the BGP custom extension function. If not, the BGP module is not triggered to send an Update message;

[0037] If yes, send IPSEC parameters and establish IPSEC tunnel according to the first six bytes of the custom extended community attribute VALUE value in the BGP Update message;

[0038] The second execution module is used to determine whether the new SPI value is consistent with the old SPI value according to the last four bytes of the custom extended community attribute VALUE value in the Update message. If they are consistent, the Server and the Client use the new SPI to encrypt the data message.

[0039] Beneficial Effects

[0040] The present invention has the following beneficial effects:

[0041] The method of using BGP's extended community attribute to fill in IPSEC values. Since the BGP protocol is established based on TCP connections, TCP connections are reliable and can guarantee data order, the custom extended community attributes of BGP are used. The IPSEC Client extracts the IPSEC parameter information based on the filling value of the first 6 bytes of the Update message, notifies the IPSEC module to automatically send down the corresponding IPSEC configuration parameters, and enables the IPSEC policy of the interface, triggering the establishment of the IPSEC tunnel, so as to realize the automatic sending of the IPSEC configuration on the CPE side, and the filling value of the last 4 bytes of the Update message can avoid the problem of packet loss during the SA aging process.

[0042] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A flowchart of automatic distribution of IPSEC configuration for the Client side of the present invention;

[0044] Figure 2 A flow chart of the present invention for preventing IPSEC SA from aging and packet loss;

[0045] Figure 3 This is a BGP Update message format diagram of the present invention;

[0046] Figure 4 It is a custom community attribute format diagram in BGP Update of the present invention;

[0047] Figure 5 This is a schematic diagram of setting the Attr.Flags field of the custom group attribute of the present invention;

[0048] Figure 6 This is a schematic diagram of filling the Attr.values ​​field of the custom group attribute of the present invention. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] In the description of the present invention, it should be understood that the terms "opening", "upper", "lower", "thickness", "top", "middle", "length", "inside", "all around" and the like indicating orientation or positional relationship are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the components or elements referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as limiting the present invention.

[0051] See also Figure 1-Figure 6 The embodiment of the present invention provides a technical solution: a configuration method of an IPSEC network, comprising the following steps:

[0052] The first step is that the server configures the IPSEC parameters and sends a BGP Update message to the IPSEC Client.

[0053] Step 2: Determine whether the BGP custom extension function is enabled. If not, do not trigger the BGP module to send the Update message.

[0054] If yes, IPSEC parameters are delivered and an IPSEC tunnel is established based on the first six bytes of the custom extended community attribute VALUE value in the BGP Update message;

[0055] Step 3: Based on the last four bytes of the custom extended community attribute VALUE value in the Update message, determine whether the new SPI value is consistent with the old SPI value. If they are consistent, the Server and Client use the new SPI to encrypt the data message.

[0056] Specifically, in the second step, sending IPSEC parameters according to the first six bytes of the VALUE value and establishing the IPSEC tunnel specifically includes the following steps:

[0057] S1. The server fills the corresponding tag value into the first six bytes of the VALUE field in the custom community attribute of the BGP Update message according to the IKE algorithm parameter combination of the two stages;

[0058] S2. The client receives the Update message, extracts the IPSEC parameter information according to the tag value in the BGP extended community attribute, and notifies the IPSEC module to issue the corresponding IPSEC configuration parameters and enable the IPSEC policy.

[0059] S3. Trigger the IPSEC module to conduct two-stage negotiation, i.e., establish an IPSEC tunnel.

[0060] In this implementation scheme, the server sends a BGP Update message to the IPSEC Client with the IPSEC configuration parameter information and the BGP custom extension function enabled. The IPSEC Client extracts the IPSEC parameter information based on the fill value of the first 6 bytes of the Update message, notifies the IPSEC module to automatically send the corresponding IPSEC configuration parameters, and sends the IPSEC policy enable of the interface to trigger the establishment of the IPSEC tunnel. In this way, there is no need to manually fill in the IPSEC parameters of the two negotiation stages of IPSEC, making the establishment of the IPSEC tunnel more efficient and convenient, thereby solving the problem of huge configuration workload, cumbersome process, time-consuming and labor-intensive.

[0061] Specifically, the two phases in S1 include a first phase IKE security protocol and a second phase IKE security protocol, and the first phase IKE security protocol and the second phase IKE security protocol both have different negotiation parameters;

[0062] The negotiation parameters in the first phase of the IKE security protocol include authentication algorithm type, DH group, encryption algorithm type, integrity algorithm type, random function algorithm type, SA life cycle, and IKE version;

[0063] The negotiation parameters in the second phase IKE security protocol include encapsulation mode, security protocol, authentication algorithm and encryption algorithm.

[0064] In this implementation scheme, if any parameter is inconsistent at the two ends (i.e., VCPE and CPE) of the IPSEC tunnel, the negotiation will fail in the first phase exchange process of IKE or the second phase exchange process of IKE. The first phase IKE security protocol (IKE proposal) includes: authentication algorithm type, DH group, encryption algorithm type, integrity algorithm type, random function algorithm type, SA life cycle, and IKE version; the second phase IKE security protocol (IPsec proposal) includes encapsulation mode (tunnel mode or ACL extraction), security protocol (ESP or AH), authentication algorithm and encryption algorithm. These parameters will be configured on the server side.

[0065] Specifically, the preset parameter combinations in S1 are no more than 64, and the preset parameter combinations are uniformly marked with corresponding binary values;

[0066] One of the preset parameter combinations is that the authentication algorithm type is md5, the DHGroup group is group12, the encryption algorithm type is 3des, the integrity algorithm type is aes-xcbc-96, the random function algorithm is aes-xcbc-128, the SA life cycle is 36000s, and the IKE version is V1 in the first phase negotiation parameters of IKE;

[0067] In the second phase negotiation parameters of IKE, the encapsulation mode is tunnel, the security protocol is ESP encapsulation, the ESP authentication algorithm is sha1, and the ESP encryption algorithm is 3des;

[0068] Mark the above combination as 000000.

[0069] In this implementation scheme, the server and the client pre-negotiate several commonly used IPSEC configuration parameter combinations, up to 2^6=64 types, and uniformly mark them with corresponding binary values, that is, the range 000000-111111. For example, in the first phase negotiation parameters of IKE, the authentication algorithm (authentication-algorithm) type is md5, the DH Group group is group12, the encryption algorithm (encryption-algorithm) type is 3des, the integrity algorithm (integrity-algorithm) type is aes-xcbc-96, the random function algorithm (prf) is aes-xcbc-128, the SA lifetime (duration) is 36000s, and the IKE version is V1; in the second phase negotiation parameters of IKE (IPsec proposal), the encapsulation mode is tunnel, the security protocol is ESP encapsulation, the ESP authentication algorithm is sha1, and the ESP encryption algorithm is 3des; the above combination is marked as 000000.

[0070] Specifically, solving the packet loss problem when IPsec SA ages in the third step specifically includes the following steps:

[0071] S1, determine whether the IPSEC SA of the client side reaches 2 / 3 of the flow threshold or 2 / 3 of the time threshold;

[0072] If yes, IPSEC re-negotiation is initiated to negotiate a new SA, but the old SA is still used to encrypt the message;

[0073] S2. The client fills the negotiated SPI value into the last 4 bytes of the VALUE value in the Update message, and sends an Update message to the server.

[0074] S3. After receiving the Update message, the server determines whether the SPI carried in the message is consistent with the SPI of the other end in the newly created IPSECSA of the local end;

[0075] If yes, the server will fill the local SPI value into the last four bytes of the custom community attribute VALUE value in the Update message and send it to the client. At the same time, the server device uses the new SPI to encrypt the data message.

[0076] S4. After receiving the Update message from the Server, the Client uses the new SPI to encrypt the data message.

[0077] In this implementation scheme, after the IPSEC tunnel is established, the SA of IPSEC will be renegotiated after reaching a certain traffic threshold or time threshold. In this process, one party may have updated the SA and used the new SA for encryption, but the other end still uses the old SA due to the delay of the renegotiated IPSEC SA message in the network, resulting in the SA of the two parties being inconsistent, and the message cannot be decrypted and discarded. Through the above steps, the client fills the negotiated SPI value into the last 4 bytes of the VALUE value in the Update message, and sends the Update message to the Server. When the SPI carried in the message is consistent with the SPI of the other end in the newly created IPSEC SA of the local end, the Server fills the local SPI value into the last four bytes of the custom group attribute VALUE value in the Update message and sends it to the Client. At the same time, the Server device uses the new SPI to encrypt the data message. After the Client receives the Update message sent by the Server, it uses the new SPI to encrypt the data message, thereby avoiding the problem of packet loss during SA aging.

[0078] Specifically, the user-defined extended community attribute is stored in Path Attributes of variable length, and the PathAttributes consists of three parts: Attr.TYPE, Attr.Length and Attr.Value;

[0079] The Attr.TYPE consists of two parts: Attr.Flags and Attr.Type Code;

[0080] The high four bits of Attr.Flags are composed of O, T, P and E, the high four bits are all set to 1, the low four bits are all set to 0 when sending and ignored when receiving;

[0081] The Attr.Length value is padded to 10.

[0082] In this implementation scheme, the fields of the BGP update message are as follows: Figure 3 As shown, octets represents an 8-bit barrier, and the custom extended community attributes are stored in the Path Attributes of variable length;

[0083] like Figure 4 As shown, Path Attributes consists of three parts: Attr.TYPE, Attr.Length and Attr.Value, where Attr.TYPE includes Attr.Flags and Attr.Type Code;

[0084] like Figure 5As shown, the upper 4 bits of Attr.Flags are composed of O, T, P, and E bits:

[0085] O: Optional bit, the optionality of the attribute, determines whether the attribute is a required attribute, and is set to 1 for custom extended attributes.

[0086] T: Transitive bit attribute transferability. When the automatic configuration is enabled, it is set to 1.

[0087] P: Partial bit attribute locality, set to 1,

[0088] E: Extended Length bit determines whether the attribute length field (i.e. Attr.Length) needs to be extended. Since the tag value is 6 bytes, the SPI value is 4 bytes, and the VALUE value required by the present invention is 10 bytes, it is set to 1.

[0089] U: Unused bits The lower 4 bits are not used, all set to 0 when sending and ignored when receiving;

[0090] The lower 4 bits are not used, all set to 0 when sending and ignored when receiving.

[0091] like Figure 6 , where the first 6 bytes of Attr.Value are used to transmit IPSEC parameter information. The last 4 bytes are used as the SPI value of the IPSEC SA negotiated by the local device. SPI stands for Security Parameter Index, which is a 32-bit security parameter index used to identify SAs with the same IP address and the same security protocol. Each pair of IPSEC tunnels will have a pair of SPIs. The local SPI of the local end is the same as the remote SPI of the other end, and the local SPI of the other end is the same as the remote SPI of the local end.

[0092] A configuration device for an IPSEC network includes a parameter configuration module, a first execution module and a second execution module, wherein:

[0093] Parameter configuration module, used to configure IPSEC parameter information and send BGP Update message to IPSEC Client;

[0094] The first execution module is used to determine whether to enable the BGP custom extension function. If not, the BGP module is not triggered to send an Update message;

[0095] If yes, IPSEC parameters are delivered and an IPSEC tunnel is established based on the first six bytes of the custom extended community attribute VALUE value in the BGP Update message;

[0096] The second execution module is used to determine whether the new SPI value is consistent with the old SPI value according to the last four bytes of the custom extended community attribute VALUE value in the Update message. If they are consistent, the Server and the Client use the new SPI to encrypt the data message.

[0097] In this implementation scheme, the parameter configuration module configures the IPSEC parameter information on the server side, and then the first execution module first determines whether to enable the BGP custom extension function. If not, the BGP module is not triggered to send the Update message, and the IPSEC parameters are manually issued; if so, the IPSEC parameters are issued and the IPSEC tunnel is established according to the first six bytes of the custom extended community attribute VALUE value of the BGP Update message, thereby solving the huge workload of manual configuration, the cumbersome process, and the time-consuming and labor-consuming process;

[0098] Finally, the second execution module solves the problem of packet loss when IPsec SA ages according to the last four bytes of the custom extended community attribute VALUE value in the Update message.

[0099] In SDWAN networks, IPSEC (Internet Protocol Security) is often used to encrypt data packets to ensure the security of data transmission. However, the establishment of IPSEC tunnels still requires manual delivery of IPSEC parameter configurations to CPE (traditional user-side equipment), which is a huge configuration workload, cumbersome process, time-consuming and labor-intensive. The method of using BGP's extended community attribute to fill in IPSEC values ​​can solve the problems of huge configuration workload, cumbersome process, time-consuming and labor-intensive.

[0100] The server and the client pre-negotiate several commonly used IPSEC configuration parameter combinations, up to 2^6=64, and uniformly mark them with corresponding binary values ​​(range 000000-111111). For example, in the first phase of IKE negotiation parameters, the authentication algorithm (authentication-algorithm) type is md5, the DH Group group is group12, the encryption algorithm (encryption-algorithm) type is 3des, the integrity algorithm (integrity-algorithm) type is aes-xcbc-96, the random function algorithm (prf) is aes-xcbc-128, the SA lifetime (duration) is 36000s, and the IKE version is V1; in the second phase of IKE negotiation parameters (IPsec proposal), the encapsulation mode is tunnel, the security protocol is ESP encapsulation, the ESP authentication algorithm is sha1, and the ESP encryption algorithm is 3des; mark the above combination as 000000;

[0101] like Figure 1 As shown, first confirm whether the switch of the BGP custom extended attribute IPSEC value is enabled. If it is not enabled, the BGP module will not be triggered to send the Update message, and the IPSEC parameters will not be manually sent. If the switch of the BGP custom extended attribute IPSEC value is enabled, the server will fill in the tag value corresponding to the IPSEC configuration parameter combination sent by the local end to the first 6 bytes of the VALUE value in the custom extended community attribute 1 of the BGP Update message. At this time, IPSEC negotiation is not performed, so the last 4 bytes are not filled in. The server sends a BGP Update message to the IPSEC Client. The IPSEC Client extracts the IPSEC parameter information according to the tag value of the Update message, notifies the IPSEC module to send the corresponding IPSEC configuration parameters, and enables the IPSEC policy of the interface, triggering the establishment of the IPSEC tunnel. In this system method device, there is no need to manually fill in the IPSEC parameters of the two negotiation stages of IPSEC, thereby making the establishment of the IPSEC tunnel more efficient and convenient;

[0102] like Figure 2 As shown in the figure, when the IPSEC SA of the client reaches 2 / 3 of the traffic threshold or 2 / 3 of the time threshold, it will actively initiate IPSEC re-negotiation to negotiate a new SA. At this stage, the old SA encryption message is still used; then the client fills the negotiated SPI value into the last 4 bytes of the VALUE value in the Update message, and sends an Update message to the Server. After receiving the Update message, the Server determines whether the SPI carried in the message is consistent with the SPI of the other end in the newly created IPSEC SA of the local end;

[0103] If they are consistent, the server fills the local SPI value into the last four bytes of the custom community attribute VALUE value in the Update message and sends it to the client. At the same time, the server device uses the new SPI to encrypt the data message. Finally, after the client receives the Update message sent by the server, it uses the new SPI to encrypt the data message, thereby solving the problem of packet loss when the IPsec SA ages.

[0104] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0105] The preferred embodiments of the present invention disclosed above are only used to help illustrate the present invention. The preferred embodiments do not describe all the details in detail, nor do they limit the invention to the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A configuration method for an IPSEC network, characterized in that: The following steps are involved: The first step is to configure IPSEC parameter information on the server side; Step 2: Determine whether the BGP custom extension function is enabled. If not, the BGP module will not be triggered to send Update messages. If yes, send a BGP Update message to the IPSEC Client, send IPSEC parameters according to the first six bytes of the custom extended community attribute VALUE value in the BGP Update message, and establish an IPSEC tunnel; Step 3: After receiving the Update message, the server determines whether the last four bytes of the custom extended community attribute VALUE in the Update message are consistent with the newly created SPI value of the server. If they are consistent, the server and client use the newly created SPI to encrypt the data message. The specific steps of the third step include: Determine whether the IPSEC SA on the client side reaches 2 / 3 of the traffic threshold or 2 / 3 of the time threshold; If yes, IPSEC re-negotiation is initiated to negotiate a new SA, but the old SA is still used to encrypt messages. The client fills the negotiated SPI value into the last 4 bytes of the custom extended community attribute VALUE value in the Update message, and sends an Update message to the server. After receiving the Update message, the server determines whether the SPI carried in the message is consistent with the SPI of the peer end in the newly created IPSEC SA of the local end; If yes, the server will fill the newly created SPI value into the last four bytes of the custom community attribute VALUE value in the Update message and send it to the client. At the same time, the server device will use the newly created SPI to encrypt the data message. After the Client receives the Update message sent by the Server, it uses the newly created SPI to encrypt the data message.

2. A method for configuring an IPSEC network according to claim 1, characterized in that: The second step specifically includes the following steps: issuing IPSEC parameters based on the first six bytes of the VALUE value and establishing an IPSEC tunnel: S1. The server fills the corresponding tag value into the first six bytes of the VALUE field in the custom community attribute of the BGP Update message according to the IKE algorithm parameter combination of the two stages; S2. The client receives the Update message, extracts the IPSEC parameter information according to the tag value in the BGP extended community attribute, and notifies the IPSEC module to issue the corresponding IPSEC configuration parameters and enable the IPSEC policy. S3. Trigger the IPSEC module to conduct two-stage negotiation, i.e., establish an IPSEC tunnel.

3. A method for configuring an IPSEC network according to claim 2, characterized in that: The two phases in S1 include a first phase IKE security protocol and a second phase IKE security protocol, and the first phase IKE security protocol and the second phase IKE security protocol both have different negotiation parameters; The negotiation parameters in the first phase of the IKE security protocol include authentication algorithm type, DH group, encryption algorithm type, integrity algorithm type, random function algorithm type, SA life cycle, and IKE version; The negotiation parameters in the second phase IKE security protocol include encapsulation mode, security protocol, authentication algorithm and encryption algorithm.

4. A method for configuring an IPSEC network according to claim 2, characterized in that: There are no more than 64 parameter combinations, and the parameter combinations are uniformly marked with corresponding binary values.

5. A method for configuring an IPSEC network according to claim 4, characterized in that: One of the parameter combinations is that in the first phase of IKE negotiation parameters, the authentication algorithm type is md5, the DH Group is group12, the encryption algorithm type is 3des, the integrity algorithm type is aes-xcbc-96, the random function algorithm is aes-xcbc-128, the SA lifetime is 36000s, and the IKE version is V1; In the second phase negotiation parameters of IKE, the encapsulation mode is tunnel, the security protocol is ESP encapsulation, the ESP authentication algorithm is sha1, and the ESP encryption algorithm is 3des; Mark the above combination as 000000.

6. The method for configuring an IPSEC network according to claim 1, characterized in that: The custom extended community attribute is stored in the length-variable Path Attributes, which consists of three parts: Attr.TYPE, Attr.Length and Attr.Value; The Attr.TYPE consists of two parts: Attr.Flags and Attr.Type Code.

7. A method for configuring an IPSEC network according to claim 6, characterized in that: The high four bits of Attr.Flags are composed of O, T, P and E. The high four bits are all set to 1, and the low four bits are all set to 0 when sending and ignored when receiving.

8. The method for configuring an IPSEC network according to claim 6, characterized in that: The Attr.Length value is padded to 10.

9. A configuration device for an IPSEC network, characterized in that: It includes a parameter configuration module, a first execution module and a second execution module, wherein: Parameter configuration module, used to configure IPSEC parameter information; The first execution module is used to determine whether to enable the BGP custom extension function. If not, the BGP module is not triggered to send an Update message; If yes, send a BGP Update message to the IPSEC Client, send IPSEC parameters according to the first six bytes of the custom extended community attribute VALUE value in the BGP Update message, and establish an IPSEC tunnel; The second execution module is used for the server to determine whether the last four bytes of the custom extended community attribute VALUE value in the Update message are consistent with the newly created SPI value of the server after receiving the Update message. If they are consistent, the server and the client use the newly created SPI to encrypt the data message, which specifically includes: Determine whether the IPSEC SA on the client side reaches 2 / 3 of the traffic threshold or 2 / 3 of the time threshold; If yes, IPSEC re-negotiation is initiated to negotiate a new SA, but the old SA is still used to encrypt messages. The client fills the negotiated SPI value into the last 4 bytes of the custom extended community attribute VALUE value in the Update message, and sends an Update message to the server. After receiving the Update message, the server determines whether the SPI carried in the message is consistent with the SPI of the peer end in the newly created IPSEC SA of the local end; If yes, the server will fill the newly created SPI value into the last four bytes of the custom community attribute VALUE value in the Update message and send it to the client. At the same time, the server device will use the newly created SPI to encrypt the data message. After the Client receives the Update message sent by the Server, it uses the newly created SPI to encrypt the data message.

Images