draft-ietf-taps-transports-04.txt		draft-ietf-taps-transports-05.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: November 28, 2015 M. Kuehlewind, Ed.		Expires: December 11, 2015 M. Kuehlewind, Ed.
	ETH Zurich		ETH Zurich
	May 27, 2015		June 09, 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-04		draft-ietf-taps-transports-05
	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 November 28, 2015.		This Internet-Draft will expire on December 11, 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 16		skipping to change at page 2, line 16
	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 (MP-TCP) . . . . . . . . . . . . . . . . . 7		3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 7
	3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 7		3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7
	3.3.1. Protocol Description . . . . . . . . . . . . . . . . 8		3.2.2. Interface Description . . . . . . . . . . . . . . . . 7
	3.3.2. Interface Description . . . . . . . . . . . . . . . . 10		3.2.3. Transport Protocol Components . . . . . . . . . . . . 8
	3.3.3. Transport Protocol Components . . . . . . . . . . . . 11		3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 9
	3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 12		3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9
	3.4.1. Protocol Description . . . . . . . . . . . . . . . . 12		3.3.2. Interface Description . . . . . . . . . . . . . . . . 11
	3.4.2. Interface Description . . . . . . . . . . . . . . . . 13		3.3.3. Transport Protocol Components . . . . . . . . . . . . 13
	3.4.3. Transport Protocol Components . . . . . . . . . . . . 13		3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 13
	3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 14		3.4.1. Protocol Description . . . . . . . . . . . . . . . . 14
	3.5.1. Protocol Description . . . . . . . . . . . . . . . . 14		3.4.2. Interface Description . . . . . . . . . . . . . . . . 14
	3.5.2. Interface Description . . . . . . . . . . . . . . . . 15		3.4.3. Transport Protocol Components . . . . . . . . . . . . 15
	3.5.3. Transport Protocol Components . . . . . . . . . . . . 15		3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 15
	3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 15		3.5.1. Protocol Description . . . . . . . . . . . . . . . . 15
	3.6.1. Protocol Description . . . . . . . . . . . . . . . . 16		3.5.2. Interface Description . . . . . . . . . . . . . . . . 16
	3.6.2. Interface Description . . . . . . . . . . . . . . . . 17		3.5.3. Transport Protocol Components . . . . . . . . . . . . 16
	3.6.3. Transport Protocol Components . . . . . . . . . . . . 17		3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 17
	3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 18		3.6.1. Protocol Description . . . . . . . . . . . . . . . . 17
	3.8. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 18		3.6.2. Interface Description . . . . . . . . . . . . . . . . 19
	3.8.1. Protocol Description . . . . . . . . . . . . . . . . 18		3.6.3. Transport Protocol Components . . . . . . . . . . . . 19
	3.8.2. Interface Description . . . . . . . . . . . . . . . . 19		3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 19
	3.8.3. Transport Protocol Components . . . . . . . . . . . . 20		3.8. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 20
			3.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
			3.8.2. Interface Description . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 20		a pseudotransport . . . . . . . . . . . . . . . . . . . . 22
	3.9.1. Protocol Description . . . . . . . . . . . . . . . . 21		3.9.1. Protocol Description . . . . . . . . . . . . . . . . 23
	3.9.2. Interface Description . . . . . . . . . . . . . . . . 21		3.9.2. Interface Description . . . . . . . . . . . . . . . . 23
	3.9.3. Transport Protocol Components . . . . . . . . . . . . 21
	3.10. Hypertext Transport Protocol (HTTP) over TCP as a		3.10. Hypertext Transport Protocol (HTTP) over TCP as a
	pseudotransport . . . . . . . . . . . . . . . . . . . . . 21		pseudotransport . . . . . . . . . . . . . . . . . . . . . 24
	3.10.1. Protocol Description . . . . . . . . . . . . . . . . 21		3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25
	3.10.2. Interface Description . . . . . . . . . . . . . . . 22		3.10.2. Interface Description . . . . . . . . . . . . . . . 26
	3.10.3. Transport Protocol Components . . . . . . . . . . . 23		3.10.3. Transport Protocol Components . . . . . . . . . . . 26
	3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 23		3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 27
	3.11.1. Protocol Description . . . . . . . . . . . . . . . . 23		3.11.1. Protocol Description . . . . . . . . . . . . . . . . 27
	3.11.2. Interface Description . . . . . . . . . . . . . . . 24		3.11.2. Interface Description . . . . . . . . . . . . . . . 27
	3.11.3. Transport Protocol Components . . . . . . . . . . . 24		3.11.3. Transport Protocol Components . . . . . . . . . . . 27
			4. Transport Service Features . . . . . . . . . . . . . . . . . 27
	4. Transport Service Features . . . . . . . . . . . . . . . . . 24		4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 29
	4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 26		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 28		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		9.1. Normative References . . . . . . . . . . . . . . . . . . 32
	9.1. Normative References . . . . . . . . . . . . . . . . . . 28		9.2. Informative References . . . . . . . . . . . . . . . . . 32
	9.2. Informative References . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	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 4, line 11		skipping to change at page 4, line 11
	and unordered message delivery within multiple streams, UDP-Lite		and unordered message delivery within multiple streams, UDP-Lite
	provides partial integrity protection, and LEDBAT can provide low-		provides partial integrity protection, and LEDBAT can provide low-
	priority "scavenger" communication.		priority "scavenger" communication.
	2. Terminology		2. Terminology
	The following terms are defined throughout this document, and in		The following terms are defined throughout this document, and in
	subsequent documents produced by TAPS describing the composition and		subsequent documents produced by TAPS describing the composition and
	decomposition of transport services.		decomposition of transport services.
			[EDITOR'S NOTE: we may want to add definitions for the different
			kinds of interfaces that are important here.]
	Transport Service Feature: a specific end-to-end feature that a		Transport Service Feature: a specific end-to-end feature that a
	transport service provides to its clients. Examples include		transport service provides to its clients. Examples include
	confidentiality, reliable delivery, ordered delivery, message-		confidentiality, reliable delivery, ordered delivery, message-
	versus-stream orientation, etc.		versus-stream orientation, etc.
	Transport Service: a set of transport service features, without an		Transport Service: a set of transport service features, without an
	association to any given framing protocol, which provides a		association to any given framing protocol, which provides a
	complete service to an application.		complete service to an application.
	Transport Protocol: an implementation that provides one or more		Transport Protocol: an implementation that provides one or more
	skipping to change at page 6, line 48		skipping to change at page 7, line 4
	The transport protocol components provided by TCP are:		The transport protocol components provided by TCP are:
	o unicast		o unicast
	o connection setup with feature negotiation and application-to-port		o connection setup with feature negotiation and application-to-port
	mapping		mapping
	o port multiplexing		o port multiplexing
	o reliable delivery		o reliable delivery
	o ordered delivery for each byte stream
	o error detection (checksum)		o error detection (checksum)
	o segmentation		o segmentation
	o stream-oriented delivery in a single stream		o stream-oriented delivery in a single stream
	o data bundling (Nagle's algorithm)		o data bundling (Nagle's algorithm)
	o flow control		o flow control
	o congestion control		o congestion control
	skipping to change at page 7, line 19		skipping to change at page 7, line 21
	o flow control		o flow control
	o congestion control		o congestion control
	[EDITOR'S NOTE: discussion of how to map this to features and TAPS:		[EDITOR'S NOTE: discussion of how to map this to features and TAPS:
	what does the higher layer need to decide? what can the transport		what does the higher layer need to decide? what can the transport
	layer decide based on global settings? what must the transport layer		layer decide based on global settings? what must the transport layer
	decide based on network characteristics?]		decide based on network characteristics?]
	3.2. Multipath TCP (MP-TCP)		3.2. Multipath TCP (MPTCP)
	[EDITOR'S NOTE: a few sentences describing Multipath TCP [RFC6824] go		Multipath TCP [RFC6824] is an extension for TCP to support multi-
	here. Note that this adds transport-layer multihoming to the		homing. It is designed to be as transparent as possible to middle-
	components TCP provides. Simone Ferlin-Oliveira will contribute text		boxes. It does so by establishing regular TCP flows between a pair
	for this section.]		of source/destination endpoints, and multiplexing the application's
			stream over these flows.
			3.2.1. Protocol Description
			MPTCP uses TCP options for its control plane. They are used to
			signal multipath capabilities, as well as to negotiate data sequence
			numbers, and advertise other available IP addresses and establish new
			sessions between pairs of endpoints.
			3.2.2. Interface Description
			By default, MPTCP exposes the same interface as TCP to the
			application. [RFC6897] however describes a richer API for MPTCP-
			aware applications.
			This Basic API describes how an application can - enable or disable
			MPTCP; - bind a socket to one or more selected local endpoints; -
			query local and remote endpoint addresses; - get a unique connection
			identifier (similar to an address-port pair for TCP).
			The document also recommend the use of extensions defined for SCTP
			[RFC6458] (see next section) to deal with multihoming.
			[AUTHOR'S NOTE: research work, and some implementation, also suggest
			that the scheduling algorithm, as well as the path manager, are
			configurable options that should be exposed to higher layer. Should
			this be discussed here?]
			3.2.3. Transport Protocol Components
			[AUTHOR'S NOTE: shouldn't it be "service feature"?]
			As an extension to TCP, MPTCP provides mostly the same components.
			By establishing multiple sessions between available endpoints, it can
			additionally provide soft failover solutions should one of the paths
			become unusable. In addition, by multiplexing one byte stream over
			separate paths, it can achieve a higher throughput than TCP in
			certain situations (note however that coupled congestion control
			[RFC6356] might limit this benefit to maintain fairness to other
			flows at the bottleneck). When aggregating capacity over multiple
			paths, and depending on the way packets are scheduled on each TCP
			subflow, an additional delay and higher jitter might be observed
			observed before in-order delivery of data to the applications.
			The transport protocol components provided by MPTCP 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 endpoint multiplexing of a single byte stream (higher throughput)
			o resilience to network failure and/or handovers
			[AUTHOR'S NOTE: it is unclear whether MPTCP has to provide data
			bundling.] [AUTHOR'S NOTE: AF muliplexing? sub-flows can be started
			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
	unidirectional streams in each direction and provides in-sequence		unidirectional streams in each direction and provides in-sequence
	delivery of user messages only within each stream. This allows to		delivery of user messages only within each stream. This allows to
	minimize head of line blocking. SCTP is extensible and the currently		minimize head of line blocking. SCTP is extensible and the currently
	defined extensions include mechanisms for dynamic re-configurations		defined extensions include mechanisms for dynamic re-configurations
	of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the		of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the
	extension specified in [RFC3758] introduces the concept of partial		extension specified in [RFC3758] introduces the concept of partial
	reliability for user messages.		reliability for user messages.
	SCTP was originally developed for transporting telephony signalling		SCTP was originally developed for transporting telephony signalling
	messages and is deployed in telephony signalling networks, especially		messages and is deployed in telephony signalling networks, especially
	in mobile telephony networks. Additionally, it is used in the WebRTC		in mobile telephony networks. Additionally, it is used in the WebRTC
	framework for data channels and is therefore deployed in all WEB-		framework for data channels and is therefore deployed in all WEB-
	browsers supporting WebRTC.		browsers supporting WebRTC.
	[EDITOR'S NOTE: Michael Tuexen and Karen Nielsen signed up as
	contributors for these sections.]
	3.3.1. Protocol Description		3.3.1. Protocol Description
	SCTP is a connection oriented protocol using a four way handshake to		SCTP is a connection oriented protocol using a four way handshake to
	establish an SCTP association and a three way message exchange to		establish an SCTP association and a three way message exchange to
	gracefully shut it down. It uses the same port number concept as		gracefully shut it down. It uses the same port number concept as
	DCCP, TCP, UDP, and UDP-Lite do and only supports unicast.		DCCP, TCP, UDP, and UDP-Lite do and only supports unicast.
	SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit		SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit
	errors. This is stronger than the 16-bit checksums used by TCP or		errors. This is stronger than the 16-bit checksums used by TCP or
	UDP. However, a partial checksum coverage as provided by DCCP or		UDP. However, a partial checksum coverage as provided by DCCP or
	skipping to change at page 18, line 16		skipping to change at page 19, line 47
	o partial integrity protection		o partial integrity protection
	3.7. Realtime Transport Protocol (RTP)		3.7. Realtime Transport Protocol (RTP)
	RTP provides an end-to-end network transport service, suitable for		RTP provides an end-to-end network transport service, suitable for
	applications transmitting real-time data, such as audio, video or		applications transmitting real-time data, such as audio, video or
	data, over multicast or unicast network services, including TCP, UDP,		data, over multicast or unicast network services, including TCP, UDP,
	UDP-Lite, DCCP.		UDP-Lite, DCCP.
	[EDITOR'S NOTE: Varun Singh signed up as contributor for this		[EDITOR'S NOTE: Varun Singh signed up as contributor for this
	section.]		section. Given the complexity of RTP, suggest to have an abbreviated
			section here contrasting RTP with other transports, and focusing on
			those features that are RTP-unique.]
	3.8. NACK-Oriented Reliable Multicast (NORM)		3.8. NACK-Oriented Reliable Multicast (NORM)
	NORM is an IETF standards track protocol specified in [RFC5740]. The		NORM is an IETF standards track protocol specified in [RFC5740]. The
	protocol was designed to support reliable bulk data dissemination to		protocol was designed to support reliable bulk data dissemination to
	receiver groups using IP Multicast but also provides for point-to-		receiver groups using IP Multicast but also provides for point-to-
	point unicast operation. Its support for bulk data dissemination		point unicast operation. Its support for bulk data dissemination
	includes discrete file or computer memory-based "objects" as well as		includes discrete file or computer memory-based "objects" as well as
	byte- and message-streaming. NORM is designed to incorporate packet		byte- and message-streaming. NORM is designed to incorporate packet
	erasure coding as an inherent part of its selective ARQ in response		erasure coding as an inherent part of its selective ARQ in response
	skipping to change at page 20, line 18		skipping to change at page 22, line 4
	3.8.3. Transport Protocol Components		3.8.3. Transport Protocol Components
	The transport protocol components provided by NORM are:		The transport protocol components provided by NORM are:
	o unicast		o unicast
	o multicast		o multicast
	o port multiplexing (UDP ports)		o port multiplexing (UDP ports)
	o reliable delivery		o reliable delivery
	o ordered delivery for each byte or message stream
	o unordered delivery of in-memory data or file bulk content objects		o unordered delivery of in-memory data or file bulk content objects
	o error detection (UDP checksum)		o error detection (UDP checksum)
	o segmentation		o segmentation
	o stream-oriented delivery in a single stream		o stream-oriented delivery in a single stream
	o object-oriented delivery of discrete data or file items		o object-oriented delivery of discrete data or file items
	skipping to change at page 20, line 44		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
	[NOTE: A few words on TLS [RFC5246] and DTLS [RFC6347] here, and how		Transport Layer Security (TLS) and Datagram TLS are IETF protocols
	they get used by other protocols to meet security goals as an add-on		that provide several security-related features to applications. TLS
	interlayer above transport. Kevin Fall will contribute text to this		is designed to run on top of TCP, DTLS is designed to run on top of
	section.]		UDP. At the time of writing, the current version of TLS is 1.2; it
			is defined in [RFC5246]. DTLS provides nearly identical
			functionality; it is defined in {RFC6347}} and also at version 1.2.
			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.
			[NOTE: The Logjam authors (weakdh.org) give (inconclusive) evidence
			that one of the recommendations of [RFC7525], namely use to DHE-1024
			as a fallback, may not be sufficient in all cases to counter an
			attacker with the resources of a nation-state. It is unclear at this
			time if the RFC is going to be updated as a result or whether 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
			discussed together. The features they provide are:
			o Confidentiality
			o Data integrity
			o Data authenticity
			o Optionally authentication of the peer entity
			[Note: Both TLS and DTLS provide replay protection, although it is
			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
			is a rare use case. In many use cases (e.g. the Web), authentication
			is not mutual, however (e.g. only the Web server is authenticated,
			but not the client). It is important to note that TLS itself does
			not specify how a peering entity is to be authenticated. This is
			part of the application logic; i.e. the authentication decision rests
			with the application. As an example, in the common use case of
			authentication by means of an X.509 certificate, it is the
			application's decision whether the certificate of the peering entity
			is acceptable for the purposes of the application or whether the
			handshake should be aborted.
			As DTLS is used over the unreliable UDP transport, it needs to add
			three features to provide the same security guarantees as TLS: *
			Message fragmentation * Message reordering * Message loss
			As a result, DTLS provides features that UDP lacks.
			[EDITOR'S NOTE: Need to describe how this is achieved?]
	3.9.2. Interface Description		3.9.2. Interface Description
	3.9.3. Transport Protocol Components		TLS is commonly used with a socket-like interface, although details
			can vary between implementations. This is particularly true for the
			choice which cryptographic algorithms to use, see below.
			[TODO: DTLS interface]
			Both TLS and DTLS allow to employ a multitude of cipher suites for
			encryption, hashing and applying message integrity. It is no easy
			task to choose safe settings here. [RFC7525] provides guidance.
			[TODO: list the RFCs?] [TODO: more detail?] ### Transport Protocol
			Components
			Both TLS and DTLS employ a layered architecture. The lower layer is
			commonly called the record protocol. It is responsible for
			fragmenting messages, applying message authentication codes (MACs),
			encrypting data, and sending it via the underlying transport
			protocol. Several essential protocols run on top of the record
			protocol in order to carry out the handshake and establish a secure
			session.
			[EDITOR'S NOTE: TLS can also compress, but this has been found to be
			a security weakness. It is not described here.]
	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
	skipping to change at page 21, line 32		skipping to change at page 24, line 43
	[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 model etc.). [RFC3205] address this issues and provides		security model etc.). [RFC3205] address this issues and provides
	some guidelines and concerns about the use of HTTP standard port 80		some guidelines and concerns about the use of HTTP standard port 80
	and 443, the use of HTTP URL scheme and interaction with existing		and 443, the use of HTTP URL scheme and interaction with existing
	firewalls, proxies and NATs. Also, though not strictly bound to TCP,		firewalls, proxies and NATs.
	HTTP is almost exclusively run over TCP, and therefore inherits its
	properties when used in this way. This can have disadvantages, when		Though not strictly bound to TCP, HTTP is almost exclusively run over
	the application does not naturally require single-streamed, reliable		TCP, and therefore inherits its properties when used in this way.
	transport.
	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
	differences between an HTTP object and a MIME message), containing		differences between an HTTP object and a MIME message), containing
	information about the client and request modifiers. The message can		information about the client and request modifiers. The message can
	contain a message body carrying application data as well. The server		contain a message body carrying application data as well. The server
	responds with a status or error code followed by a MIME-like message		responds with a status or error code followed by a MIME-like message
	skipping to change at page 23, line 15		skipping to change at page 26, line 31
	native code is less attractive.		native code is less attractive.
	Representational State Transfer (REST) [REST] is another example how		Representational State Transfer (REST) [REST] is another example how
	applications can use HTTP as transport protocol. REST is an		applications can use HTTP as transport protocol. REST is an
	architecture style for building application on the Internet. It uses		architecture style for building application on the Internet. It uses
	HTTP as a communication protocol.		HTTP as a communication protocol.
	3.10.3. Transport Protocol Components		3.10.3. Transport Protocol Components
	The transport protocol components provided by HTTP, when used as a		The transport protocol components provided by HTTP, when used as a
	pseudotransport over TCP, are:		pseudotransport, are:
	o unicast		o unicast
	o reliable delivery		o reliable delivery
	o ordered delivery		o ordered delivery
	o message and stream-oriented		o message and stream-oriented
	o object range request		o object range request
	skipping to change at page 28, line 27		skipping to change at page 31, line 27
	document does not specify any new components or mechanisms for		document does not specify any new components or mechanisms for
	providing these features. Each RFC listed in this document discusses		providing these features. Each RFC listed in this document discusses
	the security considerations of the specification it contains.		the security considerations of the specification it contains.
	7. Contributors		7. Contributors
	[Editor's Note: turn this into a real contributors section with		[Editor's Note: turn this into a real contributors section with
	addresses once we figure out how to trick the toolchain into doing		addresses once we figure out how to trick the toolchain into doing
	so]		so]
			o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera
			(ferlin@simula.no) and Olivier Mehani
			(olivier.mehani@nicta.com.au)
	o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com)		o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com)
	o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh-		o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh-
	muenster.de)		muenster.de)
	o Section 3.8 on NORM was contributed by Brian Adamson		o Section 3.8 on NORM was contributed by Brian Adamson
	(brian.adamson@nrl.navy.mil)		(brian.adamson@nrl.navy.mil)
			o Section 3.9 on MPTCP was contributed by Ralph Holz
			(ralph.holz@nicta.com.au) and Olivier Mehani
			(olivier.mehani@nicta.com.au)
	o Section 3.10 on HTTP was contributed by Dragana Damjanovic		o Section 3.10 on HTTP was contributed by Dragana Damjanovic
	(ddamjanovic@mozilla.com)		(ddamjanovic@mozilla.com)
	8. Acknowledgments		8. Acknowledgments
	This work is partially supported by the European Commission under		Thanks to Karen Nielsen, Joe Touch, and Michael Welzl for the
	grant agreement FP7-ICT-318627 mPlane; support does not imply		comments, feedback, and discussion. This work is partially supported
	endorsement.		by the European Commission under grant agreement FP7-ICT-318627
			mPlane; support does not imply endorsement.
			[EDITOR'S NOTE: add H2020-NEAT ack].
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
	1981.		1981.
	9.2. Informative References		9.2. Informative References
	skipping to change at page 32, line 30		skipping to change at page 35, line 38
	6525, February 2012.		6525, February 2012.
	[RFC6546] Trammell, B., "Transport of Real-time Inter-network		[RFC6546] Trammell, B., "Transport of Real-time Inter-network
	Defense (RID) Messages over HTTP/TLS", RFC 6546, April		Defense (RID) Messages over HTTP/TLS", RFC 6546, April
	2012.		2012.
	[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,		[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
	"Computing TCP's Retransmission Timer", RFC 6298, June		"Computing TCP's Retransmission Timer", RFC 6298, June
	2011.		2011.
	[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	UDP Checksums for Tunneled Packets", RFC 6935, April 2013.		Security Version 1.2", RFC 6347, January 2012.
	[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement		[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
	for the Use of IPv6 UDP Datagrams with Zero Checksums",		Congestion Control for Multipath Transport Protocols", RFC
	RFC 6936, April 2013.		6356, October 2011.
	[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC		[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
	6455, December 2011.		6455, December 2011.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.
	[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.		[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
	Yasevich, "Sockets API Extensions for the Stream Control		Yasevich, "Sockets API Extensions for the Stream Control
	Transmission Protocol (SCTP)", RFC 6458, December 2011.		Transmission Protocol (SCTP)", RFC 6458, December 2011.
	[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",		[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
	RFC 6691, July 2012.		RFC 6691, July 2012.
	[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,		[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
	"TCP Extensions for Multipath Operation with Multiple		"TCP Extensions for Multipath Operation with Multiple
	Addresses", RFC 6824, January 2013.		Addresses", RFC 6824, January 2013.
			[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
			Interface Considerations", RFC 6897, March 2013.
			[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
			UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
			[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
			for the Use of IPv6 UDP Datagrams with Zero Checksums",
			RFC 6936, April 2013.
	[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream		[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
	Control Transmission Protocol (SCTP) Packets for End-Host		Control Transmission Protocol (SCTP) Packets for End-Host
	to End-Host Communication", RFC 6951, May 2013.		to End-Host Communication", RFC 6951, May 2013.
	[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-		[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
	IMMEDIATELY Extension for the Stream Control Transmission		IMMEDIATELY Extension for the Stream Control Transmission
	Protocol", RFC 7053, November 2013.		Protocol", RFC 7053, November 2013.
	[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol		[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
	(HTTP/1.1): Message Syntax and Routing", RFC 7230, June		(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
	skipping to change at page 33, line 42		skipping to change at page 37, line 13
	(HTTP/1.1): Authentication", RFC 7235, June 2014.		(HTTP/1.1): Authentication", RFC 7235, June 2014.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, July 2014.		Negotiation Extension", RFC 7301, July 2014.
	[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.		[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
	Scheffenegger, "TCP Extensions for High Performance", RFC		Scheffenegger, "TCP Extensions for High Performance", RFC
	7323, September 2014.		7323, September 2014.
			[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
			Known Attacks on Transport Layer Security (TLS) and
			Datagram TLS (DTLS)", RFC 7457, February 2015.
			[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(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		Welzl, M. and G. Fairhurst, "The Benefits and Pitfalls of
	using Explicit Congestion Notification (ECN)", draft-ietf-		using Explicit Congestion Notification (ECN)", draft-ietf-
	aqm-ecn-benefits-00 (work in progress), October 2014.		aqm-ecn-benefits-00 (work in progress), October 2014.
	[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
End of changes. 29 change blocks.
	86 lines changed or deleted		255 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/