A novel software-defined network packet security tunnel forwarding mechanism

: The OpenFlow protocol match field capacity is fixed and limited, and packet forwarding in software-defined network lacks valid authentication of data source, integrity verification, and confidentiality protection mechanism. OpenFlow only supports the MPLS label tunnel establishment, and therefore cannot establish a secure tunnel flexibly. In order to solve these problems, we propose P4Sec, a novel software-defined network packet security tunnel forwarding mechanism. As P4 allows the data plane to be reprogrammed to realize the characteristics of packet forwarding, we build a software-defined network security tunnel to prevent data malicious tampering, stealing, forgery and other malicious network behavior, implementing packet routing and forwarding based on gateway identity. Finally, we construct a P4Sec prototype system based on the software switch BMv2, verify the effectiveness of the mechanism through experimental analysis, and evaluate the overhead of the mechanism. The results demonstrate that P4Sec security mechanism ensure the authenticity, integrity, and confidentiality of forwarded data, and realize the secure forwarding requirements of data packets in software-defined network.


Introduction
Though traditional IP networks are widely used, their network structure is complex and difficult to manage.In a traditional IP network, the control plane determines how network traffic is handled, while the data plane forwards traffic based on decisions made by the control plane.Because these planes are bundled inside the network device, network flexibility is reduced, hindering the innovation and evolution of network infrastructure.A software-defined network (SDN) is a new type of computer network architecture which separates the control and management logic of the network from the network equipment, as shown in Figure 1.This architecture allows us to manage the network service from a higher level of abstraction, providing great flexibility and scalability for the deployment and configuration of the network, and thus greatly improving the management efficiency of the network [1][2][3][4].Although SDN has many advantages not shared by traditional networks, such as the separation of control and forwarding, centralized network management, and network programmability, SDN still has many security risks and other problems [5][6][7].SDN networks do not have an effective data source authentication mechanism for data packet forwarding, and attackers can therefore use spoofed source IP addresses to initiate denial of service attacks such as SYN Flood Attacks to controllers and forwarding devices, resulting in network paralysis.Furthermore, data packets in SDN networks lack data confidentiality and integrity protection, and are therefore susceptible to being stolen, deleted, forged, and so on [8,9].The OpenFlow protocol [10], established by the ONF Standardization Organization, is the SDN southbound interface communication specification that specifies the basic components and functional requirements of an OpenFlow switch as an SDN data plane forwarding device, but its match fields are fixed, limited in number, and do not support dynamic increase match fields.Although the match field has been increased from 12 to 41 [11], it requires a large cost and a long period of time to support the new match fields.OpenFlow currently only supports the establishment of MPLS labels, and does not natively support the establishment of security tunnels.With the emergence of new protocols in the network, the OpenFlow will become increasingly bloated, and the addition of new match fields will become increasingly difficult due to the limited expansion capabilities of SDN networks based on OpenFlow technology.
P4 is a high-level language for programming protocol-independent packet processors [12].Unlike OpenFlow, P4 supports a fully programmable parser, which allows us to define and parse new protocol headers.Because the P4 can programmatically define the switch processing logic, updating the protocol version of the switch is performed by simply updating the switch processing logic through the controller programming.This enables the data forwarding plane to also have programmable capabilities, allowing the parsing and forwarding processes of packets to be programmatically controlled such that the software can truly define a network and its network devices.The P4 forwarding model is shown in Figure 2. Combining the characteristics of SDN network with the advantages of P4, we propose P4Sec, a software-defined network packet security tunnel forwarding mechanism based on P4.Utilizing P4 to allow the data plane to be reprogrammed to realize the characteristics of packet forwarding, we define a new protocol header P4Sec, and build a P4-based SDN security tunnel to prevent malicious data tampering, stealing, forgery, and other malicious network behavior.Additionally, we implement packet routing and forwarding based on the gateway's identity.Using the routing and forwarding characteristics of P4Sec that are based on gateway identity, the device identity of the gateway is combined with the Diffie-Hellman (DH) key exchange algorithm to realize security negotiation for tunnel session key.Finally, we construct a P4Sec prototype system based on a BMv2 software switch, verify the effectiveness of the mechanism through experimental analysis, and evaluate the overhead of the mechanism.
The structure of this article is as follows.Firstly, some related research work regarding this topic is introduced in Section 2. The system design, working principle, and solution of the SDN packet security tunnel forwarding are then introduced in Section 3. In section 4, the specific implementation of P4Sec in SDN is described.Section 5 presents verification of the effectiveness of the mechanism through experimental analysis and evaluate the overhead of the mechanism.Section 6 then summarizes the work of this paper and states our future work.

Related work
The separation of the control plane from the data plane in SDN reduces the difficulty of attacking the packet forwarding of the data plane, which enables malicious activity such as copying packets, hijacking traffic, malicious tampering, and the insertion of false packets into the normal network flow.However, because the switch in the data layer only provides simplified data forwarding functions, the data forwarding verification scheme cannot simply be deployed in a traditional IP network.
SPHINX [13] provides data flow forwarding verification functionality to SDN, and obtains statistical information of the data layer through the control plane to detect the data packet loss and attacks such as traffic hijacking.However, due to the lack of an effective packet verification function, it cannot guarantee that the received statistical information is correct, nor can it guarantee consistency between the packets arriving at the destination and those sent by the source.Therefore, SPHINX cannot detect intelligent data plane attacks such as malicious discards and packet replay attacks.SDNsec [14] enables each switch to embed cryptographic markings in its forwarding packet header, verifying the normal packet forwarding by checking the cryptographic markings of the packet header.However, SDNsec requires the controller to generate a shared key with each forwarding device, and lacks confidentiality protection for data packets.Shin et al. [15] proposed a CloudWatcher method for SDN traffic monitoring in a cloud environment, automatically importing network traffic into a corresponding security device to implement the necessary network packet inspection.However, redirecting traffic to the security device for data source verification requires a complicated implementation, and the location of the security device must be comprehensively considered for the level of cooperation between different security devices and the granularity of SDN traffic control.Because this CloudWatcher method only supports match fields using common protocols in the first four layers of the network, its control granularity is limited [16].

Basic principles
The SDN network packet security tunnel forwarding mechanism implements four basic functions to realize the secure tunnel forwarding of data packets.The four functions include key negotiation, authentication, encryption and decryption, and routing and forwarding based on gateway identity.
The key negotiation function refers to the generation of a session key by the gateway devices of the sender and receiver according to the improved DH key exchange algorithm during the tunnel negotiation initialization process.The improved key exchange algorithm combines the DH key exchange algorithm with the gateway device identity, and uses the identity-based signature algorithm to authenticate the negotiation data, realizing key agreement between gateway devices to prevent man-in-the-middle attacks.The generated session key is then used for secure data packet forwarding during the tunnel data interaction process.
The authentication function refers to applying an identity-based signature algorithm to the data packet during the tunnel data interaction process.This enables verification of the source and the integrity of the data packet as the gateway device forwards the data, which ensures the authenticity and integrity of the data.
The encryption and decryption function refers to encrypting and decrypting data packets during the tunnel data interaction process by using the session key generated during the tunnel negotiation initialization process, ensuring the confidentiality of data packets.
Routing and forwarding based on gateway identity refers to using the gateway identity as the match field of a data packet and forwarding the data packet based on the matched gateway identity, utilizing the combination of the gateway identity and the P4Sec header.This enables the network data packet routing and forwarding mechanism based on gateway device identity.These four functions of P4Sec complement each other, and jointly construct the SDN data packet security tunnel forwarding mechanism.

Architecture
P4Sec security tunnel forwarding mainly consists of two processes and two main modules.The two processes include the tunnel negotiation initialization process and the tunnel data interaction process.The two modules are the matching and forwarding module and the security processing module.The P4Sec overall architecture is shown in Figure 3.
For the tunnel negotiation initialization process, the tunnel gateway devices generate a session key by using the improved DH key exchange algorithm through tunnel negotiation request/reply message.Using this session key shared between the sender gateway and the receiver gateway provides security support for the tunnel data interaction process.
For the tunnel data interaction process in the SDN network, the controller is the network manager and is responsible for the routing management of the entire network.The controller formulates the routing strategy according to the DGW_ID field of the gateway device identity in the P4Sec header, and sends the strategy to all forwarding devices in the network, instructing all forwarding devices to match and forward packets according to the DGW_ID field.The tunnel gateway devices then perform security processing on data packets for source authentication, integrity verification, and confidentiality protection when forwarding data.
The matching and forwarding module is located inside all network forwarding devices, including the tunnel gateways.The module encapsulates or decapsulates the P4Sec header for the data packet, initializes the P4Sec protocol header, and either forwards the packet to the internal security processing module for security processing or forwards the packet to the adjacent forwarding device according to the tunnel destination gateway identity for further processing.The module matches and forwards the data flow according to the received flow rule sent by the controller, thereby implementing control forwarding based on the tunnel gateway identity.
The security processing module is located inside tunnel gateway devices.It provides security services for data packets, encrypts and decrypts data packets to implement data confidentiality protection, verifies signatures for packet authenticity and integrity, and ensures data forwarding security.

P4Sec header
The P4Sec protocol header consists of Proto_ID, Sessiontype, SeqNo, DGW_ID, Verification, and IV, as shown in Figure 4.These elements are defined as follows.
Proto_ID is a next header field that indicates the type of the next protocol header in the protocol header parsing process.
Sessiontype is a session type message field.P4Sec defines three kinds of message session types.Tunnel negotiation request messages have a REQ value, and are used to request tunnel establishment during the tunnel negotiation initialization process.Tunnel negotiation response messages have an ACK value, and are used for tunnel gateway response request messages during the tunnel negotiation initialization process.Tunnel communication messages have a NORMAL value, and are used for normal communication during the tunnel data interaction process.
SeqNo is a serial number field, and the sender gateway device maintains a separate SeqNo for each data packet.For each forwarded packet of a given tunnel, the tunnel gateway device increments SeqNo such that SeqNo is used as a unique identifier for each packet in the data flow.This can be used to prevent packet anti-replay attacks.
DGW_ID is the destination gateway device identity field, and stores the unique identifier of the destination gateway device identity.The switch matches this field according to the flow rule sent by the controller, using the gateway identity to forward data packets to implement route.
Verification is a field containing authentication information.This authentication information is generated by the gateway device using its own private key, and is used to sign the tunnel negotiation request packet, the tunnel negotiation response packet, and the tunnel communication message during the tunnel negotiation initialization process and the tunnel data interaction process.This signing enables verification of the authenticity and integrity of data packets.
IV is a field containing an initialization vector.When a data packet is encrypted, the IV is generated as an unpredictable piece of data that is 16 bytes in length, which is the block size in AES, and this data is unique to the message/key combination.
Temp is a data field used for tunnel negotiation.It is used to generate session key, and is used for the tunnel negotiation request message and the tunnel negotiation response message during tunnel negotiation initialization process.

Tunnel data interaction process
The tunnel data interaction process is a process in which the terminal host relies on the SDN gateway device to conduct the matching and forwarding of packets and to secure processing.This process, shown in Figure 5, is outlined as a sequence of seven steps, as follows.In the process, the gateway devices S1 and S2 obtain the device identity through their own configuration files and generate the public key of device identity.They obtain the private key of device identity from the trusted Private Key Generator (PKG) through secure channels.P4Sec uses the Identity-Based Signature (IBS) algorithm [17] to generate corresponding public and private keys for the gateway device.6) After Gateway S2 receives the data packet, the gateway resolves the P4Sec header and obtains the Verification field, which contains the signature information of the Encrypted_Data field.The security processing module of Gateway S2 then verifies the signature information to ensure the authenticity and integrity of the data packet.If the verification fails, the packet will be discarded.Meanwhile, the session key K generated during the tunnel negotiation initialization process is used to decrypt the Encrypted_Data field, the decrypted data is then stored in the original field, and the packet is discarded if the decryption fails.(7) Gateway S2 deletes the P4Sec header in the data packet, submits the packet to the matching and forwarding module, and then matches and forwards the data packet to destination host H2.

Implementation
This chapter provides a detailed introduction for the implementation of the tunnel negotiation initialization process, the matching and forwarding module based on P4Sec, and the security processing module based on P4Sec.

Tunnel negotiation initialization
The tunnel negotiation initialization process is shown in Figure 6.In this implementation, the 6144-bit MODP Group of RFC 3526 recommendation [18] and SHA-256 are used to generate a 256-bit AES session key K, which is used in tunnel data interaction process.The 6144-bit MODP Group id is 17, the prime P is 2 6144 -2 6080 -1+2 64 {[2 6014 π ] + 929484}, the generator a is 2, and [x] represents a largest integer less than or equal to x.The Hash function is SHA-256, which generates a hash value of 256 bits in length.The specific implementation of the signature algorithm is detailed in Section 4.3.1.
(1) Gateway S1 first queries the configuration file to get the device identity of Gateway S2, and then provides its own device identity and that of Gateway S2 to the controller.(2) The controller uses the centralized control and the whole network view to determine the route and forwarding rule according to the identity of Gateway S2 at the receiving end, and then delivers to the forwarding devices of the entire network.The forwarding devices, including Gateway S1, match and forward the data to receiving Gateway S2 according to the flow rule sent by the controller.(3) Gateway S1 selects a secret random number X A (540 bit or more), calculates , and then stores the calculation result of Y A in the Temp field of the tunnel negotiation request message.(4) After Gateway S1 calculates the hash value of Y A , the gateway uses the private key of its own device identity to sign the hash value, generates signature information (R A , S A ), and then stores that information in the Verification field (260 bytes).

Matching and forwarding module
Matching and forwarding module is implemented by developing a P4 application on forwarding devices.There are currently two parallel language specifications, including P4-14 and P4-16.The development of matching and forwarding module uses P4-14.Since the target for our P4 programs is BMv2, we uses the p4c-bmv2 as the compiler.
Packets arriving at the P4 forwarding device are first processed by the packet parser.The parser finds and extracts the previously defined and supported headers, including ethernet_header, p4sec_header, ipv4_header, and so on.The extracted headers are then passed to the match-action table for processing.The control program determines the jump relationship of the data packet in different match-action tables, which are detailed as follows.
(1) Header.The header is a list of ordered fields, each with a corresponding name and length.Each header has a corresponding instance of the header to store the data specific to each field.As shown in Table 1, the P4Sec security tunnel forwarding mechanism defines the corresponding protocol header.(2) Parser.After defining the headers, we also need to define the relationship between the headers and the corresponding relationships of packets parsing.The parser is used to parse the byte flow into corresponding protocol headers for subsequent flow table matching and action execution.The P4Sec header is added between the Ethernet header and the IPv4 header, and the P4Sec header type is 0x1212.When the Ethernet etherType is 0x1212, the parser should jump to the P4Sec header for subsequent parsing as shown in Figure 7.When the proto_id of P4Sec is 0x0800, the parser should jump to the IPv4 header for subsequent parsing.(3) Table .The format of the table is Match+Action, meaning it contains match fields and their corresponding execution actions.When the match field defined in the table matches a field in the packet successfully, a corresponding action is performed.For the P4Sec security tunnel forwarding mechanism, the flow_forward table and the data_to_verify table are mainly involved.
The flow_forward table and the data_to_verify table are designed and implemented, and described as follows.flow_forward table: According to the flow rule delivered by the control plane, the flow_forward table uses the DGW_ID field in the P4Sec header as the match field to match and forward the received data flow.In the Table 2, reads is the value of the match field, and the matching type is exact match; actions is the action performed after the matching succeeds, where in this case, the custom forwarding behavior my_forward sets the value of standard_metadata.egress_spec to determine the egress port of data flow.The custom forwarding behavior my_forward achieves the routing and forwarding of the data flow according to the gateway device identity._drop is the default action of unsuccessful matching, and size is the maximum entry size of the matching table.: This table preprocesses the data packets that need to be forwarded to the security processing module for processing, meaning the do_pkt_to_verify action primitive is used to send the pending data packets to the port connected to the security processing module.The security processing module performs encryption and decryption as well as authenticity and integrity verification of the forwarded data packets, and its specific implementation is detailed in Section 4.3.8.
In the ingress process, data packets are checked for whether they have been processed by the security processing module ( Whether there is a specific header that identifies that the packet has been processed by security module ).If a data packet has been processed, the packet is sent to the flow_forward table, matching the DGW_ID field for packet forwarding according to the flow rule sent by the controller; if it has not been processed, the packet is sent to the data_to_verify table, as it is ready to be sent to the security processing module for security processing.
In the egress process, data packets are checked for packet source and the corresponding headers are added or deleted according to the data source.If the packet has been processed by the security processing module and is from network, and the P4Sec header and other redundant header are deleted and ready to be forwarded according to the output port.If the packet has been processed by the security processing module and is from terminal host, the P4Sec header will be valid.If the packet is not processed by the security processing module, a specific header is added to identify the packet which is forwarded to the secure processing module port.

Security processing module
The security processing module includes authenticity and integrity verification as well as encryption and decryption processing.

Authenticity and integrity verification
In this solution, an IBS algorithm is used to provide data authenticity and integrity authentication for the tunnel negotiation initiation process and the tunnel data interaction process.IBS is a public key cryptography.It does not use a digital certificate, and instead directly uses the unique identity of a gateway device as the public key.The private key is generated and distributed to users by the trusted PKG.Because the public key is the public identity information of gateway device itself, the trust authority does not need to create and distribute the public key certificate, which solves the problems of certificate generation, issuance, backup, and revocation, reducing the cost and complexity of system establishment and maintenance while greatly saving storage space and network bandwidth.
(1) Setup.Taking the security parameter k as input, the A-type curve parameter provided by the open source pairing-based cryptography library (pbc library) is used as the system parameter to generate the system master key msk.This process is completed by PKG, and secretly saves the system master key msk.H 2 uses SHA1, and outputs 160 bits.(2) Extract.This algorithm is used to generate the public and private key of the gateway of the sender.According to the sender gateway identity GW_ID, we can get the public key Q ID of the sender gateway.Enter the system master key msk and the sender gateway identity GW_ID, we can get the private key d ID .5: return ( , ) RS ; 6: END (4) Verify.The Verification field, the sender gateway identity GW_ID, and the received message m are used as input, and the verification algorithm is applied to verify the correctness of the Verification field.If Value1=Value2 in the verify algorithm, the verify passes.Otherwise, the verify fails and the data message is discarded.

Data encryption and decryption processing
In this scheme, the Output Feedback (OFB) mode of the AES encryption algorithm [19] is used to provide data confidentiality protection for the tunnel data interaction process.In the OFB mode [20], the key stream is first generated by a block cipher generator, and then the key stream is XOR with the plaintext stream to obtain a ciphertext stream.Decryption is then performed using a block encryption generator to generate the key stream first, and then the key stream is XOR with the ciphertext stream to get plaintext.Due to the symmetry of the XOR operation, the process of encryption and decryption is identical.The OFB mode uses a block algorithm to implement stream algorithm, and the plaintext does not need to be aligned according to the size of the block.The plaintext is the same length as the ciphertext, which is convenient for the encryption of streaming data, and can be timely encrypted and for the transfer of data smaller than the block size.
The encryption algorithm is shown in Algorithm 5.The message Data is the data to be encrypted, and the K is the session key generated during the tunnel negotiation initialization process described in Section 4.1.The encrypted Ciphertext and initialization vector IV are the output.The OFB mode of AES requires the use of an Initialization Vector (IV).An IV is unique to the combination of a message and key, and must be known by both the encrypter and the decrypter.

Experimental environment
We implemented and deployed a simple P4Sec prototype using a virtual BMv2 switch and Mininet.The controller uses runtime_CLI and the northbound interface is the P4 Runtime.We added a matching and forwarding module and a security processing module for the P4Sec tunnel gateway device, signed the data using an identity-based signature algorithm, and encrypted and decrypted the data using the AES symmetric encryption algorithm.Figure 9 shows the evaluation environment we created to evaluate system effectiveness, safety features, time consumption.
The experimental environment was built on a host with an Intel Core i3-4170 CPU 3.70GHz and 16 GB of memory, which hosted BMv2 software switch and Mininet.S1 and S2 are access forwarding devices (i.e., tunnel gateway devices), S3 and S4 are central forwarding devices, and H1 and H2 are terminal hosts.Scapy was used to generate data packets on sender H1, and the Wireshark was used to analyze the device port packets.per second.The DGW_ID fields of S1, S2, S3, and S4 were set to 1001, 1002, 1003, and 1004, respectively.The controller sent the following flow rules: for S1, data packets with DGW_ID fields containing 1002 were forwarded to S3; for S3, data packets with DGW_ID fields containing 1002 were forwarded to S2. Monitor the port statuses of forwarding devices S1, S2, S3, and S4.The experiment was run for 10 s for each instance and was repeated 10 times, after which the 10 experimental data were averaged.The test results are shown in Figure 10.As can be seen from Figure 10, the traffic values of the S1-eth1, S3-eth0, S3-eth1, and S2-eth1 ports are approximately the same, an average of 200 packets per port.After analysing packets on the S4, S3 and S2 ports, it was seen that the data packets received by S3 and S2 carried the P4Sec protocol header with DGW_ID fields containing 1002, and the traffic values of S4-eth0, S4-eh2, and S2-eth0 ports were zero.This resulted from the tunnel gateway S1 adds P4Sec headers with DGW_ID field of 1002 to the data packets, the forwarding device S1, S2 and S3 obtained the gateway identification as the match field and matched and forwarded the data flow accurately based on the tunnel gateway identification.

Security processing effectiveness
The terminal host H1 simultaneously sends data flow A, B, and C to H2, and each data flow is sent at a rate of 20 pps for a duration of 10 s.The tunnel gateway S1 adds valid P4Sec headers to the data flow A, B, and C, and the DGW_ID field of P4Sec header contains 1002.The forwarding policy was delivered to S1, S2 and S3: the data flow forwarding path for DGW_ID fields containing 1002 was S1->S3->S2.When the forwarding device S3 forwards the data flow B, the Verification field of the data flow B is tampered; when the forwarding device S3 forwards the data flow C, the Data field of the data flow C is tampered.Each experiment was repeated 10 times, after which the data of the 10 experiments were averaged.The test results are shown in Figure 11.As can be seen from Figure 11, the number of S3-eth1 port packets was about three times as many as that of the S2-eth2 and H2-eth0 ports on average.After analysing packets on the S3, S2 and H2 ports through Wireshark, it was learned that packets sent by S3-eth1 port included data flow A, data flow B, and data flow C, for a total of 600 data packets; while packets sent through the S2-eth2 port were identical to those received by H1, an average of 200 packets, carrying data flow A and the DGW_ID field of 1002.This resulted from S2 refusing to forward error-signed packets and tampered packets after verifying the Verification fields in the P4Sec header in the process of forwarding data flow.

Delay analysis in key exchange
The processing time of the improved DH key exchange algorithm was compared with the original DH key exchange algorithm used in the P4Sec tunnel negotiation initialization process.Figure 12 shows the time comparison for S1 to generate tunnel request messages.Figure 13 shows the time comparison for the generation of session keys by S2 after receiving a tunnel request message.Figure 14 shows the time comparison for the generation of session keys by S1 after receiving a tunnel answer message.In Figure 12, 13 and 14, DH represents the processing time of the original DH algorithm.P4Sec_DH represents the processing time of the improved DH algorithm.
In Figure 12, P4Sec_DH represents the processing time for generating tunnel negotiation request messages by S1, including the time for generating and signing the Temp field.Compared with the original DH key exchange algorithm, the processing of signing the Temp field was added.We generated 200 different tunnel negotiation request messages respectively, and obtained the processing time for the two DH algorithms to generate tunnel negotiation request messages.After calculation, the average processing time of the original DH algorithm was 65.8 ms, while the average time of the improved DH algorithm was 86 ms.The processing time was increased by 20.2 ms, which is 30.1% more than the original DH algorithm.In Figure 13, P4Sec_DH represents the processing time for generating session keys after receiving a tunnel request message by S2, including the time for verifying the Verification field and generating the session key.Compared with the original DH key exchange algorithm, the processing of verifying the Verification field in the tunnel request message was added.We received 200 different tunnel negotiation request messages by S2 respectively, and obtained the processing time for the two DH algorithms to generate session keys.After calculation, the average processing time of the original DH algorithm was 61.1 ms, while the average time of the improved DH algorithm was 72.1 ms.The processing time was increased by 11 ms, which is 18% more than the original DH algorithm.
In Figure 14, P4Sec_DH represents the processing time for generating session keys after receiving a tunnel response message by S1, including the time for verifying the Verification field and generating the session key.Compared with the original DH key exchange algorithm, the processing of verifying the Verification field of the tunnel response message was added.After calculation, the average processing time of the original DH algorithm was 61.9 ms, while the average time of the improved DH algorithm was 72.8 ms.The processing time was increased by 10.9 ms, which is 17.6% more than the original DH algorithm.Experiments show that, compared with the original DH protocol, the improved DH protocol has some difference in processing time, but the impact on the P4Sec tunnel negotiation initialization process is within an acceptable range.

Delay analysis in security processing
To analyze the impact of tunnel gateway security processing on data forwarding, we verified 300 data packets and obtained the total processing time, data signature and verification time, and encryption and decryption time during the tunnel gateway forwarding.The total processing time of the tunnel gateway S1 at the sending end includes matching and forwarding time, signature time, and data encryption time.The total processing time of the tunnel gateway S2 at the receiving end includes matching and forwarding time, verification time, and data decryption time.The comparison of the security processing time of the sender S1 is shown in Figure 15.The comparison of the security processing time of the receiver S2 is shown in Figure 16.As can be seen from Figure 15, the average total time for processing of the tunnel gateway S1 is 52.6 ms, in which the data signature time is 25 ms, which accounts for 47.5% of the total processing time; the data encryption time is 0.19 ms, which accounts for 0.3% of the total processing time.As can be seen from Figure 16, the average total time for processing of the tunnel gateway S2 is 52.5 ms, in which the data verification time is 15.7 ms, which accounts for 29.9% of the total processing time; the data decryption time is 0.18 ms, which accounts for 0.3% of the total processing time.According to the analysis, the signature algorithm accounts for the largest proportion in security processing, and the complexity of signature algorithm in security processing directly determines the total forwarding delay of tunnel gateway.

Conclusion
In this paper, we propose P4Sec, a novel software-defined network packet security tunnel forwarding mechanism.For this mechanism, in light of the lack of effective data confidentiality protection, authenticity and integrity verification, as well as other problems relevant to SDN, we apply P4 technology in the SDN, design the P4Sec header, and utilize of its four functions to realize security tunnel forwarding based on P4Sec.Based on the open source software switch BMv2, we initially implemented security tunnel forwarding based on P4Sec, and then valuated the effectiveness, safety features, time consumption of the mechanism.The experimental evaluation shows that tunnel forwarding based on P4Sec effectively implements encryption, decryption, signatures, and verification of data packets in SDN, ensuring the confidentiality, authenticity, and integrity of the data packets transmitted in the tunnel.In the process of data packet forwarding, routing and forwarding are based on gateway identity such that network forwarding behavior is defined according to gateway identity, creating a novel method of routing and forwarding for SDN.For future work, we will also study the SDN data plane forwarding security problem, and further improve data processing capability.

Figure 5 .
Figure 5. Tunnel data interaction process based on P4Sec.

( 3 )
Sign.Use the signature algorithm on the message m to generate the signature information (R,S), which are stored together in the Verification field of the P4Sec header.The signature information R and S are each a 130-bit string, occupying 260 bytes total (2080 bits).Algorithm 3: Signature Algorithm Input: the message m , the private key ID d

Figure 15 .
Figure 15.The comparison of the processing time for S1.

Figure 16 .
Figure 16.The comparison of the processing time for S2.

Table 1 .
Structure of the P4Sec header.

Table 2 .
Structure of the flow_forward table.

Table 3 .
Structure of the data_to_verify table.Control Program.The control program determines the order in which the data packets are processed, meaning the jump relationships of data packets in different matching tables.After match tables is defined and implemented, a control program is also needed to determine flow control between the different tables.This process of the control program is shown in Figure is as shown in Algorithm 6.The input is the Ciphertext to be decrypted, the initialization vector IV, and the session key K. Ciphertext is the Encrypted_Data field in the received packet, IV is the IV field of the P4Sec header, and the K is the session key generated during the negotiation initialization process.The output is the decrypted plaintext.