--- 1/draft-ietf-taps-transports-11.txt 2016-10-25 06:16:11.356483678 -0700 +++ 2/draft-ietf-taps-transports-12.txt 2016-10-25 06:16:11.460486215 -0700 @@ -1,53 +1,55 @@ Network Working Group G. Fairhurst, Ed. Internet-Draft University of Aberdeen Intended status: Informational B. Trammell, Ed. -Expires: January 8, 2017 M. Kuehlewind, Ed. +Expires: April 28, 2017 M. Kuehlewind, Ed. ETH Zurich - July 07, 2016 + October 25, 2016 Services provided by IETF transport protocols and congestion control mechanisms - draft-ietf-taps-transports-11 + draft-ietf-taps-transports-12 Abstract This document describes, surveys, classifies and compares the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol - (HTTP), when HTTP is used as a pseudotransport. + (HTTP), when HTTP is used as a pseudotransport. This survey provides + background for the definition of transport services within the TAPS + working group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on January 8, 2017. + This Internet-Draft will expire on April 28, 2017. Copyright Notice Copyright (c) 2016 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 @@ -55,80 +57,80 @@ 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of Transport Features . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 5 + 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 6 3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 6 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 3.1.2. Interface description . . . . . . . . . . . . . . . . 8 3.1.3. Transport Features . . . . . . . . . . . . . . . . . 8 3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 9 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 - 3.2.2. Interface Description . . . . . . . . . . . . . . . . 9 + 3.2.2. Interface Description . . . . . . . . . . . . . . . . 10 3.2.3. Transport features . . . . . . . . . . . . . . . . . 10 3.3. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 10 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 - 3.3.2. Interface Description . . . . . . . . . . . . . . . . 11 + 3.3.2. Interface Description . . . . . . . . . . . . . . . . 12 3.3.3. Transport Features . . . . . . . . . . . . . . . . . 12 - 3.4. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 12 + 3.4. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 13 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 13 3.4.2. Interface Description . . . . . . . . . . . . . . . . 13 - 3.4.3. Transport Features . . . . . . . . . . . . . . . . . 13 + 3.4.3. Transport Features . . . . . . . . . . . . . . . . . 14 3.5. Stream Control Transmission Protocol (SCTP) . . . . . . . 14 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 14 3.5.2. Interface Description . . . . . . . . . . . . . . . . 16 3.5.3. Transport Features . . . . . . . . . . . . . . . . . 19 - 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 19 + 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 20 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 20 3.6.2. Interface Description . . . . . . . . . . . . . . . . 21 - 3.6.3. Transport Features . . . . . . . . . . . . . . . . . 21 + 3.6.3. Transport Features . . . . . . . . . . . . . . . . . 22 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a pseudotransport . . . . . . . . . . . . . . . . . . . . 22 - 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 22 - 3.7.2. Interface Description . . . . . . . . . . . . . . . . 23 + 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 23 + 3.7.2. Interface Description . . . . . . . . . . . . . . . . 24 3.7.3. Transport Features . . . . . . . . . . . . . . . . . 24 3.8. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 25 3.8.1. Protocol Description . . . . . . . . . . . . . . . . 25 3.8.2. Interface Description . . . . . . . . . . . . . . . . 26 - 3.8.3. Transport Features . . . . . . . . . . . . . . . . . 26 + 3.8.3. Transport Features . . . . . . . . . . . . . . . . . 27 3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport . . . . . . . . . . . . . . . . . . . . . 27 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 28 - 3.9.2. Interface Description . . . . . . . . . . . . . . . . 28 + 3.9.2. Interface Description . . . . . . . . . . . . . . . . 29 3.9.3. Transport features . . . . . . . . . . . . . . . . . 29 3.10. File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 30 - 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 30 + 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 31 3.10.2. Interface Description . . . . . . . . . . . . . . . 32 - 3.10.3. Transport Features . . . . . . . . . . . . . . . . . 32 + 3.10.3. Transport Features . . . . . . . . . . . . . . . . . 33 3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 33 - 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 33 - 3.11.2. Interface Description . . . . . . . . . . . . . . . 34 + 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 34 + 3.11.2. Interface Description . . . . . . . . . . . . . . . 35 3.11.3. Transport Features . . . . . . . . . . . . . . . . . 35 - 3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 35 + 3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 36 3.12.1. Protocol Description . . . . . . . . . . . . . . . . 36 - 3.12.2. Interface Description . . . . . . . . . . . . . . . 36 + 3.12.2. Interface Description . . . . . . . . . . . . . . . 37 3.12.3. Transport Features . . . . . . . . . . . . . . . . . 37 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 37 5. Transport Features . . . . . . . . . . . . . . . . . . . . . 38 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 - 10. Informative References . . . . . . . . . . . . . . . . . . . 43 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 + 10. Informative References . . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction Internet applications make use of the Services provided by a Transport protocol, such as TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean the end-to-end service provided to an application by the transport layer. That service can only be provided correctly if information about the intended usage is supplied from the application. The application may determine this @@ -142,20 +144,27 @@ and UDP, including SCTP, DCCP, MPTCP, and UDP-Lite. Transport services may be provided directly by these transport protocols, or layered on top of them using protocols such as WebSockets (which runs over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run over SCTP over DTLS over UDP or TCP). Services built on top of UDP or UDP-Lite typically also need to specify additional mechanisms, including a congestion control mechanism (such as NewReno, TFRC or LEDBAT). This extends the set of available Transport Services beyond those provided to applications by TCP and UDP. + The transport protocols described in this document provide a basis + for the definition of transport services provided by common + protocols, as background for the TAPS working group. The protocols + listed here were chosen to help expose as many potential transport + services as possible, and are not meant to be a comprehensive survey + or classification of all transport protocols. + 1.1. Overview of Transport Features Transport protocols can be differentiated by the features of the services they provide. Some of these provided features are closely related to basic control function that a protocol needs to work over a network path, such as addressing. The number of participants in a given association also determines its applicability: if a connection is between endpoints (unicast), to one of multiple endpoints (anycast), or simultaneously @@ -285,21 +294,21 @@ All TCP senders provide congestion control, such as described in [RFC5681]. TCP uses a sequence number with a sliding receiver window for flow control. The TCP congestion control mechanism also utilises this TCP sequence number to manage a separate congestion window [RFC5681]. The sending window at a given point in time is the minimum of the receiver window and the congestion window. The congestion window is increased in the absence of congestion and, respectively, decreased if congestion is detected. Often loss is implicitly handled as a congestion indication which is detected in TCP (also as input for retransmission handling) based on two - mechanisms: A retransmission timer with exponential back-up or the + mechanisms: A retransmission timer with exponential back-off or the reception of three acknowledgment for the same segment, so called duplicated ACKs (Fast retransmit). In addition, Explicit Congestion Notification (ECN) [RFC3168] can be used in TCP, if supported by both endpoints, that allows a network node to signal congestion without inducing loss. Alternatively, a delay-based congestion control scheme can be used in TCP that reacts to changes in delay as an early indication of congestion as also further described in Section 4. Examples for different kind of congestion control schemes are given in Section 4. @@ -503,24 +511,26 @@ messages from other protocols (e.g., TCP) when sharing the same network path. On transmission, UDP encapsulates each datagram into a single IP packet or several IP packet fragments. This allows a datagram to be larger than the effective path MTU. Fragments are reassembled before delivery to the UDP receiver, making this transparent to the user of the transport service. When the jumbograms are supported, larger messages may be sent without performing fragmentation. - Applications that need to provide fragmentation or that have other - requirements such as receiver flow control, congestion control, - PathMTU discovery/PLPMTUD, support for ECN, etc. need these to be - provided by protocols operating over UDP [I-D.ietf-tsvwg-rfc5405bis]. + Applications that need to provide fragmentation + UDP on its own does not provide support for segmentation, receiver + flow control, congestion control, PathMTU discovery/PLPMTUD, or ECN. + Applications that require these features need to provide them on + their own, or by using a protocol over UDP that provides them + [I-D.ietf-tsvwg-rfc5405bis]. 3.3.2. Interface Description [RFC0768] describes basic requirements for an API for UDP. Guidance on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. A UDP endpoint consists of a tuple of (IP address, port number). De- multiplexing using multiple abstract endpoints (sockets) on the same IP address is supported. The same socket may be used by a single server to interact with multiple clients (note: this behavior differs @@ -1017,25 +1028,26 @@ 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a pseudotransport Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) [RFC6347] are IETF protocols that provide several security-related features to applications. TLS is designed to run on top of a reliable streaming transport protocol (usually TCP), while DTLS is designed to run on top of a best-effort datagram protocol (UDP or DCCP [RFC5238]). At the time of writing, the current version of TLS - is 1.2; which is defined in [RFC5246]. DTLS provides nearly - identical functionality to applications; it is defined in [RFC6347] - and its current version is also 1.2. The TLS protocol evolved from - the Secure Sockets Layer (SSL) protocols developed in the mid-1990s - to support protection of HTTP traffic. + is 1.2, defined in [RFC5246]; work on TLS version 1.3 is nearing + completion. DTLS provides nearly identical functionality to + applications; it is defined in [RFC6347] and its current version is + also 1.2. The TLS protocol evolved from the Secure Sockets Layer + (SSL) protocols developed in the mid-1990s to support protection of + HTTP traffic. While older versions of TLS and DTLS are still in use, they provide weaker security guarantees. [RFC7457] outlines important attacks on TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document that describes secure configurations for TLS and DTLS to counter these attacks. The recommendations are applicable for the vast majority of use cases. 3.7.1. Protocol Description @@ -1647,20 +1661,25 @@ 3.12. Internet Control Message Protocol (ICMP) The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and ICMP for IPv6 [RFC4433] are IETF standards track protocols. It is a connection-less unidirectional protocol that delivers individual messages, without error correction, congestion control, or flow control. Messages may be sent as unicast, IPv4 broadcast or multicast datagrams (IPv4 and IPv6), in addition to anycast datagrams. + While ICMP is not typically described as a transport protocol, it + does position itself over the network layer, and the operation of + other transport protocols can be closely linked to the functions + provided by ICMP. + Transport Protocols and upper layer protocols can use received ICMP messages to help them take appropriate decisions when network or endpoint errors are reported. For example, to implement, ICMP-based Path MTU discovery [RFC1191][RFC1981] or assist in Packetization Layer Path MTU Discovery (PMTUD) [RFC4821]. Such reactions to received messages need to protect from off-path data injection [I-D.ietf-tsvwg-rfc5405bis], to avoid an application receiving packets created by an unauthorized third party. An application therefore needs to ensure that all messages are appropriately validated, by checking the payload of the messages to ensure these @@ -1768,79 +1787,27 @@ priority congestion control methods often react to changes in delay as an earlier indication of congestion. This approach tends to induce less loss than a loss-based method but does generally not compete well with loss-based traffic across shared bottleneck links. Therefore, methods such as LEDBAT [RFC6824], are deployed in the Internet for scavenger traffic that aim to only utilize otherwise unused capacity. 5. Transport Features - The tables below summarize some key features to illustrate the range - of functions provided across the IETF-specified transports. Figure 1 - considers transports that may be directly layered over the network, - and Figure 2 considers transports layered over another transport - service. Features that are permitted, but not required, are marked - as "Poss" indicating that it is possible for the transport service to - offer this feature. - - +---------------+------+------+------+------+------+------+------+ - | Feature | TCP | MPTCP| UDP | UDPL | SCTP | DCCP | ICMP | - +---------------+------+------+------+------+------+------+------+ - | Datagram | No | No | Yes | Yes | Yes | Yes | Yes | - +---------------+------+------+------+------+------+------+------+ - | Conn. Oriented| Yes | Yes | No | No | Yes | Yes | No | - +---------------+------+------+------+------+------+------+------+ - | Reliability | Yes | Yes | No | No | Yes | No | No | - +---------------+------+------+------+------+------+------+------+ - | Partial Rel. | No | No | N/A | N/A | Poss | Yes | N/A | - +---------------+------+------+------+------+------+------+------+ - | Corupt. Tol | No | No | No | Yes | No | Yes | No | - +---------------+------+------+------+------+------+------+------+ - | Cong.Control | Yes | Yes | No | No | Yes | Yes | No | - +---------------+------+------+------+------+------+------+------+ - | Endpoint | 1 | >=1 | >=1 | >=1 | >=1 | 1 | 1 | - +---------------+------+------+------+------+------+------+------+ - | Multicast Cap.| No | No | Yes | Yes | No | No | No | - +---------------+------+------+------+------+------+------+------+ - - Figure 1: Summary comparison: Transport protocols - - +---------------+------+------+------+------+------+ - | Feature |(D)TLS| RTP | HTTP | FLUTE| NORM | - +---------------+------+------+------+------+------+ - | Datagram | Both | Yes | No | No | Both | - +---------------+------+------+------+------+------+ - | Conn. Oriented| Yes | No | Yes | Yes | Yes | - +---------------+------+------+------+------+------+ - | Reliability | Poss | No | Yes | Yes | Poss | - +---------------+------+------+------+------+------+ - | Partial R | No | Poss | No | No | Poss | - +---------------+------+------+------+------+------+ - | Corupt. Tol | No | Poss | No | No | No | - +---------------+------+------+------+------+------+ - | Cong.Control | N/A | Poss | N/A | Poss | Poss | - +---------------+------+------+------+------+------+ - | Endpoint | 1 | >=1 | 1 | >=1 | >=1 | - +---------------+------+------+------+------+------+ - | Multicast Cap.| No | Yes | No | Yes | Yes | - +---------------+------+------+------+------+------+ - - Figure 2: Upper layer transports and frameworks - - The transport protocol features described in this document could be - used as a basis for defining common transport features: + The transport protocol features described in this document can be + used as a basis for defining common transport features, listed below + with the protocols supporting them: o Control Functions * Addressing - + unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP, HTTP, ICMP) + multicast (UDP, UDP-Lite, RTP, FLUTE/ALC, NORM). Note that, as TLS and DTLS are unicast-only, there is no widely deployed mechanism for supporting the features in the Security section below when using multicast addressing. + IPv4 broadcast (UDP, UDP-Lite, ICMP) @@ -1953,21 +1920,21 @@ * authentication of one end of a connection (TLS, DTLS, FLUTE/ ALC) * authentication of both ends of a connection (TLS, DTLS) * confidentiality (TLS, DTLS) * cryptographic integrity protection (TLS, DTLS) - * replay protection (FLUTE/ALC, DTLS) + * replay protection (TLS, DTLS, FLUTE/ALC) 6. IANA Considerations This document has no considerations for IANA. 7. Security Considerations This document surveys existing transport protocols and protocols providing transport-like services. Confidentiality, integrity, and authenticity are among the features provided by those services. This @@ -2426,44 +2393,44 @@ (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [I-D.ietf-tsvwg-rfc5405bis] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage - Guidelines", draft-ietf-tsvwg-rfc5405bis-15 (work in - progress), June 2016. + Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in + progress), October 2016. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-09 (work in progress), January 2015. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", draft-ietf-tsvwg- - sctp-ndata-05 (work in progress), March 2016. + sctp-ndata-07 (work in progress), July 2016. [I-D.ietf-tsvwg-natsupp] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", draft-ietf-tsvwg-natsupp-09 (work in progress), May 2016. [I-D.ietf-tcpm-cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", - draft-ietf-tcpm-cubic-01 (work in progress), January 2016. + draft-ietf-tcpm-cubic-02 (work in progress), August 2016. [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, "XMLHttpRequest working draft (http://www.w3.org/TR/XMLHttpRequest/)", 2000. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Ph. D. (UC Irvine), Chapter 5: Representational State Transfer", 2000. [POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology