draft-ietf-taps-arch-07.txt   draft-ietf-taps-arch-08.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: 10 September 2020 Google Expires: 14 January 2021 Google Switzerland GmbH
A. Brunstrom A. Brunstrom
Karlstad University Karlstad University
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
C. Perkins C. Perkins
University of Glasgow University of Glasgow
P. Tiesel P. Tiesel
TU Berlin TU Berlin
C. Wood C.A. Wood
Apple Inc. Cloudflare
9 March 2020 13 July 2020
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-07 draft-ietf-taps-arch-08
Abstract Abstract
This document describes an architecture for exposing transport This document describes an architecture for exposing transport
protocol features to applications for network communication, the protocol features to applications for network communication, the
Transport Services architecture. The Transport Services Application Transport Services architecture. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. It uses messages for representing data transfer interaction pattern. It uses messages for representing data transfer
to applications, and it assumes an implementation that can use to applications, and it describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and multiple IP addresses, multiple protocols, and multiple paths, and
provide multiple application streams. This document further defines provide multiple application streams. This document further defines
common terminology and concepts to be used in definitions of common terminology and concepts to be used in definitions of
Transport Services APIs and implementations. Transport Services APIs and implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 10 September 2020. This Internet-Draft will expire on 14 January 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . 5 1.3. Specification of Requirements . . . . . . . . . . . . . . 5
2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7
2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7
2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 9 3. API and Implementation Requirements . . . . . . . . . . . . . 9
3.1. Common APIs for Common Features . . . . . . . . . . . . . 9 3.1. Provide Common APIs for Common Features . . . . . . . . . 9
3.2. Access to Specialized Features . . . . . . . . . . . . . 9 3.2. Allow Access to Specialized Features . . . . . . . . . . 10
3.3. Scope for API and Implementation Definitions . . . . . . 10 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11
4. Transport Services Architecture and Concepts . . . . . . . . 11 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12
4.1. Transport Services API Concepts . . . . . . . . . . . . . 12 4. Transport Services Architecture and Concepts . . . . . . . . 12
4.1.1. Connections and Related Objects . . . . . . . . . . . 14 4.1. Transport Services API Concepts . . . . . . . . . . . . . 13
4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 15 4.1.1. Connections and Related Objects . . . . . . . . . . . 15
4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 16 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 16
4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 17 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 17
4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 18 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 18
4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 19 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 19
4.1.7. Connection Groups . . . . . . . . . . . . . . . . . . 19 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 20
4.2. Transport Services Implementation Concepts . . . . . . . 19 4.1.7. Connection Groups . . . . . . . . . . . . . . . . . . 20
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20 4.2. Transport Services Implementation Concepts . . . . . . . 20
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 21 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 21
4.2.3. Protocol Stack Equivalence . . . . . . . . . . . . . 21 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22
4.2.4. Separating Connection Groups . . . . . . . . . . . . 23 4.2.3. Separating Connection Groups . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Many application programming interfaces (APIs) to perform transport Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and networking have been deployed, perhaps the most widely known and
imitated being the BSD Socket [POSIX] interface (Socket API). The imitated being the BSD Socket [POSIX] interface (Socket API). The
naming of objects and functions across these APIs is not consistent, naming of objects and functions across these APIs is not consistent,
and varies depending on the protocol being used. For example, and varies depending on the protocol being used. For example,
sending and receiving streams of data is conceptually the same for sending and receiving streams of data is conceptually the same for
both an unencrypted Transmission Control Protocol (TCP) stream and both an unencrypted Transmission Control Protocol (TCP) stream and
skipping to change at page 4, line 47 skipping to change at page 4, line 47
This document describes the Transport Services architecture in three This document describes the Transport Services architecture in three
sections: sections:
* Section 2 describes how the API model of Transport Services * Section 2 describes how the API model of Transport Services
differs from traditional socket-based APIs. Specifically, it differs from traditional socket-based APIs. Specifically, it
offers asynchronous event-driven interaction, the use of messages offers asynchronous event-driven interaction, the use of messages
for data transfer, and the flexibility to use different transport for data transfer, and the flexibility to use different transport
protocols and paths without requiring major changes to the protocols and paths without requiring major changes to the
application. application.
* Section 3 explains the design principles behind the Transport * Section 3 explains the fundamental requirements for a Transport
Services API. These principles are intended to make sure that Services API. These principles are intended to make sure that
transport protocols can continue to be enhanced and evolve without transport protocols can continue to be enhanced and evolve without
requiring too many changes by application developers. requiring significant changes by application developers.
* Section 4 presents the Transport Services architecture diagram and * Section 4 presents the Transport Services architecture diagram and
defines the concepts that are used by both the API and defines the concepts that are used by both the API and
implementation documents. The Preconnection allows applications implementation documents. The Preconnection allows applications
to configure Connection Properties, and the Connection represents to configure Connection Properties, and the Connection represents
an object that can be used to send and receive Messages. an object that can be used to send and receive Messages.
1.3. Specification of Requirements 1.3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 43 skipping to change at page 6, line 43
The Transport Services API [I-D.ietf-taps-interface] defines the The Transport Services API [I-D.ietf-taps-interface] defines the
mechanism for an application to create network connections and mechanism for an application to create network connections and
transfer data. The implementation [I-D.ietf-taps-impl] is transfer data. The implementation [I-D.ietf-taps-impl] is
responsible for mapping the API to the various available transport responsible for mapping the API to the various available transport
protocols and managing the available network interfaces and paths. protocols and managing the available network interfaces and paths.
There are key differences between the architecture of the Transport There are key differences between the architecture of the Transport
Services system and the architecture of the Socket API: the Transport Services system and the architecture of the Socket API: the Transport
Services API is asynchronous and event-driven; it uses messages for Services API is asynchronous and event-driven; it uses messages for
representing data transfer to applications; and it assumes an representing data transfer to applications; and it describes how
implementation that can use multiple IP addresses, multiple implementations can use multiple IP addresses, multiple protocols,
protocols, multiple paths, and provide multiple application streams. multiple paths, and provide multiple application streams.
2.1. Event-Driven API 2.1. Event-Driven API
Originally, sockets presented a blocking interface for establishing Originally, sockets presented a blocking interface for establishing
connections and transferring data. However, most modern applications connections and transferring data. However, most modern applications
interact with the network asynchronously. Emulation of an interact with the network asynchronously. Emulation of an
asynchronous interface using sockets generally uses a try-and-fail asynchronous interface using sockets generally uses a try-and-fail
model. If the application wants to read, but data has not yet been model. If the application wants to read, but data has not yet been
received from the peer, the call to read will fail. The application received from the peer, the call to read will fail. The application
then waits and can try again later. then waits and can try again later.
skipping to change at page 9, line 9 skipping to change at page 9, line 12
further implement fallback mechanisms if connection establishment of further implement fallback mechanisms if connection establishment of
one protocol fails or performance is detected to be unsatisfactory. one protocol fails or performance is detected to be unsatisfactory.
Flexibility after connection establishment is also important. Flexibility after connection establishment is also important.
Transport protocols that can migrate between multiple network-layer Transport protocols that can migrate between multiple network-layer
interfaces need to be able to process and react to interface changes. interfaces need to be able to process and react to interface changes.
Protocols that support multiple application-layer streams need to Protocols that support multiple application-layer streams need to
support initiating and receiving new streams using existing support initiating and receiving new streams using existing
connections. connections.
3. Design Principles 3. API and Implementation Requirements
The goal of the Transport Services architecture is to redefine the The goal of the Transport Services architecture is to redefine the
interface between applications and transports in a way that allows interface between applications and transports in a way that allows
the transport layer to evolve and improve without fundamentally the transport layer to evolve and improve without fundamentally
changing the contract with the application. This requires a careful changing the contract with the application. This requires a careful
consideration of how to expose the capabilities of protocols. consideration of how to expose the capabilities of protocols.
There are several degrees in which a Transport Services system is There are several degrees in which a Transport Services system is
intended to offer flexibility to an application: it can provide intended to offer flexibility to an application: it can provide
access to multiple sets of protocols and protocol features; it can access to multiple sets of protocols and protocol features; it can
use these protocols across multiple paths that could have different use these protocols across multiple paths that could have different
performance and functional characteristics; and it can communicate performance and functional characteristics; and it can communicate
with different remote systems to optimize performance, robustness to with different remote systems to optimize performance, robustness to
failure, or some other metric. Beyond these, if the API for the failure, or some other metric. Beyond these, if the API for the
system remains the same over time, new protocols and features could system remains the same over time, new protocols and features can be
be added to the system's implementation without requiring changes in added to the system's implementation without requiring changes in
applications for adoption. applications for adoption.
3.1. Common APIs for Common Features The normative requirements described here allow Transport Services
APIs and Implementations to provide this functionlity without causing
incompatibility or introducing security vulnerabilities. The rest of
this document describes the architecture non-normatively.
Functionality that is common across multiple transport protocols 3.1. Provide Common APIs for Common Features
ought to be accessible through a unified set of API calls. An
application using a Transport Services API can implement logic for
its basic use of transport networking (establishing the transport,
and sending and receiving data) once, and expect that implementation
to continue to function as the transports change.
As a baseline, any Transport Services API needs to allow access to Any functionality that is common across multiple transport protocols
the distilled minimal set of features offered by transport protocols SHOULD be made accessible through a unified set of Transport Services
API calls. As a baseline, any Transport Services API MUST allow
access to the minimal set of features offered by transport protocols
[I-D.ietf-taps-minset]. [I-D.ietf-taps-minset].
3.2. Access to Specialized Features An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via
Properties. A Transport Services API SHOULD offer Properties that
are common to multiple transport protocols, in order to enable the
system to appropriately select between protocols that offer
equivalent features. Similarly, a Transport Services API SHOULD
offer Properties that are applicable to a variety of network layer
interfaces and paths, in order to permit racing of different network
paths without affecting the applications using the system. Each
Property is expected to have a default value.
The default values for Properties SHOULD be selected to ensure
correctness for the widest set of applications, while providing the
widest set of options for selection. For example, since both
applications that require reliability and those that do not require
reliability can function correctly when a protocol provides
reliability, reliability ought to be enabled by default. As another
example, the default value for a Property regarding the selection of
network interfaces ought to permit as many interfaces as possible.
Applications using a Transport Services system interface are REQUIRED
to be robust to the automated selection provided by the system, where
the automated selection is constrained by the requirements and
preferences expressed by the application.
3.2. Allow Access to Specialized Features
There are applications that will need to control fine-grained details There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure of transport protocols to optimize their behavior and ensure
compatibility with remote systems. A Transport Services system compatibility with remote systems. A Transport Services system
therefore ought to also permit more specialized protocol features to therefore SHOULD permit more specialized protocol features to be
be used. The interface for these specialized options ought to be used.
exposed differently from the common options to ensure flexibility.
A specialized feature could be required by an application only when A specialized feature could be required by an application only when
using a specific protocol, and not when using others. For example, using a specific protocol, and not when using others. For example,
if an application is using TCP, it could require control over the if an application is using TCP, it could require control over the
User Timeout Option for TCP; these options would not take effect for User Timeout Option for TCP; these options would not take effect for
other transport protocols. In such cases, the API ought to expose other transport protocols. In such cases, the API ought to expose
the features in such a way that they take effect when a particular the features in such a way that they take effect when a particular
protocol is selected, but do not imply that only that protocol could protocol is selected, but do not imply that only that protocol could
be used. For example, if the API allows an application to specify a be used. For example, if the API allows an application to specify a
preference to use the User Timeout Option, communication would not preference to use the User Timeout Option, communication would not
fail when a protocol such as QUIC is selected. fail when a protocol such as QUIC is selected.
Other specialized features, however, could be strictly required by an Other specialized features, however, can be strictly required by an
application and thus constrain the set of protocols that can be used. application and thus constrain the set of protocols that can be used.
For example, if an application requires support for automatic For example, if an application requires support for automatic
handover or failover for a connection, only protocol stacks that handover or failover for a connection, only protocol stacks that
provide this feature are eligible to be used, e.g., protocol stacks provide this feature are eligible to be used, e.g., protocol stacks
that include a multipath protocol or a protocol that supports that include a multipath protocol or a protocol that supports
connection migration. A Transport Services API needs to allow connection migration. A Transport Services API needs to allow
applications to define such requirements and constrain the system's applications to define such requirements and constrain the system's
options. Since such options are not part of the core/common options. Since such options are not part of the core/common
features, it will generally be simple for an application to modify features, it will generally be simple for an application to modify
its set of constraints and change the set of allowable protocol its set of constraints and change the set of allowable protocol
features without changing the core implementation. features without changing the core implementation.
3.3. Scope for API and Implementation Definitions 3.3. Select Equivalent Protocol Stacks
The Transport Services API is envisioned as the abstract model for a A Transport Services implementation can select Protocol Stacks based
family of APIs that share a common way to expose transport features on the Properties communicated by the application. If two different
and encourage flexibility. The abstract API definition Protocol Stacks can be safely swapped, or raced in parallel (see
[I-D.ietf-taps-interface] describes this interface and how it can be Section 4.2.2), then they are considered to be "equivalent".
exposed to application developers. Equivalent Protocol Stacks are defined as stacks that can provide the
same transport properties and interface expectations as requested by
the application.
Implementations that provide the Transport Services API The following two examples show non-equivalent Protocol Stacks:
[I-D.ietf-taps-impl] will vary due to system-specific support and the
needs of the deployment scenario. It is expected that all
implementations of Transport Services will offer the entire mandatory
API. All implementations are expected to offer an API that is
sufficient to use the distilled minimal set of features offered by
transport protocols [I-D.ietf-taps-minset], including API support for
TCP and UDP transport. However, some features provided by this API
will not be functional in certain implementations. For example, it
is possible that some very constrained devices might not have a full
TCP implementation beneath the API.
To preserve flexibility and compatibility with future protocols, top- * If the application requires preservation of message boundaries, a
level features in the Transport Services API ought to avoid Protocol Stack that runs UDP as the top-level interface to the
referencing particular transport protocols. The mappings of these application is not equivalent to a Protocol Stack that runs TCP as
API features to specific implementations of each feature is explained the top-level interface. A UDP stack would allow an application
in the [I-D.ietf-taps-impl] along with the implications of the to read out message boundaries based on datagrams sent from the
feature on existing protocols. It is expected that remote system, whereas TCP does not preserve message boundaries on
its own, but needs a framing protocol on top to determine message
boundaries.
[I-D.ietf-taps-interface] will be updated and supplemented as new * If the application specifies that it requires reliable
protocols and protocol features are developed. transmission of data, then a Protocol Stack using UDP without any
reliability layer on top would not be allowed to replace a
Protocol Stack using TCP.
The following example shows equivalent Protocol Stacks:
* If the application does not require reliable transmission of data,
then a Protocol Stack that adds reliability could be regarded as
an equivalent Protocol Stack as long as providing this would not
conflict with any other application-requested properties.
To ensure that security protocols are not incorrectly swapped,
Transport Services systems MUST only select Protocol Stacks that meet
application requirements ([I-D.ietf-taps-transport-security]).
Systems SHOULD only race Protocol Stacks where the transport security
protocols within the stacks are identical. Transport Services
systems MUST NOT automatically fall back from secure protocols to
insecure protocols, or to weaker versions of secure protocols. A
Transport Services system MAY allow applications to explicitly
specify that fallback to a specific other version of a protocol is
allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not
available.
3.4. Maintain Interoperability
It is important to note that neither the Transport Services API It is important to note that neither the Transport Services API
[I-D.ietf-taps-interface] nor the Implementation document [I-D.ietf-taps-interface] nor the Implementation document
[I-D.ietf-taps-impl] define new protocols or protocol capabilities [I-D.ietf-taps-impl] define new protocols or protocol capabilities
that affect what is communicated across the network. Use of a that affect what is communicated across the network. Use of a
Transport Services system does not require that a peer on the other Transport Services system MUST NOT require that a peer on the other
side of a connection uses the same API or implementation. A side of a connection uses the same API or implementation. A
Transport Services system acting as a connection initiator can Transport Services system acting as a connection initiator is able to
communicate with any existing system that implements the transport communicate with any existing system that implements the transport
protocol(s) selected by the Transport Services system. Similarly, a protocol(s) and all the required properties selected by the Transport
Transport Services system acting as a listener can receive Services system. Similarly, a Transport Services system acting as a
connections for any protocol that is supported by the system from listener can receive connections for any protocol that is supported
existing initiators that implement the protocol, independent of by the system from existing initiators that implement the protocol,
whether the initiator uses Transport Services as well or not. independent of whether the initiator uses a Transport Services system
or not.
In normal use, a Transport Services system SHOULD result in
consistent protocol and interface selection decisions for the same
network conditions given the same set of Properties. This is
intended to provide predictable outcomes to the application using the
API.
4. Transport Services Architecture and Concepts 4. Transport Services Architecture and Concepts
The concepts defined in this document are intended primarily for use The concepts defined in this document are intended primarily for use
in the documents and specifications that describe the Transport in the documents and specifications that describe the Transport
Services architecture and API. While the specific terminology can be Services architecture and API. While the specific terminology can be
used in some implementations, it is expected that there will remain a used in some implementations, it is expected that there will remain a
variety of terms used by running code. variety of terms used by running code.
The architecture divides the concepts for Transport Services into two The architecture divides the concepts for Transport Services into two
skipping to change at page 19, line 38 skipping to change at page 20, line 43
system should not attempt to deliver any outstanding data. This system should not attempt to deliver any outstanding data. This
is intended for immediate termination of a connection, without is intended for immediate termination of a connection, without
cleaning up state. cleaning up state.
4.1.7. Connection Groups 4.1.7. Connection Groups
A Connection Group is a set of Connections that share properties and A Connection Group is a set of Connections that share properties and
caches. For multiplexing transport protocols, only Connections caches. For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed within the same Connection Group are allowed to be multiplexed
together. An application can explicitly define Connection Groups to together. An application can explicitly define Connection Groups to
control caching boundaries, as discussed in Section 4.2.4. control caching boundaries, as discussed in Section 4.2.3.
4.2. Transport Services Implementation Concepts 4.2. Transport Services Implementation Concepts
This section defines the set of objects used internally to a system This section defines the set of objects used internally to a system
or library to implement the functionality needed to provide a or library to implement the functionality needed to provide a
transport service across a network, as required by the abstract transport service across a network, as required by the abstract
interface. interface.
* Path: Represents an available set of properties that a local * Path: Represents an available set of properties that a local
system can use to communicate with a remote system, such as system can use to communicate with a remote system, such as
skipping to change at page 21, line 34 skipping to change at page 22, line 42
addresses and DNS servers, attempts across different Paths will addresses and DNS servers, attempts across different Paths will
perform separate DNS resolution steps, which can lead to further perform separate DNS resolution steps, which can lead to further
racing of the resolved Remote Endpoints. racing of the resolved Remote Endpoints.
* Remote Endpoint Racing: Remote Endpoint Racing is the act of * Remote Endpoint Racing: Remote Endpoint Racing is the act of
attempting to establish, or scheduling attempts to establish, attempting to establish, or scheduling attempts to establish,
multiple Protocol Stacks that differ based on the specific multiple Protocol Stacks that differ based on the specific
representation of the Remote Endpoint, such as a particular IP representation of the Remote Endpoint, such as a particular IP
address that was resolved from a DNS hostname. address that was resolved from a DNS hostname.
4.2.3. Protocol Stack Equivalence 4.2.3. Separating Connection Groups
The Transport Services architecture defines a mechanism that allows
applications to easily make use of various network paths and Protocol
Stacks without requiring major changes in application logic. In some
cases, changing which Protocol Stacks or network paths are used will
require updating the preferences expressed by the application that
uses the Transport Services system. For example, an application can
enable the use of a multipath or multistreaming transport protocol by
modifying the properties in its Pre-Connection configuration. In
some cases, however, the Transport Services system will be able to
automatically change Protocol Stacks without an update to the
application, either by selecting a new stack entirely, or by racing
multiple candidate Protocol Stacks during connection establishment.
This functionality in the API can be a powerful driver of new
protocol adoption, but needs to be constrained carefully to avoid
unexpected behavior that can lead to functional or security problems.
If two different Protocol Stacks can be safely swapped, or raced in
parallel (see Section 4.2.2), then they are considered to be
"equivalent". Equivalent Protocol Stacks need to meet the following
criteria:
1. Both stacks MUST offer the interface requested by the application
for connection establishment and data transmission. For example,
if an application requires preservation of message boundaries, a
Protocol Stack that runs UDP as the top-level interface to the
application is not equivalent to a Protocol Stack that runs TCP
as the top-level interface. A UDP stack would allow an
application to read out message boundaries based on datagrams
sent from the remote system, whereas TCP does not preserve
message boundaries on its own, but needs a framing protocol on
top to determine message boundaries.
2. Both stacks MUST offer the transport services that are requested
by the application. For example, if an application specifies
that it requires reliable transmission of data, then a Protocol
Stack using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP. However, if the
application does not require reliability, then a Protocol Stack
that adds reliability could be regarded as an equivalent Protocol
Stack as long as providing this would not conflict with any other
application-requested properties.
3. Both stacks MUST offer security protocols and parameters as
requested by the application [I-D.ietf-taps-transport-security].
Security features and properties, such as cryptographic
algorithms, peer authentication, and identity privacy vary across
security protocols, and across versions of security protocols.
Protocol equivalence ought not to be assumed for different
protocols or protocol versions, even if they offer similar
application configuration options. To ensure that security
protocols are not incorrectly swapped, Transport Services systems
SHOULD only automatically generate equivalent Protocol Stacks
when the transport security protocols within the stacks are
identical. Specifically, a Transport Services system would
consider protocols identical only if they are of the same type
and version. For example, the same version of TLS running over
two different transport Protocol Stacks are considered
equivalent, whereas TLS 1.2 and TLS 1.3 [RFC8446] are not
considered equivalent. However, Transport Services systems MAY
allow applications to indicate that they consider two different
transport protocols equivalent, e.g., to allow fallback to TLS
1.2 if TLS 1.3 is not available.
4.2.4. Separating Connection Groups
By default, stored properties of the implementation, such as cached By default, stored properties of the implementation, such as cached
protocol state, cached path state, and heuristics, may be shared protocol state, cached path state, and heuristics, may be shared
(e.g. across multiple connections in an application). This provides (e.g. across multiple connections in an application). This provides
efficiency and convenience for the application, since the Transport efficiency and convenience for the application, since the Transport
Services implementation can automatically optimize behavior. Services implementation can automatically optimize behavior.
There are several reasons, however, that an application might want to There are several reasons, however, that an application might want to
explicitly isolate some Connections. These reasons include: explicitly isolate some Connections. These reasons include:
skipping to change at page 24, line 16 skipping to change at page 23, line 47
The Transport Services architecture does not recommend use of The Transport Services architecture does not recommend use of
specific security protocols or algorithms. Its goal is to offer ease specific security protocols or algorithms. Its goal is to offer ease
of use for existing protocols by providing a generic security-related of use for existing protocols by providing a generic security-related
interface. Each provided interface translates to an existing interface. Each provided interface translates to an existing
protocol-specific interface provided by supported security protocols. protocol-specific interface provided by supported security protocols.
For example, trust verification callbacks are common parts of TLS For example, trust verification callbacks are common parts of TLS
APIs. Transport Services APIs will expose similar functionality APIs. Transport Services APIs will expose similar functionality
[I-D.ietf-taps-transport-security]. [I-D.ietf-taps-transport-security].
As described above in Section 4.2.3, if a Transport Services system As described above in Section 3.3, if a Transport Services system
races between two different Protocol Stacks, both SHOULD use the same races between two different Protocol Stacks, both need to use the
security protocols and options. However, a Transport Services system same security protocols and options. However, a Transport Services
MAY race different security protocols, e.g., if the application system can race different security protocols, e.g., if the
explicitly specifies that it considers them equivalent. application explicitly specifies that it considers them equivalent.
Applications need to ensure that they use security APIs Applications need to ensure that they use security APIs
appropriately. In cases where applications use an interface to appropriately. In cases where applications use an interface to
provide sensitive keying material, e.g., access to private keys or provide sensitive keying material, e.g., access to private keys or
copies of pre-shared keys (PSKs), key use needs to be validated. For copies of pre-shared keys (PSKs), key use needs to be validated. For
example, applications ought not to use PSK material created for the example, applications ought not to use PSK material created for the
Encapsulating Security Protocol (ESP, part of IPsec) [RFC4303] with Encapsulating Security Protocol (ESP, part of IPsec) [RFC4303] with
QUIC, and applications ought not to use private keys intended for QUIC, and applications ought not to use private keys intended for
server authentication as keys for client authentication. server authentication as keys for client authentication.
Moreover, Transport Services systems MUST NOT automatically fall back Moreover, Transport Services systems must not automatically fall back
from secure protocols to insecure protocols, or to weaker versions of from secure protocols to insecure protocols, or to weaker versions of
secure protocols. For example, if an application requests a specific secure protocols (see Section 3.3). For example, if an application
version of TLS, but the desired version of TLS is not available, its requests a specific version of TLS, but the desired version of TLS is
connection will fail. Applications are thus responsible for not available, its connection will fail. Applications are thus
implementing security protocol fallback or version fallback by responsible for implementing security protocol fallback or version
creating multiple Transport Services Connections, if so desired. fallback by creating multiple Transport Services Connections, if so
Alternatively, a Transport Services system MAY allow applications to desired. Alternatively, a Transport Services system MAY allow
specify that fallback to a specific other version of a protocol is applications to specify that fallback to a specific other version of
allowed. a protocol is allowed.
7. Acknowledgements 7. Acknowledgements
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreements No. 644334 research and innovation programme under grant agreements No. 644334
(NEAT) and No. 688421 (MAMI). (NEAT) and No. 688421 (MAMI).
This work has been supported by Leibniz Prize project funds of DFG - This work has been supported by Leibniz Prize project funds of DFG -
German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ
FE 570/4-1). FE 570/4-1).
skipping to change at page 25, line 24 skipping to change at page 25, line 5
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
Pauly, "An Abstract Application Layer Interface to Pauly, "An Abstract Application Layer Interface to
Transport Services", Work in Progress, Internet-Draft, Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-interface-05, 4 November 2019, draft-ietf-taps-interface-06, 9 March 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-taps- <http://www.ietf.org/internet-drafts/draft-ietf-taps-
interface-05.txt>. interface-06.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Jones, T., Tiesel, P., Perkins, C., and M. Welzl, Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", Work in "Implementing Interfaces to Transport Services", Work in
Progress, Internet-Draft, draft-ietf-taps-impl-05, 4 Progress, Internet-Draft, draft-ietf-taps-impl-06, 9 March
November 2019, <http://www.ietf.org/internet-drafts/draft- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-
ietf-taps-impl-05.txt>. taps-impl-06.txt>.
[I-D.ietf-taps-minset] [I-D.ietf-taps-minset]
Welzl, M. and S. Gjessing, "A Minimal Set of Transport Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", Work in Progress, Internet- Services for End Systems", Work in Progress, Internet-
Draft, draft-ietf-taps-minset-11, 27 September 2018, Draft, draft-ietf-taps-minset-11, 27 September 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-taps- <http://www.ietf.org/internet-drafts/draft-ietf-taps-
minset-11.txt>. minset-11.txt>.
[I-D.ietf-taps-transport-security] [I-D.ietf-taps-transport-security]
Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction Between Security Wood, "A Survey of the Interaction Between Security
Protocols and Transport Services", Work in Progress, Protocols and Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-transport-security-11, 5 Internet-Draft, draft-ietf-taps-transport-security-12, 23
March 2020, <http://www.ietf.org/internet-drafts/draft- April 2020, <http://www.ietf.org/internet-drafts/draft-
ietf-taps-transport-security-11.txt>. ietf-taps-transport-security-12.txt>.
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open -- Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7", group Technical Standard: Base Specifications, Issue 7",
2008. 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
skipping to change at page 27, line 21 skipping to change at page 27, line 4
Authors' Addresses Authors' Addresses
Tommy Pauly (editor) Tommy Pauly (editor)
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
Brian Trammell (editor) Brian Trammell (editor)
Google Google Switzerland GmbH
Gustav-Gull-Platz 1 Gustav-Gull-Platz 1
CH- 8004 Zurich CH- 8004 Zurich
Switzerland Switzerland
Email: ietf@trammell.ch Email: ietf@trammell.ch
Anna Brunstrom Anna Brunstrom
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
SE- 651 88 Karlstad 651 88 Karlstad
Sweden Sweden
Email: anna.brunstrom@kau.se Email: anna.brunstrom@kau.se
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
Fraser Noble Building Fraser Noble Building
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
skipping to change at page 28, line 18 skipping to change at page 27, line 44
Email: csp@csperkins.org Email: csp@csperkins.org
Philipp S. Tiesel Philipp S. Tiesel
TU Berlin TU Berlin
Einsteinufer 25 Einsteinufer 25
10587 Berlin 10587 Berlin
Germany Germany
Email: philipp@tiesel.net Email: philipp@tiesel.net
Chris Wood Christopher A. Wood
Apple Inc. Cloudflare
One Apple Park Way 101 Townsend St
Cupertino, California 95014, San Francisco,
United States of America United States of America
Email: cawood@apple.com Email: caw@heapingbits.net
 End of changes. 42 change blocks. 
179 lines changed or deleted 161 lines changed or added

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