[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

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

   The list of Internet-Draft Shadow Directories can be accessed at

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.


   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

   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",
   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    |
     |                 |
     |      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

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.



   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Bernardo, DV et al.           Informational             [Page 13]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/