--- 1/draft-ietf-taps-minset-09.txt 2018-09-18 03:13:08.993767781 -0700 +++ 2/draft-ietf-taps-minset-10.txt 2018-09-18 03:13:09.085769999 -0700 @@ -1,18 +1,18 @@ TAPS M. Welzl Internet-Draft S. Gjessing Intended status: Informational University of Oslo -Expires: March 17, 2019 September 13, 2018 +Expires: March 22, 2019 September 18, 2018 A Minimal Set of Transport Services for End Systems - draft-ietf-taps-minset-09 + draft-ietf-taps-minset-10 Abstract This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. Status of This Memo @@ -22,21 +22,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 https://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 March 17, 2019. + This Internet-Draft will expire on March 22, 2019. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,21 +79,21 @@ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. The Superset of Transport Features . . . . . . . . . 24 A.1. CONNECTION Related Transport Features . . . . . . . . . . 25 A.2. DATA Transfer Related Transport Features . . . . . . . . 41 A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 41 A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 45 A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 46 Appendix B. Revision information . . . . . . . . . . . . . . . . 47 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 1. Introduction Currently, the set of transport services that most applications use is based on TCP and UDP (and protocols that are layered on top of them); this limits the ability for the network stack to make use of features of other transport protocols. For example, if a protocol supports out-of-order message delivery but applications always assume that the network provides an ordered bytestream, then the network stack can not immediately deliver a message that arrives out-of- @@ -313,36 +313,37 @@ an implementation over UDP is possible, and "T,U:" if an implementation over either TCP or UDP is possible. 4.1. CONNECTION Related Transport Features ESTABLISHMENT: o T,U: Connect o T,U: Specify number of attempts and/or timeout for the first establishment message + o T,U: Disable MPTCP o T: Configure authentication o T: Hand over a message to reliably transfer (possibly multiple times) before connection establishment o T: Hand over a message to reliably transfer during connection establishment AVAILABILITY: o T,U: Listen + o T,U: Disable MPTCP o T: Configure authentication MAINTENANCE: o T: Change timeout for aborting connection (using retransmit limit or time value) - o T: Suggest timeout to the peer o T,U: Disable Nagle algorithm o T,U: Notification of Excessive Retransmissions (early warning below abortion threshold) o T,U: Specify DSCP field o T,U: Notification of ICMP error message arrival o T: Change authentication parameters o T: Obtain authentication information o T,U: Set Cookie life value o T,U: Choose a scheduler to operate between streams of an @@ -597,23 +597,24 @@ always be authenticated -- if this is exposed as such, it creates an undesirable dependency on the transport protocol. For compatibility with TCP, a transport system should only allow to configure complete transport layer packets, including headers, IP pseudo-header (if any) and payload. Security is discussed in a separate document [I-D.ietf-taps-transport-security]. The minimal set presented in the present document excludes all security related transport features from Appendix A: "Configure authentication", "Change authentication - parameters", "Obtain authentication information" and and "Set Cookie - life value" as well as "Specifying a key id to be used to - authenticate a message". + parameters", "Obtain authentication information" and "Set Cookie life + value" as well as "Specifying a key id to be used to authenticate a + message". It also excludes security transport features not listed in + Appendix A, including content privacy to in-path devices. 5.7. Packet Size UDP(-Lite) has a transport feature called "Specify DF field". This yields an error message in case of sending a message that exceeds the Path MTU, which is necessary for a UDP-based application to be able to implement Path MTU Discovery (a function that UDP-based applications must do by themselves). The "Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface" transport feature yields an upper limit for the @@ -647,27 +648,29 @@ (Sending Data, Receiving Data, Errors). Here, the focus is on connections that the transport system offers as an abstraction to the application, as opposed to connections of transport protocols that the transport system uses. 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION A connection must first be "created" to allow for some initial configuration to be carried out before the transport system can actively or passively establish communication with a remote end - system. All configuration parameters in Section 6.2 can be used - initially, although some of them may only take effect when a - connection has been established with a chosen transport protocol. - Configuring a connection early helps a transport system make the - right decisions. For example, grouping information can influence the - transport system to implement a connection as a stream of a multi- - streaming protocol's existing association or not. + system. As a configuration of the newly created connection, an + application can choose to disallow usage of MPTCP. Furthermore, all + configuration parameters in Section 6.2 can be used initially, + although some of them may only take effect when a connection has been + established with a chosen transport protocol. Configuring a + connection early helps a transport system make the right decisions. + For example, grouping information can influence the transport system + to implement a connection as a stream of a multi-streaming protocol's + existing association or not. For ungrouped connections, early configuration is necessary because it allows the transport system to know which protocols it should try to use. In particular, a transport system that only makes a one-time choice for a particular protocol must know early about strict requirements that must be kept, or it can end up in a deadlock situation (e.g., having chosen UDP and later be asked to support reliable transfer). As an example description of how to correctly handle these cases, we provide the following decision tree (this is derived from Section 4.1 excluding authentication, as explained in @@ -1048,20 +1051,24 @@ 2007, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . + [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application + Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, + March 2013, . + [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, @@ -1124,26 +1131,25 @@ is exhibited to an application could be implemented by using a single stream of an SCTP association instead of mapping it to a complete SCTP association or TCP connection. This could be achieved by using more than one stream when an SCTP association is first established (CONNECT.SCTP parameter "outbound stream count"), maintaining an internal stream number, and using this stream number when sending data (SEND.SCTP parameter "stream number"). Closing or aborting a connection could then simply free the stream number for future use. This is discussed further in Section 5.2. - o All transport features that are related to using multiple paths or - the choice of the network interface were designated as - "automatable". Choosing a path or an interface does not depend on - application-specific knowledge. For example, "Listen" could - always listen on all available interfaces and "Connect" could use - the default interface for the destination IP address. + o With the exception of "Disable MPTCP", all transport features that + are related to using multiple paths or the choice of the network + interface were designated as "automatable". For example, "Listen" + could always listen on all available interfaces and "Connect" + could use the default interface for the destination IP address. Finally, in three cases, transport features are aggregated and/or slightly changed from [RFC8303] in the description below. These transport features are marked as "CHANGED FROM RFC8303". These do not add any new functionality but just represent a simple refactoring step that helps to streamline the derivation process (e.g., by removing a choice of a parameter for the sake of applications that may not care about this choice). The corresponding transport features are automatable, and they are listed immediately below the "CHANGED FROM RFC8303" transport feature. @@ -1186,30 +1193,34 @@ Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery for data that is sent before or during connection establishment. Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. Implementation over UDP: Do nothing (this is irrelevant in case of UDP because there, reliable data delivery is not assumed). o Obtain multiple sockets Protocols: SCTP - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the - application. + Automatable because the non-parallel usage of multiple paths to + communicate between the same end hosts relates to knowledge about + the network, not the application. o Disable MPTCP Protocols: MPTCP - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the - application. + Optimizing because the parallel usage of multiple paths to + communicate between the same end hosts can improve performance. + Whether to use this feature depends on knowledge about the network + as well as application-specific knowledge (see Section 3.1 of + [RFC6897]). Implementation: via a boolean parameter in CONNECT.MPTCP. + Implementation over TCP: Do nothing. + Implementation over UDP: Do nothing. o Configure authentication Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. With TCP, this allows to configure Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows to specify which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of @@ -1302,23 +1312,28 @@ knowledge about the network and the Operating System, not the application. o Specify which IP Options must always be used Protocols: TCP, UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Disable MPTCP Protocols: MPTCP - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the - application. + Optimizing because the parallel usage of multiple paths to + communicate between the same end hosts can improve performance. + Whether to use this feature depends on knowledge about the network + as well as application-specific knowledge (see Section 3.1 of + [RFC6897]). + Implementation: via a boolean parameter in LISTEN.MPTCP. + Implementation over TCP: Do nothing. + Implementation over UDP: Do nothing. o Configure authentication Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. Implementation over TCP: With TCP, this allows to configure Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows to specify which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of @@ -1398,49 +1413,49 @@ informing it of an impending functional event. Implementation: via ERROR.TCP. Implementation over UDP: do nothing (there is no abortion threshold). o Add path Protocols: MPTCP, SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port SCTP Parameters: local IP address - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the + Automatable because the choice of paths to communicate between the + same end hosts relates to knowledge about the network, not the application. o Remove path Protocols: MPTCP, SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port SCTP Parameters: local IP address - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the + Automatable because the choice of paths to communicate between the + same end host relates to knowledge about the network, not the application. o Set primary path Protocols: SCTP - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the + Automatable because the choice of paths to communicate between the + same end hosts relates to knowledge about the network, not the application. o Suggest primary path to the peer Protocols: SCTP - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the + Automatable because the choice of paths to communicate between the + same end hosts relates to knowledge about the network, not the application. o Configure Path Switchover Protocols: SCTP - Automatable because the usage of multiple paths to communicate to - the same end host relates to knowledge about the network, not the + Automatable because the choice of paths to communicate between the + same end hosts relates to knowledge about the network, not the application. o Obtain status (query or notification) Protocols: SCTP, MPTCP SCTP parameters: association connection state; destination transport address list; destination transport address reachability states; current local and peer receiver window size; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other @@ -2106,21 +2121,24 @@ WG -06: Fixed nits. WG -07: Addressed Genart comments from Robert Sparks. WG -08: Addressed one more Genart comment from Robert Sparks. WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben Campbell, Benjamin Kaduk and Eric Rescorla. + WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla. + Authors' Addresses + Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Stein Gjessing