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/