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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/