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/