CN106209897A - A kind of software defined network distributed many Task-size Controlling device safety communicating method based on agency - Google Patents

Abstract

The invention relates to an agent-based software-defined network distributed multi-granularity controller security communication method, which belongs to the technical field of inter-domain communication security of a multi-domain SDN network. In this method, by designing a distributed multi-granularity security controller architecture, including the message packet format between the controllers, using the connection between the controller domain and the inter-domain agent, and the connection between the inter-domain agents to establish a communication tunnel, the communication between the controllers is completed. Neighbor discovery, two-step authentication, and encrypted transmission among multi-domain network controllers to achieve direct communication. In this communication method, the infrastructure is based on the security controller and the inter-domain agent, and the inter-domain agent sends the message of the control plane to the data plane for transmission, which solves the communication problem between independent control planes; at the same time, based on the challenge response mechanism The DTLS protocol provides a two-step authentication scheme for controller communication, which can prevent denial of service supply and complete identity authentication, improving security.

Description

An agent-based software-defined network distributed multi-granularity controller security communication method

technical field

The invention belongs to the technical field of inter-domain communication security of a multi-domain SDN network, and relates to an agent-based software-defined network distributed multi-granularity controller security communication method.

Background technique

In recent years, more and more researchers have begun to address the problems in the large-scale deployment of SDN, including the cooperation of multiple controllers in the control plane, the division of controller management areas, and load balancing. In the case of multiple SDN autonomous domains, the routing problem between autonomous domains is also of particular concern.

In terms of the expansion of the intra-domain control plane, there are research results such as DIFANE, DevoFlow, HyperFlow, and Onix. Aiming at the performance bottleneck of the controller in real-time flow table processing, DIFANE uses active and passive simultaneous methods to add flow tables to the switch. In DIFANE, some switches can have certain flow table management power, called authoritative switches. Switches in the same area as the authoritative switch can request flow tables from it. Since the high-priority flow tables issued by the controller are stored in the cache of the authoritative switch, it can share the processing pressure for the controller. DIFANE's switch area division is based on the data flow address, protocol, port and other information to classify, and then form the flow space. DevoFlow takes into account the bandwidth consumption between the controller and the switch, uses a flow table with a special mark to wildcard a class of traffic, and subdivides the flow table entries for the traffic in the switch. And it is possible to set multiple outbound ports for the wildcard flow entry, and implement multi-path routing according to the probability distribution forwarding.

HyperFlow and Onix solve the insurmountable performance constraints of single-point controllers from the perspective of multi-controller distributed control. HyperFlow divides switches into different controllers for management, and the controllers share network topology information. The information sharing between controllers adopts the method of publishing irregularly, and the messages are sent through different channels. The update of information is implemented in the form of distributed file system WheelFS. However, HyperFlow can only achieve some infrequent information sharing that does not require high real-time performance. Onix has designed an SDN architecture based on distributed control, which mainly uses distributed hash table technology as the basis for network information sharing and synchronization, and then uses a reliable distribution mechanism to achieve rapid response synchronization control.

The document Virtual routers as a service: the RouteFlow approach leveraging software-defined networks proposes RouteFlow: a routing architecture in SDN. RouteFlow converts physical switches into virtual switches in the controller, maintains a virtual topology, and uses open source routing software to implement routing calculations. The document OFBGP: A Scalable, Highly Available BGP Architecture for SDN proposes OFBGP, a BGP architecture with strong scalability and high availability in SD networks. OFBGP is divided into a BGP protocol module and a BGP decision module. As an application of the control plane, it manages and controls intra-domain and inter-domain routing, and realizes rapid recovery of routing failures through backup.

The document WEBridge: west–east bridge for distributed heterogeneous SDN NOSespeering conducts a detailed study on the inter-domain interconnection mechanism of SDN, proposes an east-west bridging scheme for heterogeneous NOS in SDN, and designs the information that needs to be exchanged. In this scheme, the inter-domain controller adopts a point-to-point communication method, and besides exchanging routing information, it also shares the network view (topology) with other autonomous domains to form a global view. DISCO proposed in the document DISCO: Distributed Multi-domain SDN Controllers also simply designs the east-west interaction mechanism of controllers to realize the collaboration between multi-domain controllers.

In the multi-controller SDN scenario, many single-domain distributed control solutions have emerged and are relatively mature. In terms of inter-domain interconnection, there have been some research results on inter-domain routing and control plane communication. Due to the characteristics of SDN, inter-domain interconnection is basically realized through the east-west communication of controllers, but the communication method and security between controllers have not received much attention. Inter-domain security is a key issue in the large-scale deployment of SDN networks, so it is very necessary to build secure communication between inter-domain distributed controllers.

Contents of the invention

In view of this, the object of the present invention is to provide an agent-based software-defined network distributed multi-granularity controller security communication method, design a distributed multi-granularity security controller architecture, including the message packet format between the controllers, use The connection between the controller domain and the inter-domain agent, and the connection between the inter-domain agents establish a communication tunnel, complete neighbor discovery between controllers, two-step identity authentication and encrypted transmission to realize direct communication between multi-domain network controllers.

To achieve the above object, the present invention provides the following technical solutions:

An agent-based software-defined network distributed multi-granularity controller security communication method, the method includes the following steps:

S1: Design and build a distributed multi-granularity controller architecture to enable each SDN autonomous domain to achieve the purpose of inter-domain communication; the architecture is divided into a basic control block, a multi-granularity security customization module, and an enhanced security controller. The basic control module follows The SDN architecture requires the realization of basic functions. The multi-granularity security customization module realizes the security functions that can be customized in the controller, and the enhanced security controller is to solve the security problem between domains in the SDN multi-network environment;

S2: Under the architecture mode of step S1, the message format in the secure communication method is designed, and the data transmission between all controllers adopts the dedicated Ethernet data packet type identifier 0xEFEF, and the payload part retains the IP data packet format, while the transport layer adopts UDP protocol;

S3: Neighbor discovery for secure connection establishment. Neighbor discovery adopts a broadcast discovery method. The controller of each autonomous domain broadcasts its own information through the inter-domain agent; The information such as the service port number is sent to the inter-domain agent, and the inter-domain agent encapsulates it into an Ethernet packet and forwards it to the adjacent autonomous domain, customizing the format of the neighbor discovery message;

S4: Trustworthy authentication for the establishment of a secure connection. When inter-domain controllers communicate, it is necessary to ensure the communication security between the controller and the inter-domain agent and between the inter-domain agents. Therefore, the identity authentication between the controllers must be completed. Both controllers It is necessary to clarify whether the other party is trustworthy, so two-step authentication is adopted, which includes inter-domain proxy authentication and certificate authentication;

S5: The tunnel establishment of the secure connection establishment. During the operation of the SDN multi-domain network, the controllers of each autonomous domain continuously broadcast their own information. After the controllers of other autonomous domains receive the broadcast message, the controller that wants to send the message initiates a connection.

Further, in step S1, the SDN security controller architecture is divided into a basic control module and a multi-granularity security customization module. The multi-granularity security customization module implements customizable security functions in the controller, mainly including a threat defense module and a flow table management module. , backup module and application management module; enhanced security controller architecture, its inter-domain module mainly includes security configuration, connection management, neighborhood management and inter-domain routing.

Further, in step S2, the packet format of the inter-domain message of the controller is as follows: the first 8 bits are the type of the message, and then 32 bits are the length of the message (the whole UDP load part, and the bits are bytes), and the remaining parts are specific message content; the message types are divided into neighbor discovery messages, keepalive messages, and secure tunnel messages, and their type identifiers are: 0x01, 0x02, and 0x03.

Further, in step S3, the controller sends information such as the AS number of the autonomous domain, whether it supports a secure tunnel, and the service port number of the secure tunnel to the inter-domain agent, and the inter-domain agent encapsulates it into an Ethernet packet and forwards it to the adjacent autonomous domain. domain, the format of the neighbor discovery message is customized as follows:

The message type field is 0x01, and the message length is generally 10 bytes, that is, 0x000A; the following fields are AS number (32 bits), security tunnel support (8 bits, 0x00 means not supported, 0x01 means supported), port number (16 bits) , ignore this field if it means not supported);

After the neighbor discovery is completed, the controller continuously updates and maintains the information of the adjacent autonomous domain. If it does not receive a message from the adjacent autonomous domain for a long time (Message Timeout), it needs to send a Keepalive message to confirm whether the neighbor still exists; The controller in the neighboring autonomous domain will return a Keepalive message after receiving the message. If it does not receive the returned message within a certain period of time (Keepalive Timeout), it is considered that the neighbor no longer exists; the Message Timeout and Keepalive Timeout are determined by each autonomous domain according to the situation. Set by yourself; the message type field of Keepalive is 0x02, and the message length is generally 3 bytes, that is, 0x0003.

Further, in step S4, the authentication process of the two-step authentication includes: after the inter-domain agent receives the handshake message from the controller that initiates the request, it will not forward it to the controller of the autonomous domain at the first time, but First cache it; then the inter-domain agent initiates an authentication request to the requester to verify the non-attack intention of the requester; after the requester controller completes the answer and passes the verification, the inter-domain agent begins to forward the data packet to the autonomous domain controller Then, the handshake process is carried out to complete the identity authentication based on the certificate; in the DTLS protocol handshake process, both controllers need to know whether the other party is trustworthy, so strict two-way authentication is adopted.

Further, in step S5, the secure communication tunnel establishment process specifically includes:

S51: The controller constructs a neighbor discovery data packet, writes its own AS number, security tunnel support and service port into the data packet, then sends the data packet to all inter-domain agents, and the inter-domain agent encapsulates it as a type identifier The Ethernet frame of 0xEFEF is forwarded;

S52: After receiving the broadcast, the controller analyzes the AS number of the adjacent autonomous domain and the support of the security tunnel according to the broadcast message of the other party; if the other party does not support the security tunnel, it uses the normal UDP data transmission method according to the security configuration to send the data that is allowed to be shared. information; connection initiation can be initiated by any party, if no connection request from the other party is received, a secure tunnel handshake message is constructed, and the client initiates a secure tunnel connection request to the other party;

S53: After the other party receives the secure tunnel handshake message as the server, it will no longer initiate requests to the other party as the client; both parties complete two-step identity verification and encryption negotiation based on inter-domain proxy authentication and digital certificates, and when both parties confirm the identity of the other party , the secure communication tunnel is established, otherwise the tunnel establishment fails, and the normal UDP protocol is used instead;

S54: From the time when the controller receives the broadcast message from the neighboring autonomous domain controller, the message timeout message Timeout will be turned on (that is, no message from the neighbor has been received for a long time); after the timeout, the Keepalive message is sent to the other party, if the other party If the Keepalive message is not returned within the Keepalive Timeout time limit, it is considered that the other party does not exist and stops maintaining the secure tunnel.

The beneficial effect of the present invention is that: the present invention designs a secure communication method between distributed multi-granularity controllers. It is sent to the data plane for transmission, which solves the communication problem between independent control planes. At the same time, based on the challenge response mechanism and DTLS protocol, a two-step authentication scheme for controller communication is given, which can prevent denial of service supply and complete identity authentication, improving security.

Description of drawings

In order to make the purpose, technical scheme and beneficial effect of the present invention clearer, the present invention provides the following drawings for illustration:

Fig. 1 is the macro-flow chart of scheme of the present invention;

Figure 2 is the distributed controller communication architecture;

Figure 3 is an enhanced security controller;

Figure 4 is the granularity division of inter-domain security services;

Fig. 5 is the controller inter-domain data packet format;

Fig. 6 is a neighbor discovery message format;

Figure 7 is the Keepalive message format;

Figure 8 is a two-step authentication flow chart;

FIG. 9 is a flow chart of the process of establishing a secure tunnel.

detailed description

The preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

Fig. 1 is the macro-flow chart of the scheme of the present invention, as shown in the figure, the distributed multi-granularity controller security communication method of the present invention mainly includes the following four steps using the border switch as an inter-domain agent: Step 1: Design and build a distributed multi-granularity controller architecture composed of basic control blocks, multi-granularity security customization modules and an enhanced security controller, so that each SDN autonomous domain can achieve the purpose of inter-domain communication; Step 2: In the architecture of Step 1 In this mode, the message format in the secure communication method is designed, and the data transmission between all controllers adopts the dedicated Ethernet data packet type identifier 0xEFEF, the payload part retains the IP data packet format, and the transport layer adopts the UDP protocol; Step 3: Security Neighbor discovery after connection establishment, the controller sends information such as the AS number of the autonomous domain, whether it supports a secure tunnel, and the service port number of the secure tunnel to the inter-domain agent, and the inter-domain agent encapsulates it into an Ethernet packet and forwards it to the adjacent autonomous domain , customized the format of the neighbor discovery message; Step 4: Trustworthy authentication for secure connection establishment: When inter-domain controllers communicate, both controllers need to know whether the other party is trustworthy, so two-way authentication is used; Step 5: Secure connection establishment The tunnel is established. During the operation of the SDN multi-domain network, the controllers of each autonomous domain continuously broadcast their own information. After the controllers of other autonomous domains receive the broadcast message, the controller that wants to send the message initiates a connection.

Figure 2 shows the communication architecture of distributed controllers. The SDN multi-domain architecture adopts software boundary routing in the interconnection mode, and uses it as an application program in the control plane. The OpenFlow border switch connecting the two SDN autonomous domains acts as an inter-domain agent, and forms a secure communication tunnel between controllers in different autonomous domains through the establishment of connections from the controller to the border switch and between border switches.

According to the requirements of controller interconnection in the SDN multi-domain network, the inter-domain module is added on the basis of the security controller architecture, and the enhanced security controller architecture is constructed. The inter-domain module mainly includes security configuration, connection management, neighborhood management and inter-domain routing. Its basic structure is shown in Figure 3. Figure 4 shows the granularity division of inter-domain security services.

In the architecture mode of step 1, the message format in the secure communication method is designed, and the data transmission between all controllers adopts the dedicated Ethernet data packet type identifier 0xEFEF, the payload part retains the IP data packet format, and the transport layer adopts the UDP protocol . The format of the data packet between the controller domains is shown in Figure 5: the first 8 bits are the type of the message, the next 32 bits are the length of the message (the whole UDP payload part, the bits are bytes), and the rest are the specific message content. Message types are divided into neighbor discovery messages, keepalive messages, and secure tunnel messages, and their type identifiers are: 0x01, 0x02, and 0x03.

In the secure communication method of the controller, the establishment of the secure connection goes through three steps: neighbor discovery, trusted authentication and tunnel establishment.

First, after the controller broadcasts information to the neighbors, any party initiates a secure tunnel connection, and a secure communication tunnel is established after the identity verification of both parties is completed. Neighbor discovery adopts the broadcast discovery method. The controller of each autonomous domain broadcasts its own information through the inter-domain agent; The inter-domain agent encapsulates the Ethernet data packet and forwards it to the adjacent autonomous domain. The format of the neighbor discovery message is customized as shown in Figure 6: the message type field is 0x01, and the message length is generally 10 bytes (that is, 0x000A ). The following fields are AS number (32 bits), security tunnel support (8 bits, 0x00 means not supported, 0x01 means supported), port number (16 bits, ignore this field if it means not supported). After the neighbor discovery is completed, the controller continuously updates and maintains the information of the adjacent autonomous domain. If it does not receive the message from the adjacent autonomous domain for a long time (Message Timeout), it needs to send a Keepalive message to confirm whether the neighbor still exists. The controllers in the adjacent autonomous domains also return a Keepalive message after receiving the message, and if they do not receive the returned message within a certain period of time (Keepalive Timeout), it is considered that the neighbor no longer exists. Message Timeout and Keepalive Timeout are set by each autonomous domain according to the situation. The Keepalive message only contains message type and length fields, and the message format is shown in Figure 7.

The second is trusted authentication. In the inter-domain communication architecture of the present invention, a two-step authentication protocol is provided based on the Client Puzzle idea and DTLS to complete identity authentication and encrypted transmission between controllers. When inter-domain controllers communicate, it is necessary to ensure the security of the communication between the controller and the inter-domain agent and between the inter-domain agents. Therefore, the identity authentication between the controllers must be completed. Both controllers need to know whether the other party is trustworthy, so use Two-step authentication. Two-step authentication includes inter-domain proxy authentication and certificate authentication. After the inter-domain agent receives the handshake message from the controller that initiates the request, it will not forward it to the controller in the autonomous domain at the first time, but cache it first. Then the inter-domain proxy initiates an authentication request to the requester to verify the non-attack intention of the requester. After the requesting controller completes the answer and passes the verification, the inter-domain agent starts to forward the data packet to the autonomous domain controller, and then performs the handshake process to complete the certificate-based identity authentication. In the handshake process of the DTLS protocol, generally only the identity verification is performed on the server, but in the framework of the present invention, both controllers need to know whether the other party is trustworthy, so strict two-way authentication is adopted. The authentication process is shown in Figure 8.

Inter-domain proxy authentication mainly relies on three key questions: random number R, difficulty coefficient D, and answer A. Therefore, the authentication scheme in this paper is mainly aimed at the generation of random number R and the correctness verification of answer A.

This scheme generates a random number R through a single-item hash function. Since the security of MD5 and SHA-1 is increasingly challenged, the present invention adopts the SHA-256 algorithm. The generation of the random number depends on the AS number AS _I and the physical address of the network card MAC _I of the autonomous domain where the requesting inter-domain agent is located, the AS number AS _R and the physical address of the network card MAC _R of the receiver, and a random number M.

R＝SHA-256(MAC _I ||MAC _R ||AS _I ||AS _R ||M) (1)

The way for the responding party to solve the authentication request is to use the solving function to repeatedly try. The solving function uses the SHA-1 algorithm to continuously try to get the correct answer A according to the difficulty coefficient D, the random number R, and the AS numbers of both parties (AS _I , AS _R ).

Psolve(SHA-1(R||AS _I ||AS _R ||A), D)＝0 (2)

For the verification of the authentication solution, first confirm whether the random number R is consistent, if not, it indicates that it is not a response to the corresponding request, and then verify the correctness of the solution A according to the solution algorithm.

The steps for the supplicant to generate an authentication request are as follows:

1) Generate difficulty coefficient D;

2) Extract the answering party AS number AS _R from the neighbor list, and generate a random number M;

3) Calculate the random number R according to formula 1;

4) Fill R and D into the authentication request message and send it to the responding party.

The steps to answer a certification request are as follows:

1) extract the random number R and the difficulty coefficient D in the request message;

2) According to the solution function (formula 2), exhaustively enumerate the answers A that meet the requirements;

3) Fill R, D, and A into the authentication response message and send it back to the requesting party.

The process for validating a certification answer is as follows:

1) extract the random number R, difficulty coefficient D and answer A in the response message;

2) Verify that the random number R is consistent with the one sent, if not, ignore the response, otherwise continue;

3) Verify the correctness of answer A according to formula 2.

In the communication process between controllers, the security of the controller mainly depends on the two-step authentication scheme, and the attack on the controller is defended through the two-step authentication. For the convenience of analysis, the two stages of the authentication method are respectively denoted by δ and To represent. δ is inter-domain proxy authentication, for certificate authentication.

The process of authentication protocol δ is described as follows:

1) Connection request: C _I sends a connection establishment request to C _R.

2) Authentication request: A _R generates a random number M after receiving the request and calculates R=SHA-256(MAC _I ||MAC _R ||AS _I ||AS _R ||M), and sends a message according to the difficulty D (R, D) to C _I .

3) Authentication response: C _I calculates the solution A to satisfy Psolve(SHA-1(R||AS _I ||AS _R ||A), D)=0, and sends a message (R, D, A) to A _R.

4) Credible verification: AR verifies the consistency of _R and D and the correctness of A.

authentication protocol The process is described as follows:

1) Certificate transmission: C _R sends digital certificate Cert _R =(Info _R ||Sign _R ), Sign _R =Enc(SHA(Info _R ), PriK _R ) to C _I.

2) Identity verification: C _I requests the public key PubK _R from CA _R , and verifies whether the decrypted signature Dec(Sign _R , PubK _R ) is the same as the certificate hash SHA(Info _R ).

3) Certificate transmission: C _I sends digital certificate Cert _I =(Info _I ||Sign _I ), Sign _I =Enc(SHA(Info _I ), PriK _I ) to C _R.

4) Identity verification: C _R requests the public key PubK _I from CA _I , and verifies whether the decrypted signature Dec(Sign _I , PubK _I ) and the certificate hash SHA(Info _I ) are the same.

In the protocol δ, the input to generate the random number R is the result of the connection operation of AS _I , MAC _I , AS _R , MAC _R and the random number M. Assume that in the IPv4 environment, AS _I , MAC _I , AS _R , and MAC _R are all 32 bits, and M is a variable random N-bit bit string. Then the binary length of (MAC _I ||MAC _R ||AS _I ||AS _R ||M) is 2×32+2×48+N=160+N bits. The value of ^A has 2D possibilities, so the attacker only has ^2D-(160+N) probability of success when using random cracking. At the same time, according to the current security analysis of SHA-256, it is very difficult to complete the collision attack. Therefore, δ meets the security requirements.

in agreement Among them, the reliability of Cert depends on the confidentiality of the CA private key PriK and the encrypted signature Sign. Since Sign is based on asymmetric encryption, PubK can be used to decrypt Sign without PriK being public. After the content of the attacker's certificate is maliciously modified, the SHA(Info) changes, and the result of Dec(Sign, PubK) cannot match the SHA(Info). Therefore, when PriK is kept strictly confidential, The reliability is very high.

In summary, the anti-attack capability of protocol δ and the protocol The reliability not only guarantees the effectiveness of the two-step authentication method, but also ensures the security of the method.

The last is the establishment of the tunnel. During the operation of the SDN multi-domain network, the controllers of each autonomous domain continuously broadcast their own information. After the controllers of other autonomous domains receive the broadcast message, the controller that wants to send the message initiates a connection. The process of establishing a secure communication tunnel includes:

1) The controller constructs a neighbor discovery data packet, writes its own AS number, security tunnel support and service port into the data packet, then sends the data packet to all inter-domain agents, and the inter-domain agent encapsulates it as a type identifier Ethernet frame with 0xEFEF and forwarded.

2) After receiving the broadcast, the controller analyzes the AS number of the adjacent autonomous domain and the security tunnel support situation according to the broadcast message of the other party. If the other party does not support the security tunnel, the common UDP data transmission method will be used to send the information that is allowed to be shared according to the security configuration. Connection initiation can be initiated by any party. If no connection request is received from the other party, a secure tunnel handshake message will be constructed, and the client will initiate a secure tunnel connection request to the other party.

3) After receiving the secure tunnel handshake message as the server, the other party no longer initiates requests to the other party as the client. The two parties complete two-step identity verification and encryption negotiation based on inter-domain proxy authentication and digital certificates. When both parties confirm the identity of the other party, the secure communication tunnel is established. Otherwise, the tunnel establishment fails and the ordinary UDP protocol is used instead.

4) When the slave controller receives the broadcast message from the adjacent autonomous domain controller, it will start the message timeout MessageTimeout (that is, it has not received any message from the neighbor for a long time). After the timeout, send a Keepalive message to the other party. If the other party does not return a Keepalive message within the Keepalive Timeout time limit, it will consider that the other party does not exist and stop maintaining the secure tunnel.

The establishment process of the secure tunnel is shown in FIG. 9 .

Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that it can be described in terms of form and Various changes may be made in the details without departing from the scope of the invention defined by the claims.

Claims (6)

1. An agent-based software-defined network distributed multi-granularity controller security communication method, characterized in that: the method comprises the following steps: S1: Design and build a distributed multi-granularity controller architecture to enable each SDN autonomous domain to achieve the purpose of inter-domain communication; the architecture is divided into a basic control block, a multi-granularity security customization module, and an enhanced security controller. The basic control module follows The SDN architecture requires the realization of basic functions. The multi-granularity security customization module realizes the security functions that can be customized in the controller, and the enhanced security controller is to solve the security problem between domains in the SDN multi-network environment; S2: Under the architecture mode of step S1, the message format in the secure communication method is designed, and the data transmission between all controllers adopts the dedicated Ethernet data packet type identifier 0xEFEF, and the payload part retains the IP data packet format, while the transport layer adopts UDP protocol; S3: Neighbor discovery for secure connection establishment. Neighbor discovery adopts a broadcast discovery method. The controller of each autonomous domain broadcasts its own information through the inter-domain agent; The information such as the service port number is sent to the inter-domain agent, and the inter-domain agent encapsulates it into an Ethernet packet and forwards it to the adjacent autonomous domain, customizing the format of the neighbor discovery message; S4: Trustworthy authentication for the establishment of a secure connection. When inter-domain controllers communicate, it is necessary to ensure the communication security between the controller and the inter-domain agent and between the inter-domain agents. Therefore, the identity authentication between the controllers must be completed. Both controllers It is necessary to clarify whether the other party is trustworthy, so two-step authentication is adopted, which includes inter-domain proxy authentication and certificate authentication; S5: The tunnel establishment of the secure connection establishment. During the operation of the SDN multi-domain network, the controllers of each autonomous domain continuously broadcast their own information. After the controllers of other autonomous domains receive the broadcast message, the controller that wants to send the message initiates a connection. 2. A kind of proxy-based software-defined network distributed multi-granularity controller secure communication method according to claim 1, characterized in that: in step S1, the SDN security controller architecture is divided into a basic control module and a multi-granularity security Customized module, multi-granularity security customized module implements customizable security functions in the controller, mainly including threat defense module, flow table management module, backup module and application management module; enhanced security controller architecture, its inter-domain modules mainly include Security configuration, connection management, neighborhood management, and interdomain routing. 3. A kind of proxy-based software-defined network distributed multi-granularity controller secure communication method according to claim 1, characterized in that: in step S2, the packet format of the controller inter-domain message is as follows: the first 8 bits is the type of the message, followed by 32 bits for the length of the message (the entire UDP payload part, the bits are bytes), and the rest is the specific message content; the message types are divided into neighbor discovery messages, keepalive messages, and secure tunnel messages. The identifiers are: 0x01, 0x02, 0x03. 4. A kind of proxy-based software-defined network distributed multi-granularity controller secure communication method according to claim 1, characterized in that: in step S3, the controller sends the AS number of the autonomous domain, whether it supports secure tunnels and The information such as the security tunnel service port number is sent to the inter-domain agent, and the inter-domain agent encapsulates it into an Ethernet packet and forwards it to the adjacent autonomous domain. The format of the neighbor discovery message is customized as follows: The message type field is 0x01, and the message length is generally 10 bytes, that is, 0x000A; the following fields are AS number (32 bits), security tunnel support (8 bits, 0x00 means not supported, 0x01 means supported), port number (16 bits) , ignore this field if it means not supported); After the neighbor discovery is completed, the controller continuously updates and maintains the information of the adjacent autonomous domain. If it does not receive the message of the adjacent autonomous domain for a long time (MessageTimeout), it needs to send a Keepalive message to confirm whether the neighbor still exists; The controller of the autonomous domain returns a Keepalive message after receiving the message. If it does not receive the returned message within a certain period of time (Keepalive Timeout), it considers that the neighbor no longer exists; the Message Timeout and Keepalive Timeout are determined by each autonomous domain according to the situation. Setting; the message type field of Keepalive is 0x02, and the message length is generally 3 bytes, namely 0x0003. 5. An agent-based software-defined network distributed multi-granularity controller security communication method according to claim 1, characterized in that: in step S4, the authentication process of the two-step authentication includes: the inter-domain agent in After receiving the handshake message from the controller that initiated the request, it will not be forwarded to the controller in the autonomous domain at the first time, but will be cached first; then the inter-domain agent will initiate an authentication request to the requester to verify the requester's Non-attack intent; after the requesting controller completes the answer and passes the verification, the inter-domain agent starts to forward the data packet to the autonomous domain controller, and then performs the handshake process to complete the certificate-based identity authentication; in the DTLS protocol handshake process, Both sides of the controller need to know whether the other party is trustworthy, so strict two-way authentication is adopted. 6. A kind of proxy-based software-defined network distributed multi-granularity controller secure communication method according to claim 1, characterized in that: in step S5, the secure communication tunnel establishment process specifically includes: S51: The controller constructs a neighbor discovery data packet, writes its own AS number, security tunnel support and service port into the data packet, then sends the data packet to all inter-domain agents, and the inter-domain agent encapsulates it as a type identifier The Ethernet frame of 0xEFEF is forwarded; S52: After receiving the broadcast, the controller analyzes the AS number of the adjacent autonomous domain and the support of the security tunnel according to the broadcast message of the other party; if the other party does not support the security tunnel, it uses the normal UDP data transmission method according to the security configuration to send the data that is allowed to be shared. information; connection initiation can be initiated by any party, if no connection request from the other party is received, a secure tunnel handshake message is constructed, and the client initiates a secure tunnel connection request to the other party; S53: After the other party receives the secure tunnel handshake message as the server, it will no longer initiate requests to the other party as the client; both parties complete two-step identity verification and encryption negotiation based on inter-domain proxy authentication and digital certificates, and when both parties confirm the identity of the other party , the secure communication tunnel is established, otherwise the tunnel establishment fails, and the normal UDP protocol is used instead; S54: From the time the controller receives the broadcast message from the adjacent autonomous domain controller, it will start message timeout MessageTimeout (that is, it has not received any message from the neighbor for a long time); after the timeout, it will send a Keepalive message to the other party, if the other party does not If the Keepalive message is returned within the Keepalive Timeout time limit, it is considered that the other party does not exist and stops maintaining the secure tunnel.