INTERNET-DRAFT Network Working Group Danilo Valeros Bernardo Request for Comments: Doan B. Hoang Category: Informational The University of Technology Expires March 2010 Sydney, Australia September 2009 Security Requirements for UDT draft-d-sec-udt-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Abstract UDT does not have its specific security mechanism. It depends on the application to provide authentication and lower layer to provide security mechanisms[GG07]. However, UDT implementations should check each arrived packets are from the expected source, since UDP is connectionless. This document proposes evaluation of security requirements for UDT, or UDP based Data Transfer considered as an alternative data transfer protocol for the situation when TCP does not work well.The objective is to achieve a wide class of security methods used on existing mature protocols such as UDP and TCP. Bernardo, DV Expires - March 25, 2010 [Page 2] Security Requirements for UDT October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Security Framework . . . . . . . . . . . . . . . . . . . . . 3 2.1 Absence of Checksum . . . . . . . . . . . . . . . . . . . 3 2.2 Dependencies on user preferences . . . . . . . . . . . . . 3 2.3 Dependencies on existing mechanisms . . . . . . . . . . . 3 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Evaluations . . . . . . . . . . . . . . . . . . . . . 5 3.1. Evaluation 1 Sending Rates . . . . . . . . . . . . . . . 6 3.2. Evaluation 2 End-to-End Security . . . . . . . . . . . . 6 3.3. Evaluation 3 Random sequence number feature. . . . . . . 7 3.4 Evaluation 4 Encapsulation of IPsec ESP packets . . . . 8 3.5 Evaluation 5 UDTv4 responses to Potential Threats . . . . 8 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 9 5. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 1. Introduction This document proposes UDT's security requirements based on existing network protocols, aimed at preserving the security and privacy of the data flow. UDT relies on UDP to check IP streams, and similarly, it is susceptible to attacks such as snooping, packet interception and IP masquerading. UDT's objective is to deliver bandwidth-intensive applications over a protocol that carries a minimal amount of overhead (such as UDP), but it cannot guarantee that it will avoid compromising the security, privacy, and data integrity that is desired by the user. This document presents a summary reviewing the existing design and implementation of UDT's inherent security features that have not been reviewed previously. The analysis covered any inherent security features and control algorithms. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Bernardo, DV et al. Informational [Page 3] 2. Security Evaluation and Framework The contention for the need of security mechanisms of the new UDT is derived from 3 important observations [BH09b]. 2.1 Absence of inherent security mechanisms, such as checksum for UDT 2.2 Dependencies on user preferences and implementation on the layer on where it is implemented 2.3 Dependencies on existing security mechanisms of other layers on the stack Subsequently, the presentation of a model for UDT supports the need of minimizing its sending rates in retransmissions and introducing its own checksum [CD90] in its design; and supports the importance of implementing security in UDT. 3. Security Framework UDT's position in the layer architecture provides a layer-to-layer approach in addressing security, its implementation needs to rely on proven security mechanisms developed and implemented on existing matured protocols. A summary of security mechanisms and their implementations are presented in Fig. 1. +-----------------+ | | SSL/TLS, SSH, HTTPS |Application Layer| | | +---+ +-----------------+ |CCC| ^ +---+ v / +-----------------+/ | UDT Socket | +-----------------+ ^ v +-----------------+ | | | UDT | | | +-----------------+ ^ v UDT Data from Sender to Receiver +------------------+ |OS Socket Interace| UDT Control Flow - Receiver to Receiver +------------------+ ^ v ETH Header +--------------------------------+ +-----------------+ |Src Addr, Des addr, Chksum | | | ---------------------------------+ | UDP |<----> IP Header |Src IP, Dest IP, Chksum,TTL | | | ---------------------------------- +-----------------+ UDP Header |Src Port, Dest Port, Len, Chksum| +--------------------------------+ | | | Message | | | +--------------------------------+ Figure 1. : UDT in Layer Architecture. UDT is in the application layer above UDP. The application exchanges its data through UDT socket, which then uses UDP socket to send or receive data. Bernardo, DV et al. Informational [Page 4] UDT is in the application layer above, this requires that data is transmitted securely and correctly. UDT is implemented by each application and not by an operating system or by a separate stack. The existence of five application-dependent components, such as the API module, the sender, receiver, and UDP channel, as well as four data components: sender's protocol buffer, receiver's protocol buffer, sender's loss ist and receiver's loss list [BH09a], require that UDT security features must be implemented on an application basis. An application exchanges data through the UDT socket but relies on the UDP socket to send and receive data. This results problems during data transmission from the UDP socket, such as unreliable data, and security flaws [BH09a]. UDT's Sequence Number is 31 and a bit long. This is a small sequence space that does not effectively protect connections against some blind attacks, such as the injection of resets into the connection. It does not have a feature that avoids sequence number attacks, where an attacker can guess the sequence numbers that a future connection would use. The distinction between UDT and other protocols, such as UDP, TCP, STCP and DCCP, is that UDT does not have a checksum. For most protocols, checksum is applied to the protocol header. It applies strong integrity checks, which are available in other protocols (e.g. DCCP). They use the same algorithm to generate the IP checksum to generate this number. The checksum can be included for the segment in UDT, in addition to providingthe information contained, and to prevent packets from being incorrectly forwarded by UDP. This provides an added security feature to ensure segment integrity. Bernardo, DV et al. Informational [Page 5] UDT requires protection against attackers who can snoop on a connection in progress, or who can guess valid sequence numbers in other ways. Despite its flow management and multiplexing, UDT does not guarantee that all packets will arrive and, if they do, that the packets' sequences will be accurate. Attackers can execute easily by sending data packets with random sequence numbers. If one of these packets hits the valid sequence number window, the attacker's packet application data may be inserted into the data stream. Attackers can also send random sequence and acknowledgment numbers. If one of these packets hits the valid ACK number window, the receiver will shift its sequence number window accordingly, getting out of sync with the correct endpoint. UDT additionally needs to provide a mechanism to limit the potential impact of some denial-of-service attacks. It needs to provide limitations on requests, processing options and ICMP messages, and excessive packet generation avoidance on the servers. Because it was designed as an application level protocol that is intended for delivery of data in high speed networks, the need to establish how it handles QoS is essential. It is a relatively new protocol, tested in limited production cases in 2004 and focused on performance between long distance links, before UDTv4 was developed and introduced in 2007. 3. Evaluations UDT is designed to be a general purpose and versatile transport protocol. One of its major objectives is for application level implementation. It is supportive for firewall such as NAT (see [RFC3715]) traversing with UDP multiplexing and rendezvous connection setup. In its design, UDT is not expected to provide all of the necessary security features. This section describes a few considerations that can be implemented to secure UDT data flow. Figures 3 show the possibilities for arranging secure UDT from end-to-end (from the UDT to the UDP sockets). As a transport protocol designed to carry reliable data, UDT is required to meet fundamental security objectives: -Availability of reliable and timely data transport services in High-Speed WAN. -Integrity of the user-to-user data transfer carried by UDT. Bernardo, DV et al. Informational [Page 6] The following evaluations are based on the consideration presented by DV Bernardo & DHoang [BH09a]. 3.1 Evaluation 1. UDT Sending Rates Sending rates UDT may need to diminish its sending rates in the presence of retransmission time outs and the arrival of duplicate acknowledgments. An attacker can impair its connection by either causing data packets or their acknowledgments to be lost or by forging excessive duplicate acknowledgments. Causing three congestion control events back-to-back will often cut the ss threshold to its minimum value of 3*SMSS, causing the connection to immediately enter the slower-performing congestion avoidance phase. Here is the pseudo code of the fast retransmit and fast recovery algorithm of which UDT's CTCP redefined two handlers: onACK and onTimeout. Virtual void onACK (cons tint&ack) { if(three duplicate ACK detected) { //ssthresh=max{flight_size /2,3} // cwnd=ssthresh + 3* SMSS } else if (further duplicate ACK detected) { //cwnd=cwnd + SMSS } else if (end fast recovery) { // cwnd=ssthresh } else { //cwnd=cwnd+1/cwnd } } 3.2 Evaluation 2. End-to-End Security End-to-end security as shown in Figure 2. UDP Multiplexer UDP Multiplexer IPsec ^ ^ UDP \ +--+ | | +--+ / \ | | | Sequence Number | | | / Sockets ---O<--> |--|<--|------------------->|-->|--|<-->O--- Sockets / | | | UDT Connection | | | \ / | | | | | | \ | | | UDT Flow | | | \ | | | | | | \ | | | | | | Sockets ---O<--> |--|\ | | | | / | | \ | | | | / +--+ \| | +--+ v v \ \_____> To other addresses End-to-End Security Figure 2. Bernardo, DV et al. Informational [Page 7] Implementations and applications desiring stronger security (to maintain integrity, authentication, confidentiality, and access control) should use IPsec [KA98] or end-to-end security [SRC84]. Depending on the security level required, application level cryptography may suffice. 3.3 Evaluation 3. Random sequence number feature. In TCP, initial sequence numbers are intended to be more or less random. TCP specifies that the 32 - bit counter be incremented by 1 in about every given time.Instead, Berkeley-derived kernels increment it by a constant every second, and by another constant for each new connection. The TCP sequence number's unpredictability has arguably been adhered to for many years. However, some implementations have still failed to take this into careful consideration; one such example is the iPhone. Its earlier OS version made its TCP initial sequence numbers predictable which consequently led to either TCP spoofing or session hijacking. This has since been corrected in a new OS release. A lesson can be drawn from that experience in the implementation of UDT, especially it does not intend to protect against some classes of attackers, and is dependent on TCP and UPD. Another problem with UDT, is its connections can be hijacked (terminating the connection unexpectedly, or causing compromised data to be accepted by an unsuspecting endpoint as if it came from a valid sender),especially when attackers can guess the valid sequence numbers. UDT, however, provides simple randomization for m_iTSN. Its sequence and ACK numbers form a defense against attacks. Attackers can nevertheless still send many packets with random numbers, which if they end up sequence-valid, may shut down the connection. Security evaluations for UDT were adopted from RFC 1948, giving each connection a cryptographic hash function (such as MD5) for each separate sequence number space. Recommendations when using random numbers can be based on TCP in accordance with the recommendations provided. struct CHandShake { int32_t m_iVersion; // UDT version int32_t m_iType; // UDT socket type int32_t m_iISN; // random initial sequence number int32_t m_iMSS; Bernardo, DV et al. Informational [Page 8] // maximum segment size int32_t m_iFlightFlagSize; // flow control window size int32_t m_iReqType; // connection request type: 1: regular connection request, 0: rendezvous connection request, -1/-2: response int32_t m_iID; // socket ID int32_t m_iCookie; // cookie }; UDT provides an space on the control packet for user defined control packets (see also Fig. 1). // bit 16 - 31: // 0 1 2 3 // 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// |1| Sequence Number a (first) | // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// |0| Sequence Number b (last) | // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// |0| SequenceNumber (single) | // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// 3.4 Evaluation 4. Base on UDP encapsulation of IPsec ESP packets shown in Figure. 3. UDP encapsulation of IPsec ESP Packets Source Port Destination Port Length Checksum ESP Header (RFC2406) +-------+ | | .--> | UDT | <--. | | | | | +-------+ | | | | | .--> V <--. +-------------------------------+ | Source Port | Destination Port| --------------------------------- | Length | Checksum | --------------------------------- | ESP Header (RFC 2406) | +-------------------------------+ Figure 3. Schematic diagram of securing UDT on top of UDP. It is possible to create a security arrangement to secure UDT connections, such as authentication handled by IPsec. Since it relies on UDP, developers can use UDP encapsulation [RFC2406] to ensure the connection from UDP is secure. IPsec provides encryption and keying services and offers authentication services; adding ESP extends services to encryption. Specifications on protecting UDP packets can be found on RFC3948. Moreover, it can be implemented with MD5 to cater for key management to meet user security requirements. typedef unsigned char md5_byte_t; /* 8-bit byte */ typedef unsigned int md5_word_t; /* 32-bit word */ Bernardo, DV et al. Informational [Page 9] 3.5 Evaluation 5. UDTv4 responses to Potential Threats. UDT may be used in a wide variety of risk situations, and therefore it is important for developers of systems to adopt security measures for their particular situations and decide on appropriate measures. In countering insider attacks, the principles of [RFC 2196] should be applied to minimize risk of attacks. To protect against data corruption in data transfer and in the network, where concealed and undetected errors in the datagrams delivered by lower layer transport services, such as UDP and IP, are considered too great, additional integrity protection is required. Protection also provided on the application-layer would minimize deliberate integrity attacks to the UDT header. The absence of appropriate security mechanisms for detection of packet replays remains a risk. Stronger protections are required when the operating environment contains significant risk of deliberate attacks from sophisticated adversaries. For stronger security integrity protections, an IP Authentication header should be used. For mobile users, confidentiality requirements,including but not limited to masking of IP addresses and ports, ESP cryptographic transform that includes cryptographic integrity protection must be used. This provides added protection against integrity and confidentiality threats. As this caters to application-level protection, encryption on that level may not be required. IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]), however, may be considered for key management. 4. Implementation There are several ways to use the proposed framework; as a tool to provide network researchers, technical designers basic understanding of the advantages to a moresecure but flexible systems and infrastructure when using UDT, and as a tool to better evaluate the risks in the implementation of UDT on different layers of the stack. 5. IAB Considerations The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715]. 6. Acknowledgments Thanks to the people at iNext, University of Technology, Sydney. 7. Security Considerations All protocols discussed in this paper have their own specific security requirements that MUST be considered. The special security considerations for UDT are discussed here. Bernardo, DV et al. Informational [Page 10] 8. References 8.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. 8.2. Informative References [BH09a] D.V. Bernardo and D. Hoang, "Network Security Considerations for a New Generation Protocol UDT. Proc. IEEE the 2nd ICCIST Conference 2009, Beijing China. [BH08b] D.V. Bernardo and D. Hoang, "A Security Framework and its Implementation in Fast Data Transfer Next Generation Protocol UDT", Journal of Information Assurance and Security Vol 4(354-360). ISN 1554-1010. 2009 [CD90] D.D. Clark and D.L. Tennenhouse: Architectural considerations for a new generation of protocols. In ACM SIGCOMM, pages 200-208, 1990. [GG07] Yunhong Gu and Robert L. Grossman, UDT: UDP-based Data Transfer for High-Speed Wide Area Networks, Computer Networks (Elsevier). Volume 51, Issue 7. May 2007. [GG05] Yunhong Gu and Robert L. Grossman, Supporting Configurable Congestion Control in Data Transport Services, SC 2005, Nov 12 - 18, Seattle, WA, USA. [GHG04a] Yunhong Gu, Xinwei Hong, and Robert L. Grossman, An Analysis of AIMD Algorithms with Decreasing Increases, First Workshop on Networks for Grid Applications (Gridnets 2004), Oct. 29, San Jose, CA, USA. [GHG04b] Yunhong Gu, Xinwei Hong, and Robert L. Grossman, Experiences in Design and Implementation of a High Performance Transport Protocol, SC 2004, Nov 6 - 12, Pittsburgh, PA, USA. Bernardo, DV et al. Informational [Page 11] [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, October 2004. [KA98] S. Kent, R. Atkinson "Security Architecture for the Internet Protocol", RFC 2401, 1998. [LM97] T. V. Lakshman and U. Madhow, The Performance of TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss, IEEE/ACM Trans. on Networking, vol. 5 no 3, July 1997, pp. 336-350. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2581] Allman, M., Paxson, V. and W. Stevens, TCP Congestion Control, RFC 2581, April 1999. [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Chwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream Control Transmission Protocol. RFC 2960, IETF, October 2000. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [SRC84] J. Saltzer, D. Reed, and D. Clark: End-to-end arguments in system design. ACM Transactions on Computer Systems 2,4, 1984 pages 277-288. [TS06] K. Tan, Jingmin Song, Qian Zhang, Murari Sridharan, A Compound TCP Approach for High-speed and Long Distance Networks, in IEEE Infocom, April 2006, Barcelona, Spain. [UDT] UDT: UDP-based Data Transfer, URL http://udt.sf.net. [XHR04] Lisong Xu, Khaled Harfoush, and Injong Rhee, Binary Increase Congestion Control for Fast Long-Distance Networks, INFOCOM 2004. Author's Addresses Danilo Valeros Bernardo The University of Technology - Sydney Sydney, Australia. Email: dbernard@db2powerhouse.com Doan B. Hoang The University of Technology - Sydney Sydney, Australia. Bernardo, DV et al. Informational [Page 12] Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bernardo, DV et al. Informational [Page 13]