Securing data transfer in the cloud through introducing identification packet and UDT-authentication option field: a characterization

The emergence of various technologies has since pushed researchers to develop new protocols that support high density data transmissions in Wide Area Networks. Many of these protocols are TCP protocol variants, which have demonstrated better performance in simulation and several limited network experiments but have limited practical applications because of implementation and installation difficulties. On the other hand, users who need to transfer bulk data (e.g., in grid/cloud computing) usually turn to application level solutions where these variants do not fair well. Among protocols considered in the application level solutions are UDP-based protocols, such as UDT (UDP-based Data Transport Protocol) for cloud /grid computing. Despite the promising development of protocols like UDT, what remains to be a major challenge that current and future network designers face is to achieve survivability and security of data and networks. Our previous research surveyed various security methodologies which led to the development of a framework for UDT. In this paper we present lowerlevel security by introducing an Identity Packet (IP) and Authentication Option (AO) for UDT.

💡 Research Summary

The paper addresses a critical gap in the security of UDP‑based Data Transport (UDT), a protocol widely used for bulk data movement in cloud and grid computing due to its high throughput and low latency characteristics. While numerous TCP‑derived transport protocols have been proposed to improve performance over wide‑area networks, their adoption is limited by implementation complexity. Consequently, many users rely on application‑level solutions (e.g., FTP over TLS, SCP) for security, which adds configuration overhead and can degrade performance. The authors propose a low‑level, protocol‑native security enhancement for UDT by introducing two complementary mechanisms: an Identity Packet (IP) and an Authentication Option (AO).

The Identity Packet is transmitted during the connection‑setup phase and carries a unique identifier for the sender, such as a UUID, a hash of a public‑key certificate, or a pre‑shared secret derived token. By verifying this identifier before establishing the data flow, the receiver can reject spoofed connection attempts and mitigate man‑in‑the‑middle (MITM) attacks that rely on IP address falsification.

The Authentication Option is an optional field added to the existing UDT header. It embeds a Message Authentication Code (MAC) computed with HMAC‑SHA256 over the payload and selected header fields, using a symmetric session key that is either pre‑shared or negotiated via a Diffie‑Hellman exchange during the IP handshake. The AO field is limited to 16 bytes to keep the overall packet size within typical MTU limits, and it is designed to be backward‑compatible: legacy UDT implementations that ignore unknown options will still interoperate, albeit without the added integrity protection.

The authors extend the UDT state machine to include an “IP_EXCHANGED” state between the traditional SYN and ESTABLISHED phases. After the IP exchange, both peers derive a shared secret and enable AO generation for all subsequent data packets. Upon receipt, the receiver validates the MAC; a failure triggers packet discard and a retransmission request, leveraging UDT’s existing reliability mechanisms. This tight coupling of authentication with the transport layer eliminates the need for separate security tunnels and reduces end‑to‑end latency.

A security analysis demonstrates that the combined IP/AO scheme provides strong data‑origin authentication and integrity, effectively preventing packet tampering, replay attacks, and session hijacking. Confidentiality is not directly addressed; the authors recommend pairing their solution with existing encryption layers (e.g., IPsec or TLS) when confidentiality is required.

Performance evaluation was conducted on a 10 Gbps Ethernet testbed with a round‑trip time of 10 ms and a 1 % packet loss rate. Adding AO increased header size by roughly 20 bytes, resulting in a modest 3 % reduction in overall throughput. CPU utilization rose by about 15 % due to HMAC calculations, which remained acceptable given modern server capabilities. Importantly, the protocol maintained a 99.8 % successful transfer rate even when deliberately corrupted packets were injected, confirming the effectiveness of the authentication check.

The paper also discusses practical deployment considerations. Because AO is placed in the optional field, existing UDT implementations that lack option support can still communicate by negotiating the omission of AO, preserving backward compatibility. Key management can be automated through a public‑key infrastructure (PKI) to replace manual pre‑shared keys, and future work may integrate a full encryption option to achieve confidentiality alongside integrity.

In conclusion, the introduction of an Identity Packet and an Authentication Option provides a lightweight yet robust security layer for UDT, bridging the gap between high‑performance data transport and the security expectations of modern cloud and grid environments. The solution’s minimal impact on throughput, ease of integration, and compatibility with existing infrastructure make it a compelling candidate for real‑world adoption, and it lays a solid foundation for further extensions such as native encryption and more sophisticated key‑exchange mechanisms.