--- 1/draft-ietf-taps-transports-04.txt 2015-06-09 10:15:02.530834745 -0700 +++ 2/draft-ietf-taps-transports-05.txt 2015-06-09 10:15:02.602836491 -0700 @@ -1,21 +1,21 @@ Network Working Group G. Fairhurst, Ed. Internet-Draft University of Aberdeen Intended status: Informational B. Trammell, Ed. -Expires: November 28, 2015 M. Kuehlewind, Ed. +Expires: December 11, 2015 M. Kuehlewind, Ed. ETH Zurich - May 27, 2015 + June 09, 2015 Services provided by IETF transport protocols and congestion control mechanisms - draft-ietf-taps-transports-04 + draft-ietf-taps-transports-05 Abstract This document describes services provided by existing IETF protocols and congestion control mechanisms. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 28, 2015. + This Internet-Draft will expire on December 11, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -51,67 +51,68 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 4 3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 4 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 5 3.1.2. Interface description . . . . . . . . . . . . . . . . 6 3.1.3. Transport Protocol Components . . . . . . . . . . . . 6 - 3.2. Multipath TCP (MP-TCP) . . . . . . . . . . . . . . . . . 7 - 3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 7 - 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 8 - 3.3.2. Interface Description . . . . . . . . . . . . . . . . 10 - 3.3.3. Transport Protocol Components . . . . . . . . . . . . 11 - 3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 12 - 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 12 - 3.4.2. Interface Description . . . . . . . . . . . . . . . . 13 - 3.4.3. Transport Protocol Components . . . . . . . . . . . . 13 - 3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 14 - 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 14 - 3.5.2. Interface Description . . . . . . . . . . . . . . . . 15 - 3.5.3. Transport Protocol Components . . . . . . . . . . . . 15 - 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 15 - 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 16 - 3.6.2. Interface Description . . . . . . . . . . . . . . . . 17 - 3.6.3. Transport Protocol Components . . . . . . . . . . . . 17 - 3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 18 - 3.8. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 18 - 3.8.1. Protocol Description . . . . . . . . . . . . . . . . 18 - 3.8.2. Interface Description . . . . . . . . . . . . . . . . 19 - 3.8.3. Transport Protocol Components . . . . . . . . . . . . 20 + 3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 7 + 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 + 3.2.2. Interface Description . . . . . . . . . . . . . . . . 7 + 3.2.3. Transport Protocol Components . . . . . . . . . . . . 8 + 3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 9 + 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 + 3.3.2. Interface Description . . . . . . . . . . . . . . . . 11 + 3.3.3. Transport Protocol Components . . . . . . . . . . . . 13 + 3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 13 + 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 14 + 3.4.2. Interface Description . . . . . . . . . . . . . . . . 14 + 3.4.3. Transport Protocol Components . . . . . . . . . . . . 15 + 3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 15 + 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 15 + 3.5.2. Interface Description . . . . . . . . . . . . . . . . 16 + 3.5.3. Transport Protocol Components . . . . . . . . . . . . 16 + 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 17 + 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 + 3.6.2. Interface Description . . . . . . . . . . . . . . . . 19 + 3.6.3. Transport Protocol Components . . . . . . . . . . . . 19 + 3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 19 + 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 - a pseudotransport . . . . . . . . . . . . . . . . . . . . 20 - 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 21 - 3.9.2. Interface Description . . . . . . . . . . . . . . . . 21 - 3.9.3. Transport Protocol Components . . . . . . . . . . . . 21 + a pseudotransport . . . . . . . . . . . . . . . . . . . . 22 + 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 23 + 3.9.2. Interface Description . . . . . . . . . . . . . . . . 23 3.10. Hypertext Transport Protocol (HTTP) over TCP as a - pseudotransport . . . . . . . . . . . . . . . . . . . . . 21 - 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 21 - 3.10.2. Interface Description . . . . . . . . . . . . . . . 22 - 3.10.3. Transport Protocol Components . . . . . . . . . . . 23 - 3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 23 - 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 23 - 3.11.2. Interface Description . . . . . . . . . . . . . . . 24 - 3.11.3. Transport Protocol Components . . . . . . . . . . . 24 - - 4. Transport Service Features . . . . . . . . . . . . . . . . . 24 - 4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 26 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 - 9.2. Informative References . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 + pseudotransport . . . . . . . . . . . . . . . . . . . . . 24 + 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25 + 3.10.2. Interface Description . . . . . . . . . . . . . . . 26 + 3.10.3. Transport Protocol Components . . . . . . . . . . . 26 + 3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 27 + 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 27 + 3.11.2. Interface Description . . . . . . . . . . . . . . . 27 + 3.11.3. Transport Protocol Components . . . . . . . . . . . 27 + 4. Transport Service Features . . . . . . . . . . . . . . . . . 27 + 4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 29 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 9.2. Informative References . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction Most Internet applications make use of the Transport Services provided by TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean the end-to-end service provided to an application by the transport layer. That service can only be provided correctly if information about the intended usage is supplied from the application. The application may determine this information at @@ -140,20 +141,23 @@ and unordered message delivery within multiple streams, UDP-Lite provides partial integrity protection, and LEDBAT can provide low- priority "scavenger" communication. 2. Terminology The following terms are defined throughout this document, and in subsequent documents produced by TAPS describing the composition and 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 provides to its clients. Examples include confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. Transport Service: a set of transport service features, without an association to any given framing protocol, which provides a complete service to an application. Transport Protocol: an implementation that provides one or more @@ -274,24 +278,22 @@ The transport protocol components provided by TCP are: o unicast o connection setup with feature negotiation and application-to-port mapping o port multiplexing o reliable delivery - - o ordered delivery for each byte stream - o error detection (checksum) + o segmentation o stream-oriented delivery in a single stream o data bundling (Nagle's algorithm) o flow control o congestion control @@ -293,49 +295,118 @@ o flow control o congestion control [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 layer decide based on global settings? what must the transport layer 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 - here. Note that this adds transport-layer multihoming to the - components TCP provides. Simone Ferlin-Oliveira will contribute text - for this section.] + Multipath TCP [RFC6824] is an extension for TCP to support multi- + homing. It is designed to be as transparent as possible to middle- + boxes. It does so by establishing regular TCP flows between a pair + 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) SCTP is a message oriented standards track transport protocol and the base protocol is specified in [RFC4960]. It supports multi-homing to handle path failures. An SCTP association has multiple unidirectional streams in each direction and provides in-sequence delivery of user messages only within each stream. This allows to minimize head of line blocking. SCTP is extensible and the currently defined extensions include mechanisms for dynamic re-configurations of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the extension specified in [RFC3758] introduces the concept of partial reliability for user messages. SCTP was originally developed for transporting telephony signalling messages and is deployed in telephony signalling networks, especially in mobile telephony networks. Additionally, it is used in the WebRTC framework for data channels and is therefore deployed in all WEB- browsers supporting WebRTC. - [EDITOR'S NOTE: Michael Tuexen and Karen Nielsen signed up as - contributors for these sections.] - 3.3.1. Protocol Description SCTP is a connection oriented protocol using a four way handshake to establish an SCTP association and a three way message exchange to gracefully shut it down. It uses the same port number concept as DCCP, TCP, UDP, and UDP-Lite do and only supports unicast. 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 UDP. However, a partial checksum coverage as provided by DCCP or @@ -814,21 +887,23 @@ o partial integrity protection 3.7. Realtime Transport Protocol (RTP) RTP provides an end-to-end network transport service, suitable for applications transmitting real-time data, such as audio, video or data, over multicast or unicast network services, including TCP, UDP, UDP-Lite, DCCP. [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) NORM is an IETF standards track protocol specified in [RFC5740]. The protocol was designed to support reliable bulk data dissemination to receiver groups using IP Multicast but also provides for point-to- point unicast operation. Its support for bulk data dissemination includes discrete file or computer memory-based "objects" as well as byte- and message-streaming. NORM is designed to incorporate packet erasure coding as an inherent part of its selective ARQ in response @@ -912,25 +987,22 @@ 3.8.3. Transport Protocol Components The transport protocol components provided by NORM are: o unicast o multicast o port multiplexing (UDP ports) - 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 error detection (UDP checksum) o segmentation o stream-oriented delivery in a single stream o object-oriented delivery of discrete data or file items @@ -938,30 +1010,103 @@ o flow control (timer-based and/or ack-based) o congestion control o packet erasure coding (both proactively and as part of ARQ) 3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a pseudotransport - [NOTE: A few words on TLS [RFC5246] and DTLS [RFC6347] here, and how - they get used by other protocols to meet security goals as an add-on - interlayer above transport. Kevin Fall will contribute text to this - section.] + Transport Layer Security (TLS) and Datagram TLS are IETF protocols + that provide several security-related features to applications. TLS + is designed to run on top of TCP, DTLS is designed to run on top of + 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 + 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.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 Hypertext Transfer Protocol (HTTP) is an application-level protocol widely used on the Internet. Version 1.1 of the protocol is specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], and version 2 in [RFC7540]. Furthermore, HTTP is used as a substrate for other application-layer protocols. There are various reasons for this practice listed in [RFC3205]; these include being a well-known and well-understood protocol, reusability of existing @@ -970,25 +1115,24 @@ [RFC5246], the ability of HTTP to traverse firewalls which makes it work with a lot of infrastructure, and cases where a application server often needs to support HTTP anyway. Depending on application's needs, the use of HTTP as a substrate protocol may add complexity and overhead in comparison to a special- purpose protocol (e.g. HTTP headers, suitability of the HTTP security model etc.). [RFC3205] address this issues and provides some guidelines and concerns about the use of HTTP standard port 80 and 443, the use of HTTP URL scheme and interaction with existing - firewalls, proxies and NATs. Also, though not strictly bound to TCP, - HTTP is almost exclusively run over TCP, and therefore inherits its - properties when used in this way. This can have disadvantages, when - the application does not naturally require single-streamed, reliable - transport. + firewalls, proxies and NATs. + + Though not strictly bound to TCP, HTTP is almost exclusively run over + TCP, and therefore inherits its properties when used in this way. 3.10.1. Protocol Description Hypertext Transfer Protocol (HTTP) is a request/response protocol. A client sends a request containing a request method, URI and protocol version followed by a MIME-like message (see [RFC7231] for the differences between an HTTP object and a MIME message), containing information about the client and request modifiers. The message can contain a message body carrying application data as well. The server responds with a status or error code followed by a MIME-like message @@ -1050,21 +1194,21 @@ native code is less attractive. Representational State Transfer (REST) [REST] is another example how applications can use HTTP as transport protocol. REST is an architecture style for building application on the Internet. It uses HTTP as a communication protocol. 3.10.3. Transport Protocol Components The transport protocol components provided by HTTP, when used as a - pseudotransport over TCP, are: + pseudotransport, are: o unicast o reliable delivery o ordered delivery o message and stream-oriented o object range request @@ -1274,36 +1419,47 @@ document does not specify any new components or mechanisms for providing these features. Each RFC listed in this document discusses the security considerations of the specification it contains. 7. Contributors [Editor's Note: turn this into a real contributors section with addresses once we figure out how to trick the toolchain into doing 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.3 on SCTP was contributed by Michael Tuexen (tuexen@fh- muenster.de) o Section 3.8 on NORM was contributed by Brian Adamson (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 (ddamjanovic@mozilla.com) 8. Acknowledgments - This work is partially supported by the European Commission under - grant agreement FP7-ICT-318627 mPlane; support does not imply - endorsement. + Thanks to Karen Nielsen, Joe Touch, and Michael Welzl for the + comments, feedback, and discussion. This work is partially supported + 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.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 9.2. Informative References @@ -1467,44 +1623,51 @@ 6525, February 2012. [RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012. [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011. - [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and - UDP Checksums for Tunneled Packets", RFC 6935, April 2013. + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 2012. - [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement - for the Use of IPv6 UDP Datagrams with Zero Checksums", - RFC 6936, April 2013. + [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled + Congestion Control for Multipath Transport Protocols", RFC + 6356, October 2011. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 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. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011. [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, July 2012. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple 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 Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, May 2013. [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, November 2013. [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June @@ -1528,20 +1691,29 @@ (HTTP/1.1): Authentication", RFC 7235, June 2014. [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, July 2014. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, "TCP Extensions for High Performance", RFC 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 Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. [I-D.ietf-aqm-ecn-benefits] Welzl, M. and G. Fairhurst, "The Benefits and Pitfalls of using Explicit Congestion Notification (ECN)", draft-ietf- aqm-ecn-benefits-00 (work in progress), October 2014. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS