Internet DRAFT - draft-sec-udt
draft-sec-udt
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]
