draft-ietf-taps-transports-05.txt		draft-ietf-taps-transports-06.txt
	Network Working Group G. Fairhurst, Ed.		Network Working Group G. Fairhurst, Ed.
	Internet-Draft University of Aberdeen		Internet-Draft University of Aberdeen
	Intended status: Informational B. Trammell, Ed.		Intended status: Informational B. Trammell, Ed.
	Expires: December 11, 2015 M. Kuehlewind, Ed.		Expires: January 7, 2016 M. Kuehlewind, Ed.
	ETH Zurich		ETH Zurich
	June 09, 2015		July 06, 2015
	Services provided by IETF transport protocols and congestion control		Services provided by IETF transport protocols and congestion control
	mechanisms		mechanisms
	draft-ietf-taps-transports-05		draft-ietf-taps-transports-06
	Abstract		Abstract
	This document describes services provided by existing IETF protocols		This document describes services provided by existing IETF protocols
	and congestion control mechanisms. It is designed to help		and congestion control mechanisms. It is designed to help
	application and network stack programmers and to inform the work of		application and network stack programmers and to inform the work of
	the IETF TAPS Working Group.		the IETF TAPS Working Group.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 11, 2015.		This Internet-Draft will expire on December 14, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 17		skipping to change at page 2, line 17
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Existing Transport Protocols . . . . . . . . . . . . . . . . 4		3. Existing Transport Protocols . . . . . . . . . . . . . . . . 4
	3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 4		3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 4
	3.1.1. Protocol Description . . . . . . . . . . . . . . . . 5		3.1.1. Protocol Description . . . . . . . . . . . . . . . . 5
	3.1.2. Interface description . . . . . . . . . . . . . . . . 6		3.1.2. Interface description . . . . . . . . . . . . . . . . 6
	3.1.3. Transport Protocol Components . . . . . . . . . . . . 6		3.1.3. Transport Protocol Components . . . . . . . . . . . . 6
	3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 7		3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 7
	3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7		3.2.1. Protocol Description . . . . . . . . . . . . . . . . 8
	3.2.2. Interface Description . . . . . . . . . . . . . . . . 7		3.2.2. Interface Description . . . . . . . . . . . . . . . . 8
	3.2.3. Transport Protocol Components . . . . . . . . . . . . 8		3.2.3. Transport Protocol Components . . . . . . . . . . . . 8
	3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 9		3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 9
	3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9		3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9
	3.3.2. Interface Description . . . . . . . . . . . . . . . . 11		3.3.2. Interface Description . . . . . . . . . . . . . . . . 11
	3.3.3. Transport Protocol Components . . . . . . . . . . . . 13		3.3.3. Transport Protocol Components . . . . . . . . . . . . 13
	3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 13		3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 13
	3.4.1. Protocol Description . . . . . . . . . . . . . . . . 14		3.4.1. Protocol Description . . . . . . . . . . . . . . . . 14
	3.4.2. Interface Description . . . . . . . . . . . . . . . . 14		3.4.2. Interface Description . . . . . . . . . . . . . . . . 14
	3.4.3. Transport Protocol Components . . . . . . . . . . . . 15		3.4.3. Transport Protocol Components . . . . . . . . . . . . 15
	3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 15		3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 15
	skipping to change at page 2, line 44		skipping to change at page 2, line 44
	3.6.2. Interface Description . . . . . . . . . . . . . . . . 19		3.6.2. Interface Description . . . . . . . . . . . . . . . . 19
	3.6.3. Transport Protocol Components . . . . . . . . . . . . 19		3.6.3. Transport Protocol Components . . . . . . . . . . . . 19
	3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 19		3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 19
	3.8. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 20		3.8. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 20
	3.8.1. Protocol Description . . . . . . . . . . . . . . . . 20		3.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
	3.8.2. Interface Description . . . . . . . . . . . . . . . . 21		3.8.2. Interface Description . . . . . . . . . . . . . . . . 21
	3.8.3. Transport Protocol Components . . . . . . . . . . . . 21		3.8.3. Transport Protocol Components . . . . . . . . . . . . 21
	3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as		3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as
	a pseudotransport . . . . . . . . . . . . . . . . . . . . 22		a pseudotransport . . . . . . . . . . . . . . . . . . . . 22
	3.9.1. Protocol Description . . . . . . . . . . . . . . . . 23		3.9.1. Protocol Description . . . . . . . . . . . . . . . . 23
	3.9.2. Interface Description . . . . . . . . . . . . . . . . 23		3.9.2. Interface Description . . . . . . . . . . . . . . . . 24
			3.9.3. Transport Protocol Components . . . . . . . . . . . . 24
	3.10. Hypertext Transport Protocol (HTTP) over TCP as a		3.10. Hypertext Transport Protocol (HTTP) over TCP as a
	pseudotransport . . . . . . . . . . . . . . . . . . . . . 24		pseudotransport . . . . . . . . . . . . . . . . . . . . . 25
	3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25		3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25
	3.10.2. Interface Description . . . . . . . . . . . . . . . 26		3.10.2. Interface Description . . . . . . . . . . . . . . . 26
	3.10.3. Transport Protocol Components . . . . . . . . . . . 26		3.10.3. Transport Protocol Components . . . . . . . . . . . 27
	3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 27		3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 27
	3.11.1. Protocol Description . . . . . . . . . . . . . . . . 27		3.11.1. Protocol Description . . . . . . . . . . . . . . . . 27
	3.11.2. Interface Description . . . . . . . . . . . . . . . 27		3.11.2. Interface Description . . . . . . . . . . . . . . . 27
	3.11.3. Transport Protocol Components . . . . . . . . . . . 27		3.11.3. Transport Protocol Components . . . . . . . . . . . 28
	4. Transport Service Features . . . . . . . . . . . . . . . . . 27		4. Transport Service Features . . . . . . . . . . . . . . . . . 28
	4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 29		4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 30
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 31		6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.1. Normative References . . . . . . . . . . . . . . . . . . 32		9.1. Normative References . . . . . . . . . . . . . . . . . . 33
	9.2. Informative References . . . . . . . . . . . . . . . . . 32		9.2. Informative References . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	Most Internet applications make use of the Transport Services		Most Internet applications make use of the Transport Services
	provided by TCP (a reliable, in-order stream protocol) or UDP (an		provided by TCP (a reliable, in-order stream protocol) or UDP (an
	unreliable datagram protocol). We use the term "Transport Service"		unreliable datagram protocol). We use the term "Transport Service"
	to mean the end-to-end service provided to an application by the		to mean the end-to-end service provided to an application by the
	transport layer. That service can only be provided correctly if		transport layer. That service can only be provided correctly if
	information about the intended usage is supplied from the		information about the intended usage is supplied from the
	application. The application may determine this information at		application. The application may determine this information at
	skipping to change at page 6, line 42		skipping to change at page 6, line 42
	In API implementations derived from the BSD Sockets API, TCP sockets		In API implementations derived from the BSD Sockets API, TCP sockets
	are created using the "SOCK_STREAM" socket type.		are created using the "SOCK_STREAM" socket type.
	The features used by a protocol instance may be set and tuned via		The features used by a protocol instance may be set and tuned via
	this API.		this API.
	(more on the API goes here)		(more on the API goes here)
	3.1.3. Transport Protocol Components		3.1.3. Transport Protocol Components
	The transport protocol components provided by TCP are:		The transport protocol components provided by TCP (new version) are:
	o unicast
	o connection setup with feature negotiation and application-to-port		[EDITOR'S NOTE: discussion of how to map this to features and TAPS:
	mapping		what does the higher layer need to decide? what can the transport
			layer decide based on global settings? what must the transport layer
			decide based on network characteristics?]
	o port multiplexing		o Connection-oriented bidirectional communication using three-way
			handshake connection setup with feature negotiation and an
			explicit distinction between passive and active open: This implies
			both unicast addressing and a guarantee of return routability.
	o reliable delivery		o Single stream-oriented transmission: The stream abstraction atop
	o error detection (checksum)		the datagram service provided by IP is implemented by dividing the
			stream into segments.
	o segmentation		o Limited control over segment transmission scheduling (Nagle's
			algorithm): This allows for delay minimization in interactive
			applications by preventing the transport to add additional delays
			(by deactivating Nagle's algorithm).
	o stream-oriented delivery in a single stream		o Port multiplexing, with application-to-port mapping during
			connection setup: Note that in the presence of network address and
			port translation (NAPT), TCP ports are in effect part of the
			endpoint address for forwarding purposes.
	o data bundling (Nagle's algorithm)		o Full reliability using (S)ACK- and RTO-based loss detection and
			retransmissions: Loss is sensed using duplicated ACKs ("fast
			retransmit"), which places a lower bound on the delay inherent in
			this approach to reliability. The retransmission timeout
			determines the upper bound on the delay (expect if also
			exponential back-off is performed). The use of selective
			acknowlegdements further reduces the latency for retransmissions
			if multiple packets are lost during one congestion event.
	o flow control		o Error detection based on a checksum covering the network and
			transport headers as well as payload: Packets that are detected as
			corrupted are dropped, relying on the reliability mechanism to
			retransmit them.
	o congestion control		o Window-based flow control, with receiver-side window management
			and signaling of available window: Scaling the flow control window
			beyond 64kB requires the use of an optional feature, which has
			performance implications in environments where this option is not
			supported; this can be the case either if the receiver does not
			implement window scaling or if a network node on the path strips
			the window scaling option.
	[EDITOR'S NOTE: discussion of how to map this to features and TAPS:		o Window-based congestion control reacting to loss, delay,
	what does the higher layer need to decide? what can the transport		retransmission timeout, or an explicit congestion signal (ECN):
	layer decide based on global settings? what must the transport layer		Most commonly used is a loss signal from the reliability
	decide based on network characteristics?]		component's retransmission mechanism. TCP reacts to a congestion
			signal by reducing the size of the congestion window;
			retransmission timeout is generally handled with a larger reaction
			than other signals.
	3.2. Multipath TCP (MPTCP)		3.2. Multipath TCP (MPTCP)
	Multipath TCP [RFC6824] is an extension for TCP to support multi-		Multipath TCP [RFC6824] is an extension for TCP to support multi-
	homing. It is designed to be as transparent as possible to middle-		homing. It is designed to be as transparent as possible to middle-
	boxes. It does so by establishing regular TCP flows between a pair		boxes. It does so by establishing regular TCP flows between a pair
	of source/destination endpoints, and multiplexing the application's		of source/destination endpoints, and multiplexing the application's
	stream over these flows.		stream over these flows.
	3.2.1. Protocol Description		3.2.1. Protocol Description
	skipping to change at page 8, line 23		skipping to change at page 8, line 50
	additionally provide soft failover solutions should one of the paths		additionally provide soft failover solutions should one of the paths
	become unusable. In addition, by multiplexing one byte stream over		become unusable. In addition, by multiplexing one byte stream over
	separate paths, it can achieve a higher throughput than TCP in		separate paths, it can achieve a higher throughput than TCP in
	certain situations (note however that coupled congestion control		certain situations (note however that coupled congestion control
	[RFC6356] might limit this benefit to maintain fairness to other		[RFC6356] might limit this benefit to maintain fairness to other
	flows at the bottleneck). When aggregating capacity over multiple		flows at the bottleneck). When aggregating capacity over multiple
	paths, and depending on the way packets are scheduled on each TCP		paths, and depending on the way packets are scheduled on each TCP
	subflow, an additional delay and higher jitter might be observed		subflow, an additional delay and higher jitter might be observed
	observed before in-order delivery of data to the applications.		observed before in-order delivery of data to the applications.
	The transport protocol components provided by MPTCP therefore are:		The transport protocol components provided by MPTCP in addition to
			TCP therefore are:
	o unicast
	o connection setup with feature negotiation and application-to-port
	mapping
	o port multiplexing
	o reliable delivery
	o error detection (checksum)
	o segmentation
	o stream-oriented delivery in a single stream
	o flow control
	o congestion control		o congestion control with load balancing over mutiple connections
	o endpoint multiplexing of a single byte stream (higher throughput)		o endpoint multiplexing of a single byte stream (higher throughput)
	o resilience to network failure and/or handovers		o resilience to network failure and/or handoverss
	[AUTHOR'S NOTE: it is unclear whether MPTCP has to provide data		[AUTHOR'S NOTE: it is unclear whether MPTCP has to provide data
	bundling.] [AUTHOR'S NOTE: AF muliplexing? sub-flows can be started		bundling.] [AUTHOR'S NOTE: AF muliplexing? sub-flows can be started
	over IPv4 or IPv6 for the same session]		over IPv4 or IPv6 for the same session]
	3.3. Stream Control Transmission Protocol (SCTP)		3.3. Stream Control Transmission Protocol (SCTP)
	SCTP is a message oriented standards track transport protocol and the		SCTP is a message oriented standards track transport protocol and the
	base protocol is specified in [RFC4960]. It supports multi-homing to		base protocol is specified in [RFC4960]. It supports multi-homing to
	handle path failures. An SCTP association has multiple		handle path failures. An SCTP association has multiple
	skipping to change at page 16, line 25		skipping to change at page 16, line 33
	As for UDP, mechanisms for receiver flow control, congestion control,		As for UDP, mechanisms for receiver flow control, congestion control,
	PMTU or PLPMTU discovery, support for ECN, etc need to be provided by		PMTU or PLPMTU discovery, support for ECN, etc need to be provided by
	upper layer protocols [RFC5405].		upper layer protocols [RFC5405].
	Examples of use include a class of applications that can derive		Examples of use include a class of applications that can derive
	benefit from having partially-damaged payloads delivered, rather than		benefit from having partially-damaged payloads delivered, rather than
	discarded. One use is to support error tolerate payload corruption		discarded. One use is to support error tolerate payload corruption
	when used over paths that include error-prone links, another		when used over paths that include error-prone links, another
	application is when header integrity checks are required, but payload		application is when header integrity checks are required, but payload
	integrity is provided by some other mechanism (e.g. [RFC6936].		integrity is provided by some other mechanism (e.g. [RFC6936].
	A UDP-Lite service may support IPv4 broadcast, multicast, anycast and		A UDP-Lite service may support IPv4 broadcast, multicast, anycast and
	unicast.		unicast.
	3.5.2. Interface Description		3.5.2. Interface Description
	There is no current API specified in the RFC Series, but guidance on		There is no current API specified in the RFC Series, but guidance on
	use of common APIs is provided in [RFC5405].		use of common APIs is provided in [RFC5405].
	The interface of UDP-Lite differs from that of UDP by the addition of		The interface of UDP-Lite differs from that of UDP by the addition of
	skipping to change at page 18, line 46		skipping to change at page 19, line 6
	defined [RFC6773] that permits DCCP to be used over paths where it is		defined [RFC6773] that permits DCCP to be used over paths where it is
	not natively supported. Support in NAPT/NATs is defined in [RFC4340]		not natively supported. Support in NAPT/NATs is defined in [RFC4340]
	and [RFC5595].		and [RFC5595].
	Upper layer protocols specified on top of DCCP include: DTLS		Upper layer protocols specified on top of DCCP include: DTLS
	[RFC5595], RTP [RFC5672], ICE/SDP [RFC6773].		[RFC5595], RTP [RFC5672], ICE/SDP [RFC6773].
	A DCCP service is unicast.		A DCCP service is unicast.
	A common packet format has allowed tools to evolve that can read and		A common packet format has allowed tools to evolve that can read and
	interpret DCCP packets (e.g. Wireshark).		interpret DCCP packets (e.g. Wireshark).
	3.6.2. Interface Description		3.6.2. Interface Description
	API characteristics include: - Datagram transmission. - Notification		API characteristics include: - Datagram transmission. - Notification
	of the current maximum packet size. - Send and reception of zero-		of the current maximum packet size. - Send and reception of zero-
	length payloads. - Set the Slow Receiver flow control at a receiver.		length payloads. - Set the Slow Receiver flow control at a receiver.
	- Detect a Slow receiver at the sender.		- Detect a Slow receiver at the sender.
	There is no current API specified in the RFC Series.		There is no current API specified in the RFC Series.
	skipping to change at page 22, line 27		skipping to change at page 22, line 27
	o flow control (timer-based and/or ack-based)		o flow control (timer-based and/or ack-based)
	o congestion control		o congestion control
	o packet erasure coding (both proactively and as part of ARQ)		o packet erasure coding (both proactively and as part of ARQ)
	3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a		3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a
	pseudotransport		pseudotransport
	Transport Layer Security (TLS) and Datagram TLS are IETF protocols		Transport Layer Security (TLS) and Datagram TLS (DTLS) are IETF
	that provide several security-related features to applications. TLS		protocols that provide several security-related features to
	is designed to run on top of TCP, DTLS is designed to run on top of		applications. TLS is designed to run on top of a reliable streaming
	UDP. At the time of writing, the current version of TLS is 1.2; it		transport protocol (usually TCP), while DTLS is designed to run on
	is defined in [RFC5246]. DTLS provides nearly identical		top of a best-effort datagram protocol (usually UDP). At the time of
	functionality; it is defined in {RFC6347}} and also at version 1.2.		writing, the current version of TLS is 1.2; it 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 90s to support protection of
			HTTP traffic.
	While older versions of TLS and DTLS are still in use, they provide		While older versions of TLS and DTLS are still in use, they provide
	weaker security guarantees. [RFC7457] outlines important attacks on		weaker security guarantees. [RFC7457] outlines important attacks on
	TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document		TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document
	that describes secure configurations for TLS and DTLS to counter		that describes secure configurations for TLS and DTLS to counter
	these attacks. The recommendations are applicable for the vast		these attacks. The recommendations are applicable for the vast
	majority of use cases.		majority of use cases.
	[NOTE: The Logjam authors (weakdh.org) give (inconclusive) evidence		[NOTE: The Logjam authors (weakdh.org) give (inconclusive) evidence
	that one of the recommendations of [RFC7525], namely use to DHE-1024		that one of the recommendations of [RFC7525], namely the use of
	as a fallback, may not be sufficient in all cases to counter an		DHE-1024 as a fallback, may not be sufficient in all cases to counter
	attacker with the resources of a nation-state. It is unclear at this		an attacker with the resources of a nation-state. It is unclear at
	time if the RFC is going to be updated as a result or whether there		this time if the RFC is going to be updated as a result, or whether
	will be an RFC7525bis.]		there will be an RFC7525bis.]
	3.9.1. Protocol Description		3.9.1. Protocol Description
	Both TLS and DTLS provide the same security features and can thus be		Both TLS and DTLS provide the same security features and can thus be
	discussed together. The features they provide are:		discussed together. The features they provide are:
	o Confidentiality		o Confidentiality
	o Data integrity		o Data integrity
	o Data authenticity		o Peer authentication (optional)
	o Optionally authentication of the peer entity
	[Note: Both TLS and DTLS provide replay protection, although it is		o Perfect forward secrecy (optional)
	optional in DTLS. The TLS RFC discusses this only in the security
	considerations and thus views it as a feature that is implicit in the
	ones listed above. DTLS mentions it as an explicit feature.]
	The authentication of the peer entity can be omitted, although this		The authentication of the peer entity can be omitted; a common web
	is a rare use case. In many use cases (e.g. the Web), authentication		use case is where the server is authenticated and the client is not.
	is not mutual, however (e.g. only the Web server is authenticated,		TLS also provides a completely anonymous operation mode in which
	but not the client). It is important to note that TLS itself does		neither peer's identity is authenticated. It is important to note
	not specify how a peering entity is to be authenticated. This is		that TLS itself does not specify how a peering entity's identity
	part of the application logic; i.e. the authentication decision rests		should be interpreted. For example, in the common use case of
	with the application. As an example, in the common use case of
	authentication by means of an X.509 certificate, it is the		authentication by means of an X.509 certificate, it is the
	application's decision whether the certificate of the peering entity		application's decision whether the certificate of the peering entity
	is acceptable for the purposes of the application or whether the		is acceptable for authorization decisions. Perfect forward secrecy,
	handshake should be aborted.		if enabled and supported by the selected algorithms, ensures that
			traffic encrypted and captured during a session at time t0 cannot be
			later decrypted at time t1 (t1 > t0), even if the long-term secrets
			of the communicating peers are later compromised.
	As DTLS is used over the unreliable UDP transport, it needs to add		As DTLS is generally used over an unreliable datagram transport such
	three features to provide the same security guarantees as TLS: *		as TCP, applications will need to tolerate loss, re-ordered, or
	Message fragmentation * Message reordering * Message loss		duplicated datagrams. Like TLS, DTLS conveys application data in a
			sequence of independent records. However, because records are mapped
			to unreliable datagrams, there are several features unique to DTLS
			that are not applicable to TLS:
	As a result, DTLS provides features that UDP lacks.		o Record replay detection (optional)
	[EDITOR'S NOTE: Need to describe how this is achieved?]		o Record size negotiation (estimates of PMTU and record size
			expansion factor)
			o Coveyance of IP don't fragment (DF) bit settings by application
			o An anti-DoS stateless cookie mechanism (optional)
			Generally, DTLS follows the TLS design as closely as possible. To
			operate over datagrams, DTLS includes a sequence number and limited
			forms of retransmission and fragmentation for its internal
			operations. The sequence number may be used for detecting replayed
			information, according to the windowing procedure described in
			Section 4.1.2.6 of [RFC6347]. Note also that DTLS bans the use of
			stream ciphers, which are essentially incompatible when operating on
			independent encrypted records.
	3.9.2. Interface Description		3.9.2. Interface Description
	TLS is commonly used with a socket-like interface, although details		TLS is commonly invoked using an API provided by packages such as
	can vary between implementations. This is particularly true for the		OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the
	choice which cryptographic algorithms to use, see below.		manipulation of several important abstractions, which fall into the
			following categories: long-term keys and algorithms, session state,
			and communications/connections. There may also be special APIs
			required to deal with time and/or random numbers, both of which are
			needed by a variety of encryption algorithms and protocols.
	[TODO: DTLS interface]		Considerable care is required in the use of TLS APIs in order to
	Both TLS and DTLS allow to employ a multitude of cipher suites for		create a secure application. The programmer should have at least a
	encryption, hashing and applying message integrity. It is no easy		basic understanding of encryption and digital signature algorithms
	task to choose safe settings here. [RFC7525] provides guidance.		and their strengths, public key infrastructure (including X.509
			certificates and certificate revocation), and the sockets API. See
			[RFC7525] and [RFC7457], as mentioned above.
	[TODO: list the RFCs?] [TODO: more detail?] ### Transport Protocol		As an example, in the case of OpenSSL, the primary abstractions are
	Components		the library itself and method (protocol), session, context, cipher
			and connection. After initializing the library and setting the
			method, a cipher suite is chosen and used to configure a context
			object. Session objects may then be minted according to the
			parameters present in a context object and associated with individual
			connections. Depending on how precisely the programmer wishes to
			select different algorithmic or protocol options, various levels of
			details may be required.
			3.9.3. Transport Protocol Components
	Both TLS and DTLS employ a layered architecture. The lower layer is		Both TLS and DTLS employ a layered architecture. The lower layer is
	commonly called the record protocol. It is responsible for		commonly called the record protocol. It is responsible for
	fragmenting messages, applying message authentication codes (MACs),		fragmenting messages, applying message authentication codes (MACs),
	encrypting data, and sending it via the underlying transport		encrypting data, and invoking transmission from the underlying
	protocol. Several essential protocols run on top of the record		transport protocol. DTLS augments the TLS record protocol with
	protocol in order to carry out the handshake and establish a secure		sequence numbers used for ordering and replay detection.
	session.
	[EDITOR'S NOTE: TLS can also compress, but this has been found to be		Several protocols are layered on top of the record protocol. These
	a security weakness. It is not described here.]		include the handshake, alert, and change cipher spec protocols.
			There is also the data protocol, used to carry application traffic.
			The handshake protocol is used to establish cryptographic and
			compression parameters when a connection is first set up. In DTLS,
			this protocol also has a basic fragmentation and retransmission
			capability and a cookie-like mechanism to resist DoS attacks. (TLS
			compression is not recommended at present). The alert protocol is
			used to inform the peer of various conditions, most of which are
			terminal for the connection. The change cipher spec protocol is used
			to synchronize changes in cryptographic parameters for each peer.
	3.10. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport		3.10. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport
	Hypertext Transfer Protocol (HTTP) is an application-level protocol		Hypertext Transfer Protocol (HTTP) is an application-level protocol
	widely used on the Internet. Version 1.1 of the protocol is		widely used on the Internet. Version 1.1 of the protocol is
	specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234]		specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234]
	[RFC7235], and version 2 in [RFC7540]. Furthermore, HTTP is used as		[RFC7235], and version 2 in [RFC7540]. Furthermore, HTTP is used as
	a substrate for other application-layer protocols. There are various		a substrate for other application-layer protocols. There are various
	reasons for this practice listed in [RFC3205]; these include being a		reasons for this practice listed in [RFC3205]; these include being a
	well-known and well-understood protocol, reusability of existing		well-known and well-understood protocol, reusability of existing
	servers and client libraries, easy use of existing security		servers and client libraries, easy use of existing security
	mechanisms such as HTTP digest authentication [RFC2617] and TLS		mechanisms such as HTTP digest authentication [RFC2617] and TLS
	[RFC5246], the ability of HTTP to traverse firewalls which makes it		[RFC5246], the ability of HTTP to traverse firewalls which makes it
	work with a lot of infrastructure, and cases where a application		work with a lot of infrastructure, and cases where a application
	server often needs to support HTTP anyway.		server often needs to support HTTP anyway.
	Depending on application's needs, the use of HTTP as a substrate		Depending on application's needs, the use of HTTP as a substrate
	protocol may add complexity and overhead in comparison to a special-		protocol may add complexity and overhead in comparison to a special-
	purpose protocol (e.g. HTTP headers, suitability of the HTTP		purpose protocol (e.g. HTTP headers, suitability of the HTTP security
	security model etc.). [RFC3205] address this issues and provides		model etc.). [RFC3205] address this issues and provides some
	some guidelines and concerns about the use of HTTP standard port 80		guidelines and concerns about the use of HTTP standard port 80 and
	and 443, the use of HTTP URL scheme and interaction with existing		443, the use of HTTP URL scheme and interaction with existing
	firewalls, proxies and NATs.		firewalls, proxies and NATs.
	Though not strictly bound to TCP, HTTP is almost exclusively run over		Though not strictly bound to TCP, HTTP is almost exclusively run over
	TCP, and therefore inherits its properties when used in this way.		TCP, and therefore inherits its properties when used in this way.
	3.10.1. Protocol Description		3.10.1. Protocol Description
	Hypertext Transfer Protocol (HTTP) is a request/response protocol. A		Hypertext Transfer Protocol (HTTP) is a request/response protocol. A
	client sends a request containing a request method, URI and protocol		client sends a request containing a request method, URI and protocol
	version followed by a MIME-like message (see [RFC7231] for the		version followed by a MIME-like message (see [RFC7231] for the
	skipping to change at page 25, line 49		skipping to change at page 26, line 30
	(denoted by HTTPS), which adds protocol properties provided by such a		(denoted by HTTPS), which adds protocol properties provided by such a
	mechanism (e.g. authentication, encryption, etc.). TLS's		mechanism (e.g. authentication, encryption, etc.). TLS's
	Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can		Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can
	be used for HTTP version negotiation within TLS handshake which		be used for HTTP version negotiation within TLS handshake which
	eliminates addition round-trip. Arbitrary cookie strings, included		eliminates addition round-trip. Arbitrary cookie strings, included
	as part of the MIME headers, are often used as bearer tokens in HTTP.		as part of the MIME headers, are often used as bearer tokens in HTTP.
	Application layer protocols using HTTP as substrate may use existing		Application layer protocols using HTTP as substrate may use existing
	method and data formats, or specify new methods and data formats.		method and data formats, or specify new methods and data formats.
	Furthermore some protocols may not fit a request/response paradigm		Furthermore some protocols may not fit a request/response paradigm
	and instead rely on HTTP to send messages (e.g. [RFC6546]). Because		and instead rely on HTTP to send messages (e.g. [RFC6546]). Because
	HTTP is working in many restricted infrastructures, it is also used		HTTP is working in many restricted infrastructures, it is also used
	to tunnel other application-layer protocols.		to tunnel other application-layer protocols.
	3.10.2. Interface Description		3.10.2. Interface Description
	There are many HTTP libraries available exposing different APIs. The		There are many HTTP libraries available exposing different APIs. The
	APIs provide a way to specify a request by providing a URI, a method,		APIs provide a way to specify a request by providing a URI, a method,
	request modifiers and optionally a request body. For the response,		request modifiers and optionally a request body. For the response,
	callbacks can be registered that will be invoked when the response is		callbacks can be registered that will be invoked when the response is
	received. If TLS is used, API expose a registration of callbacks in		received. If TLS is used, API expose a registration of callbacks in
	skipping to change at page 27, line 16		skipping to change at page 28, line 4
	3.11. WebSockets		3.11. WebSockets
	[RFC6455]		[RFC6455]
	[EDITOR'S NOTE: Salvatore Loreto will contribute text for this		[EDITOR'S NOTE: Salvatore Loreto will contribute text for this
	section.]		section.]
	3.11.1. Protocol Description		3.11.1. Protocol Description
	3.11.2. Interface Description		3.11.2. Interface Description
	3.11.3. Transport Protocol Components		3.11.3. Transport Protocol Components
	4. Transport Service Features		4. Transport Service Features
			[EDITOR'S NOTE: This section is still work-in-progress. This list is
			probably not complete and/or too detailed.]
	The transport protocol components analyzed in this document which can		The transport protocol components analyzed in this document which can
	be used as a basis for defining common transport service features,		be used as a basis for defining common transport service features,
	normalized and separated into categories, are as follows:		normalized and separated into categories, are as follows:
	o Destination selection		o Control Functions
	* unicast		* Addressing
	* broadcast (IPv4 only)		+ unicast
	* multicast		+ broadcast (IPv4 only)
	* anycast		+ multicast
	* transport layer multihoming for resilience		+ anycast
	* transport layer mobility		+ something on ports and NAT
	* port multiplexing		* Multihoming support
	* service codes		+ multihoming for resilience
	o Connection setup		+ multihoming for mobility
	* connection setup with feature negotiation and application-to-		- specify handover latency?
	port mapping
	o Delivery		+ multihoming for load-balancing
	* reliable delivery		- specify interleaving delay?
	* partially reliable delivery
	* unreliable delivery		* Multiplexing
	* packet erasure coding		+ application to port mapping
	* ordered delivery		+ single vs. multiple streaming
	* unordered delivery		o Delivery
	* stream-oriented delivery		* reliability
	* message-oriented delivery		+ reliable delivery
			+ partially reliable delivery
	* message fragmentation		- packet erasure coding
	* object-oriented delivery of discrete data or file items		+ unreliable delivery
	* unordered delivery of in-memory data or file bulk content		- drop notification
	objects
	* object range request		- Integrity protection
	* object content type negotiation		o checksum for error detection
	* single streaming		o partial checksum protection
	* multiple streaming		o checksum optional
	* stream scheduling prioritization		* ordering
	* segmentation		+ ordered delivery
	* data bundling (Nagle's algorithm)		+ unordered delivery
	* message bundling		- unordered delivery of in-memory data
	o Transmission control		* type/framing
	* timer-based rate control		+ stream-oriented delivery
	* ack-based flow control		+ message-oriented delivery
	* drop notification		+ object-oriented delivery of discrete data or file items
	* packet erasure coding		- object content type negotiation
	* congestion control		+ range-based partical object transmission
	o Integrity protection		+ file bulk content objects
	* checksum for error detection		o Transmission control
	* partial checksum protection		* rate control
	* checksum optional		+ timer-based
	* cryptographic integrity protection		+ ACK-based
			* congestion control
			* flow control
			* segmentation
			* data/message bundling (Nagle's algorithm)
			* stream scheduling prioritization
	o Security		o Security
	* authentication of one end of a connection		* authentication of one end of a connection
	* authentication of both ends of a connection		* authentication of both ends of a connection
	* confidentiality		* confidentiality
			* cryptographic integrity protection
	The next revision of this document will define transport service		The next revision of this document will define transport service
	features based upon this list.		features based upon this list.
	[EDITOR'S NOTE: this section will drawn from the candidate features		[EDITOR'S NOTE: this section will drawn from the candidate features
	provided by protocol components in the previous section - please		provided by protocol components in the previous section - please
	discuss on taps@ietf.org list]		discuss on taps@ietf.org list]
	4.1. Complete Protocol Feature Matrix		4.1. Complete Protocol Feature Matrix
	[EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this		[EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this
	skipping to change at page 37, line 26		skipping to change at page 38, line 26
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,		[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, May 2015.		(DTLS)", BCP 195, RFC 7525, May 2015.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer		[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
	Protocol Version 2 (HTTP/2)", RFC 7540, May 2015.		Protocol Version 2 (HTTP/2)", RFC 7540, May 2015.
	[I-D.ietf-aqm-ecn-benefits]		[I-D.ietf-aqm-ecn-benefits]
	Welzl, M. and G. Fairhurst, "The Benefits and Pitfalls of		Fairhurst, G. and M. Welzl, "The Benefits of using
	using Explicit Congestion Notification (ECN)", draft-ietf-		Explicit Congestion Notification (ECN)", draft-ietf-aqm-
	aqm-ecn-benefits-00 (work in progress), October 2014.		ecn-benefits-05 (work in progress), June 2015.
	[I-D.ietf-tsvwg-sctp-dtls-encaps]		[I-D.ietf-tsvwg-sctp-dtls-encaps]
	Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS		Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
	Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-		Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
	dtls-encaps-09 (work in progress), January 2015.		dtls-encaps-09 (work in progress), January 2015.
	[I-D.ietf-tsvwg-sctp-prpolicies]		[I-D.ietf-tsvwg-sctp-prpolicies]
	Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,		Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
	"Additional Policies for the Partial Reliability Extension		"Additional Policies for the Partial Reliability Extension
	of the Stream Control Transmission Protocol", draft-ietf-		of the Stream Control Transmission Protocol", draft-ietf-
End of changes. 87 change blocks.
	156 lines changed or deleted		223 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/