--- 1/draft-ietf-taps-transports-05.txt 2015-07-06 15:15:02.114366941 -0700 +++ 2/draft-ietf-taps-transports-06.txt 2015-07-06 15:15:02.194368942 -0700 @@ -1,21 +1,21 @@ Network Working Group G. Fairhurst, Ed. Internet-Draft University of Aberdeen Intended status: Informational B. Trammell, Ed. -Expires: December 11, 2015 M. Kuehlewind, Ed. +Expires: January 7, 2016 M. Kuehlewind, Ed. ETH Zurich - June 09, 2015 + July 06, 2015 Services provided by IETF transport protocols and congestion control mechanisms - draft-ietf-taps-transports-05 + draft-ietf-taps-transports-06 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 December 11, 2015. + This Internet-Draft will expire on December 14, 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 @@ -52,22 +52,22 @@ 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 (MPTCP) . . . . . . . . . . . . . . . . . . 7 - 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 - 3.2.2. Interface Description . . . . . . . . . . . . . . . . 7 + 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 8 + 3.2.2. Interface Description . . . . . . . . . . . . . . . . 8 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 @@ -79,40 +79,41 @@ 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 . . . . . . . . . . . . . . . . . . . . 22 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 - pseudotransport . . . . . . . . . . . . . . . . . . . . . 24 + pseudotransport . . . . . . . . . . . . . . . . . . . . . 25 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25 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.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 + 3.11.3. Transport Protocol Components . . . . . . . . . . . 28 + 4. Transport Service Features . . . . . . . . . . . . . . . . . 28 + 4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 - 9.2. Informative References . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 9.2. Informative References . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 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 @@ -268,46 +269,75 @@ In API implementations derived from the BSD Sockets API, TCP sockets are created using the "SOCK_STREAM" socket type. The features used by a protocol instance may be set and tuned via this API. (more on the API goes here) 3.1.3. Transport Protocol Components - The transport protocol components provided by TCP are: - - o unicast + The transport protocol components provided by TCP (new version) are: - o connection setup with feature negotiation and application-to-port - mapping + [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?] - 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 error detection (checksum) + o Single stream-oriented transmission: The stream abstraction atop + 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: - 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 Window-based congestion control reacting to loss, delay, + retransmission timeout, or an explicit congestion signal (ECN): + Most commonly used is a loss signal from the reliability + 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) 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 @@ -345,44 +375,28 @@ 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 + The transport protocol components provided by MPTCP in addition to + TCP therefore are: - o congestion control + o congestion control with load balancing over mutiple connections 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 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 @@ -1010,125 +1024,167 @@ 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 - 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. + Transport Layer Security (TLS) and Datagram TLS (DTLS) are IETF + protocols that provide several security-related features to + applications. TLS is designed to run on top of a reliable streaming + transport protocol (usually TCP), while DTLS is designed to run on + top of a best-effort datagram protocol (usually UDP). At the time of + 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 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.] + that one of the recommendations of [RFC7525], namely the use of + 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 + o Peer authentication (optional) - [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.] + o Perfect forward secrecy (optional) - 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 + The authentication of the peer entity can be omitted; a common web + use case is where the server is authenticated and the client is not. + TLS also provides a completely anonymous operation mode in which + neither peer's identity is authenticated. It is important to note + that TLS itself does not specify how a peering entity's identity + should be interpreted. For 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. + is acceptable for authorization decisions. Perfect forward secrecy, + 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 - three features to provide the same security guarantees as TLS: * - Message fragmentation * Message reordering * Message loss + As DTLS is generally used over an unreliable datagram transport such + as TCP, applications will need to tolerate loss, re-ordered, or + 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 - 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. + TLS is commonly invoked using an API provided by packages such as + OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the + 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] - 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. + Considerable care is required in the use of TLS APIs in order to + create a secure application. The programmer should have at least a + basic understanding of encryption and digital signature algorithms + 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 - Components + As an example, in the case of OpenSSL, the primary abstractions are + 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 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. + encrypting data, and invoking transmission from the underlying + transport protocol. DTLS augments the TLS record protocol with + sequence numbers used for ordering and replay detection. - [EDITOR'S NOTE: TLS can also compress, but this has been found to be - a security weakness. It is not described here.] + Several protocols are layered on top of the record protocol. These + 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 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 servers and client libraries, easy use of existing security mechanisms such as HTTP digest authentication [RFC2617] and TLS [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 + 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. 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 @@ -1227,122 +1284,133 @@ 3.11. WebSockets [RFC6455] [EDITOR'S NOTE: Salvatore Loreto will contribute text for this section.] 3.11.1. Protocol Description 3.11.2. Interface Description - 3.11.3. Transport Protocol Components 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 be used as a basis for defining common transport service features, 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- - port mapping + - specify handover latency? - o Delivery + + multihoming for load-balancing - * reliable delivery - * partially reliable delivery + - specify interleaving delay? - * 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 - objects + - drop notification - * 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 * authentication of one end of a connection * authentication of both ends of a connection * confidentiality + * cryptographic integrity protection + The next revision of this document will define transport service features based upon this list. [EDITOR'S NOTE: this section will drawn from the candidate features provided by protocol components in the previous section - please discuss on taps@ietf.org list] 4.1. Complete Protocol Feature Matrix [EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this @@ -1704,23 +1770,23 @@ [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. + Fairhurst, G. and M. Welzl, "The Benefits of using + Explicit Congestion Notification (ECN)", draft-ietf-aqm- + ecn-benefits-05 (work in progress), June 2015. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-09 (work in progress), January 2015. [I-D.ietf-tsvwg-sctp-prpolicies] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol", draft-ietf-