draft-ietf-taps-arch-08.txt | draft-ietf-taps-arch-09.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: 14 January 2021 Google Switzerland GmbH | Expires: 6 May 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.A. Wood | C.A. Wood | |||
Cloudflare | Cloudflare | |||
13 July 2020 | 2 November 2020 | |||
An Architecture for Transport Services | An Architecture for Transport Services | |||
draft-ietf-taps-arch-08 | draft-ietf-taps-arch-09 | |||
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 describes how implementations 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 | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
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 14 January 2021. | This Internet-Draft will expire on 6 May 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 37 ¶ | skipping to change at page 2, line 37 ¶ | |||
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. API and Implementation Requirements . . . . . . . . . . . . . 9 | 3. API and Implementation Requirements . . . . . . . . . . . . . 9 | |||
3.1. Provide Common APIs for Common Features . . . . . . . . . 9 | 3.1. Provide Common APIs for Common Features . . . . . . . . . 9 | |||
3.2. Allow Access to Specialized Features . . . . . . . . . . 10 | 3.2. Allow Access to Specialized Features . . . . . . . . . . 10 | |||
3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11 | 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11 | |||
3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12 | 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12 | |||
4. Transport Services Architecture and Concepts . . . . . . . . 12 | 4. Transport Services Architecture and Concepts . . . . . . . . 12 | |||
4.1. Transport Services API Concepts . . . . . . . . . . . . . 13 | 4.1. Transport Services API Concepts . . . . . . . . . . . . . 13 | |||
4.1.1. Connections and Related Objects . . . . . . . . . . . 15 | 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 15 | |||
4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 16 | 4.1.2. Connections and Related Objects . . . . . . . . . . . 15 | |||
4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 17 | 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 16 | |||
4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 18 | 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 17 | |||
4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 19 | 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 18 | |||
4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 20 | 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 19 | |||
4.1.7. Connection Groups . . . . . . . . . . . . . . . . . . 20 | 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 20 | |||
4.2. Transport Services Implementation Concepts . . . . . . . 20 | 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 20 | |||
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 21 | 4.2. Transport Services Implementation Concepts . . . . . . . 21 | |||
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 22 | ||||
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22 | 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22 | |||
4.2.3. Separating Connection Groups . . . . . . . . . . . . 22 | 4.2.3. Separating Connection Groups . . . . . . . . . . . . 23 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 25 | 8.2. Informative References . . . . . . . . . . . . . . . . . 25 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
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 10 ¶ | skipping to change at page 4, line 10 ¶ | |||
Services Architecture does not require that all APIs and | Services Architecture does not require that all APIs and | |||
implementations are identical, a common minimal set of features | implementations are identical, a common minimal set of features | |||
represented in a consistent fashion will enable applications to be | represented in a consistent fashion will enable applications to be | |||
easily ported from one system to another. | easily ported from one system to another. | |||
1.1. Background | 1.1. Background | |||
The Transport Services architecture is based on the survey of | The Transport Services architecture is based on the survey of | |||
services provided by IETF transport protocols and congestion control | services provided by IETF transport protocols and congestion control | |||
mechanisms [RFC8095], and the distilled minimal set of the features | mechanisms [RFC8095], and the distilled minimal set of the features | |||
offered by transport protocols [I-D.ietf-taps-minset]. These | offered by transport protocols [RFC8923]. These documents identified | |||
documents identified common features and patterns across all | common features and patterns across all transport protocols developed | |||
transport protocols developed thus far in the IETF. | thus far in the IETF. | |||
Since transport security is an increasingly relevant aspect of using | Since transport security is an increasingly relevant aspect of using | |||
transport protocols on the Internet, this architecture also considers | transport protocols on the Internet, this architecture also considers | |||
the impact of transport security protocols on the feature-set exposed | the impact of transport security protocols on the feature-set exposed | |||
by Transport Services [I-D.ietf-taps-transport-security]. | by Transport Services [RFC8922]. | |||
One of the key insights to come from identifying the minimal set of | One of the key insights to come from identifying the minimal set of | |||
features provided by transport protocols [I-D.ietf-taps-minset] was | features provided by transport protocols [RFC8923] was that features | |||
that features either require application interaction and guidance | either require application interaction and guidance (referred to in | |||
(referred to in that document as Functional or Optimizing Features), | that document as Functional or Optimizing Features), or else can be | |||
or else can be handled automatically by a system implementing | handled automatically by a system implementing Transport Services | |||
Transport Services (referred to as Automatable Features). Among the | (referred to as Automatable Features). Among the identified | |||
Functional and Optimizing Features, some were common across all or | Functional and Optimizing Features, some were common across all or | |||
nearly all transport protocols, while others could be seen as | nearly all transport protocols, while others could be seen as | |||
features that, if specified, would only be useful with a subset of | features that, if specified, would only be useful with a subset of | |||
protocols, but would not harm the functionality of other protocols. | protocols, but would not harm the functionality of other protocols. | |||
For example, some protocols can deliver messages faster for | For example, some protocols can deliver messages faster for | |||
applications that do not require messages to arrive in the order in | applications that do not require messages to arrive in the order in | |||
which they were sent. However, this functionality needs to be | which they were sent. However, this functionality needs to be | |||
explicitly allowed by the application, since reordering messages | explicitly allowed by the application, since reordering messages | |||
would be undesirable in many cases. | would be undesirable in many cases. | |||
skipping to change at page 7, line 17 ¶ | skipping to change at page 7, line 17 ¶ | |||
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. | |||
In contrast to sockets, all interaction with a Transport Services | In contrast to sockets, all interaction with a Transport Services | |||
system is expected to be asynchronous, and use an event-driven model | system is expected to be asynchronous, and use an event-driven model | |||
(see Section 4.1.5). For example, if the application wants to read, | (see Section 4.1.6). For example, if the application wants to read, | |||
its call to read will not complete immediately, but will deliver an | its call to read will not complete immediately, but will deliver an | |||
event containing the received data once it is available. Error | event containing the received data once it is available. Error | |||
handling is also asynchronous; a failure to send results in an | handling is also asynchronous; a failure to send results in an | |||
asynchronous send error as an event. | asynchronous send error as an event. | |||
The Transport Services API also delivers events regarding the | The Transport Services API also delivers events regarding the | |||
lifetime of a connection and changes in the available network links, | lifetime of a connection and changes in the available network links, | |||
which were not previously made explicit in sockets. | which were not previously made explicit in sockets. | |||
Using asynchronous events allows for a more natural interaction model | Using asynchronous events allows for a more natural interaction model | |||
skipping to change at page 8, line 23 ¶ | skipping to change at page 8, line 23 ¶ | |||
Transport Services system could decide to not deliver a message, | Transport Services system could decide to not deliver a message, | |||
either following packet loss or because it has missed a deadline. | either following packet loss or because it has missed a deadline. | |||
In particular, this can avoid (re-)sending data that relies on a | In particular, this can avoid (re-)sending data that relies on a | |||
previous transmission that was never received. | previous transmission that was never received. | |||
* the ability to automatically assign messages and connections to | * the ability to automatically assign messages and connections to | |||
underlying transport connections to utilize multi-streaming and | underlying transport connections to utilize multi-streaming and | |||
pooled connections. | pooled connections. | |||
Allowing applications to interact with messages is backwards- | Allowing applications to interact with messages is backwards- | |||
compatible with existings protocols and APIs, as it does not change | compatible with existing protocols and APIs because it does not | |||
the wire format of any protocol. Instead, it gives the protocol | change the wire format of any protocol. Instead, it gives the | |||
stack additional information to allow it to make better use of modern | protocol stack additional information to allow it to make better use | |||
transport services, while simplifying the application's role in | of modern transport services, while simplifying the application's | |||
parsing data. For protocols which natively use a streaming | role in parsing data. For protocols which natively use a streaming | |||
abstraction, framers (Section 4.1.4) bridge the gap between the two | abstraction, framers (Section 4.1.5) bridge the gap between the two | |||
abstractions. | abstractions. | |||
2.3. Flexibile Implementation | 2.3. Flexibile Implementation | |||
Sockets, for protocols like TCP, are generally limited to connecting | Sockets, for protocols like TCP, are generally limited to connecting | |||
to a single address over a single interface. They also present a | to a single address over a single interface. They also present a | |||
single stream to the application. Software layers built upon sockets | single stream to the application. Software layers built upon sockets | |||
often propagate this limitation of a single-address single-stream | often propagate this limitation of a single-address single-stream | |||
model. The Transport Services architecture is designed to handle | model. The Transport Services architecture is designed to handle | |||
multiple candidate endpoints, protocols, and paths; and support | multiple candidate endpoints, protocols, and paths; and support | |||
skipping to change at page 9, line 32 ¶ | skipping to change at page 9, line 32 ¶ | |||
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 can be | system remains the same over time, new protocols and features can 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. | |||
The normative requirements described here allow Transport Services | The normative requirements described here allow Transport Services | |||
APIs and Implementations to provide this functionlity without causing | APIs and Implementations to provide this functionality without | |||
incompatibility or introducing security vulnerabilities. The rest of | causing incompatibility or introducing security vulnerabilities. The | |||
this document describes the architecture non-normatively. | rest of this document describes the architecture non-normatively. | |||
3.1. Provide Common APIs for Common Features | 3.1. Provide Common APIs for Common Features | |||
Any functionality that is common across multiple transport protocols | Any functionality that is common across multiple transport protocols | |||
SHOULD be made accessible through a unified set of Transport Services | SHOULD be made accessible through a unified set of Transport Services | |||
API calls. As a baseline, any Transport Services API MUST allow | API calls. As a baseline, any Transport Services API MUST allow | |||
access to the minimal set of features offered by transport protocols | access to the minimal set of features offered by transport protocols | |||
[I-D.ietf-taps-minset]. | [RFC8923]. | |||
An application can specify constraints and preferences for the | An application can specify constraints and preferences for the | |||
protocols, features, and network interfaces it will use via | protocols, features, and network interfaces it will use via | |||
Properties. A Transport Services API SHOULD offer Properties that | Properties. A Transport Services API SHOULD offer Properties that | |||
are common to multiple transport protocols, in order to enable the | are common to multiple transport protocols, which enables the system | |||
system to appropriately select between protocols that offer | to appropriately select between protocols that offer equivalent | |||
equivalent features. Similarly, a Transport Services API SHOULD | features. Similarly, a Transport Services API SHOULD offer | |||
offer Properties that are applicable to a variety of network layer | Properties that are applicable to a variety of network layer | |||
interfaces and paths, in order to permit racing of different network | interfaces and paths, which permits racing of different network paths | |||
paths without affecting the applications using the system. Each | without affecting the applications using the system. Each Property | |||
Property is expected to have a default value. | is expected to have a default value. | |||
The default values for Properties SHOULD be selected to ensure | The default values for Properties SHOULD be selected to ensure | |||
correctness for the widest set of applications, while providing the | correctness for the widest set of applications, while providing the | |||
widest set of options for selection. For example, since both | widest set of options for selection. For example, since both | |||
applications that require reliability and those that do not require | applications that require reliability and those that do not require | |||
reliability can function correctly when a protocol provides | reliability can function correctly when a protocol provides | |||
reliability, reliability ought to be enabled by default. As another | reliability, reliability ought to be enabled by default. As another | |||
example, the default value for a Property regarding the selection of | example, the default value for a Property regarding the selection of | |||
network interfaces ought to permit as many interfaces as possible. | network interfaces ought to permit as many interfaces as possible. | |||
skipping to change at page 11, line 48 ¶ | skipping to change at page 11, line 48 ¶ | |||
The following example shows equivalent Protocol Stacks: | The following example shows equivalent Protocol Stacks: | |||
* If the application does not require reliable transmission of data, | * If the application does not require reliable transmission of data, | |||
then a Protocol Stack that adds reliability could be regarded as | then a Protocol Stack that adds reliability could be regarded as | |||
an equivalent Protocol Stack as long as providing this would not | an equivalent Protocol Stack as long as providing this would not | |||
conflict with any other application-requested properties. | conflict with any other application-requested properties. | |||
To ensure that security protocols are not incorrectly swapped, | To ensure that security protocols are not incorrectly swapped, | |||
Transport Services systems MUST only select Protocol Stacks that meet | Transport Services systems MUST only select Protocol Stacks that meet | |||
application requirements ([I-D.ietf-taps-transport-security]). | application requirements ([RFC8922]). Systems SHOULD only race | |||
Systems SHOULD only race Protocol Stacks where the transport security | Protocol Stacks where the transport security protocols within the | |||
protocols within the stacks are identical. Transport Services | stacks are identical. Transport Services systems MUST NOT | |||
systems MUST NOT automatically fall back from secure protocols to | automatically fall back from secure protocols to insecure protocols, | |||
insecure protocols, or to weaker versions of secure protocols. A | or to weaker versions of secure protocols. A Transport Services | |||
Transport Services system MAY allow applications to explicitly | system MAY allow applications to explicitly specify that fallback to | |||
specify that fallback to a specific other version of a protocol is | a specific other version of a protocol is allowed, e.g., to allow | |||
allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not | fallback to TLS 1.2 if TLS 1.3 is not available. | |||
available. | ||||
3.4. Maintain Interoperability | 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 MUST 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 is able to | Transport Services system acting as a connection initiator is able to | |||
skipping to change at page 13, line 46 ¶ | skipping to change at page 13, line 43 ¶ | |||
+-------+--------+ | +-------+--------+ | |||
V | V | |||
Network Layer Interface | Network Layer Interface | |||
Figure 3: Concepts and Relationships in the Transport Services | Figure 3: Concepts and Relationships in the Transport Services | |||
Architecture | Architecture | |||
4.1. Transport Services API Concepts | 4.1. Transport Services API Concepts | |||
Fundamentally, a Transport Services API needs to provide connection | Fundamentally, a Transport Services API needs to provide connection | |||
objects (Section 4.1.1) that allow applications to establish | objects (Section 4.1.2) that allow applications to establish | |||
communication, and then send and receive data. These could be | communication, and then send and receive data. These could be | |||
exposed as handles or referenced objects, depending on the language. | exposed as handles or referenced objects, depending on the language. | |||
Beyond the connection objects, there are several high-level groups of | Beyond the connection objects, there are several high-level groups of | |||
actions that any Transport Services API needs to provide: | actions that any Transport Services API needs to provide: | |||
* Pre-Establishment (Section 4.1.2) encompasses the properties that | * Pre-Establishment (Section 4.1.3) encompasses the properties that | |||
an application can pass to describe its intent, requirements, | an application can pass to describe its intent, requirements, | |||
prohibitions, and preferences for its networking operations. | prohibitions, and preferences for its networking operations. | |||
These properties apply to multiple transport protocols, unless | These properties apply to multiple transport protocols, unless | |||
otherwise specified. Properties specified during Pre- | otherwise specified. Properties specified during Pre- | |||
Establishment can have a large impact on the rest of the | Establishment can have a large impact on the rest of the | |||
interface: they modify how establishment occurs, they influence | interface: they modify how establishment occurs, they influence | |||
the expectations around data transfer, and they determine the set | the expectations around data transfer, and they determine the set | |||
of events that will be supported. | of events that will be supported. | |||
* Establishment (Section 4.1.3) focuses on the actions that an | * Establishment (Section 4.1.4) focuses on the actions that an | |||
application takes on the connection objects to prepare for data | application takes on the connection objects to prepare for data | |||
transfer. | transfer. | |||
* Data Transfer (Section 4.1.4) consists of how an application | * Data Transfer (Section 4.1.5) consists of how an application | |||
represents the data to be sent and received, the functions | represents the data to be sent and received, the functions | |||
required to send and receive that data, and how the application is | required to send and receive that data, and how the application is | |||
notified of the status of its data transfer. | notified of the status of its data transfer. | |||
* Event Handling (Section 4.1.5) defines categories of notifications | * Event Handling (Section 4.1.6) defines categories of notifications | |||
which an application can receive during the lifetime of transport | which an application can receive during the lifetime of transport | |||
objects. Events also provide opportunities for the application to | objects. Events also provide opportunities for the application to | |||
interact with the underlying transport by querying state or | interact with the underlying transport by querying state or | |||
updating maintenance options. | updating maintenance options. | |||
* Termination (Section 4.1.6) focuses on the methods by which data | * Termination (Section 4.1.7) focuses on the methods by which data | |||
transmission is stopped, and state is torn down in the transport. | transmission is stopped, and state is torn down in the transport. | |||
The diagram below provides a high-level view of the actions and | The diagram below provides a high-level view of the actions and | |||
events during the lifetime of a Connection object. Note that some | events during the lifetime of a Connection object. Note that some | |||
actions are alternatives (e.g., whether to initiate a connection or | actions are alternatives (e.g., whether to initiate a connection or | |||
to listen for incoming connections), while others are optional (e.g., | to listen for incoming connections), while others are optional (e.g., | |||
setting Connection and Message Properties in Pre-Establishment) or | setting Connection and Message Properties in Pre-Establishment) or | |||
have been omitted for brevity and simplicity. | have been omitted for brevity and simplicity. | |||
Pre-Establishment : Established : Termination | Pre-Establishment : Established : Termination | |||
----------------- : ----------- : ----------- | ----------------- : ----------- : ----------- | |||
: : | : : | |||
+-- Local Endpoint : Message : | +-- Local Endpoint : Message : | |||
+-- Remote Endpoint : Receive() | : | +-- Remote Endpoint : Receive() | : | |||
+-- Transport Properties : Send() | : | +-- Transport Properties : Send() | : | |||
+-- Security Parameters : | : | +-- Security Parameters : | : | |||
| : | : | | : | : | |||
| InitiateWithSend() | Close() : | | InitiateWithSend() | Close() : | |||
| +---------------+ Initiate() +-----+------+ Abort() : | | +---------------+ Initiate() +-----+------+ Abort() : | |||
+---+ Preconnection |------------->| Connection |-----------> Closed | +---+ Preconnection |------------->| Connection |-----------> Closed | |||
+---------------+ Rendezvous() +------------+ : | +---------------+ Rendezvous() +------------+ : | |||
Listen() | : | | : | Listen() | : | | : | |||
| : | v : | | : | v : | |||
v : | Connection : | v : | Connection : | |||
+----------+ : | Ready : | +----------+ : | Ready : | |||
| Listener |----------------------+ : | | Listener |----------------------+ : | |||
+----------+ Connection Received : | +----------+ Connection Received : | |||
: : | : : | |||
Figure 4: The lifetime of a Connection object | Figure 4: The lifetime of a Connection object | |||
4.1.1. Connections and Related Objects | 4.1.1. Endpoint Objects | |||
* Endpoint: An Endpoint represents an identifier for one side of a | ||||
transport connection. Endpoints can be Local Endpoints or Remote | ||||
Endpoints, and respectively represent an identity that the | ||||
application uses for the source or destination of a connection. | ||||
An Endpoint can be specified at various levels of abstraction, and | ||||
an Endpoint at a higher level of abstraction (such as a hostname) | ||||
can be resolved to more concrete identities (such as IP | ||||
addresses). | ||||
* Remote Endpoint: The Remote Endpoint represents the application's | ||||
identifier for a peer that can participate in a transport | ||||
connection; for example, the combination of a DNS name for the | ||||
peer and a service name/port. | ||||
* Local Endpoint: The Local Endpoint represents the application's | ||||
identifier for itself that it uses for transport connections; for | ||||
example, a local IP address and port. | ||||
4.1.2. Connections and Related Objects | ||||
* Preconnection: A Preconnection object is a representation of a | * Preconnection: A Preconnection object is a representation of a | |||
potential Connection. It has state that describes parameters of a | potential Connection. It has state that describes parameters of a | |||
Connection that might exist in the future: the Local Endpoint from | Connection that might exist in the future: the Local Endpoint from | |||
which that Connection will be established, the Remote Endpoint | which that Connection will be established, the Remote Endpoint | |||
(Section 4.1.2) to which it will connect, and Transport Properties | (Section 4.1.3) to which it will connect, and Transport Properties | |||
that influence the paths and protocols a Connection will use. A | that influence the paths and protocols a Connection will use. A | |||
Preconnection can be fully specified such that it represents a | Preconnection can be fully specified such that it represents a | |||
single possible Connection, or it can be partially specified such | single possible Connection, or it can be partially specified such | |||
that it represents a family of possible Connections. The Local | that it represents a family of possible Connections. The Local | |||
Endpoint (Section 4.1.2) is required if the Preconnection is used | Endpoint (Section 4.1.3) is required if the Preconnection is used | |||
to Listen for incoming Connections. The Local Endpoint is | to Listen for incoming Connections. The Local Endpoint is | |||
optional if it is used to Initiate Connections. The Remote | optional if it is used to Initiate Connections. The Remote | |||
Endpoint is required in the Preconnection that is used to Initiate | Endpoint is required in the Preconnection that is used to Initiate | |||
Connections. The Remote Endpoint is optional if it is used to | Connections. The Remote Endpoint is optional if it is used to | |||
Listen for incoming Connections. The Local Endpoint and the | Listen for incoming Connections. The Local Endpoint and the | |||
Remote Endpoint are both required if a peer-to-peer Rendezvous is | Remote Endpoint are both required if a peer-to-peer Rendezvous is | |||
to occur based on the Preconnection. | to occur based on the Preconnection. | |||
* Transport Properties: Transport Properties allow the application | * Transport Properties: Transport Properties allow the application | |||
to express their requirements, prohibitions, and preferences and | to express their requirements, prohibitions, and preferences and | |||
configure the Transport Services system. There are three kinds of | configure the Transport Services system. There are three kinds of | |||
Transport Properties: | Transport Properties: | |||
- Selection Properties (Section 4.1.2) that can only be specified | - Selection Properties (Section 4.1.3) that can only be specified | |||
on a Preconnection. | on a Preconnection. | |||
- Connection Properties (Section 4.1.2) that can be specified on | - Connection Properties (Section 4.1.3) that can be specified on | |||
a Preconnection and changed on the Connection. | a Preconnection and changed on the Connection. | |||
- Message Properties (Section 4.1.4) that can be specified as | - Message Properties (Section 4.1.5) that can be specified as | |||
defaults on a Preconnection or a Connection, and can also be | defaults on a Preconnection or a Connection, and can also be | |||
specified during data transfer to affect specific Messages. | specified during data transfer to affect specific Messages. | |||
* Connection: A Connection object represents one or more active | * Connection: A Connection object represents one or more active | |||
transport protocol instances that can send and/or receive Messages | transport protocol instances that can send and/or receive Messages | |||
between local and remote systems. It holds state pertaining to | between local and remote systems. It holds state pertaining to | |||
the underlying transport protocol instances and any ongoing data | the underlying transport protocol instances and any ongoing data | |||
transfers. This represents, for example, an active Connection in | transfers. This represents, for example, an active Connection in | |||
a connection-oriented protocol such as TCP, or a fully-specified | a connection-oriented protocol such as TCP, or a fully-specified | |||
5-tuple for a connectionless protocol such as UDP. It can also | 5-tuple for a connectionless protocol such as UDP. It can also | |||
represent a pool of transport protocol instances, e.g., a set of | represent a pool of transport protocol instances, e.g., a set of | |||
TCP and QUIC connections to equivalent endpoints, or a stream of a | TCP and QUIC connections to equivalent endpoints, or a stream of a | |||
multi-streaming transport protocol instance. Connections can be | multi-streaming transport protocol instance. Connections can be | |||
created from a Preconnection or by a Listener. | created from a Preconnection or by a Listener. | |||
* Listener: A Listener object accepts incoming transport protocol | * Listener: A Listener object accepts incoming transport protocol | |||
connections from remote systems and generates corresponding | connections from remote systems and generates corresponding | |||
Connection objects. It is created from a Preconnection object | Connection objects. It is created from a Preconnection object | |||
that specifies the type of incoming Connections it will accept. | that specifies the type of incoming Connections it will accept. | |||
4.1.2. Pre-Establishment | 4.1.3. Pre-Establishment | |||
* Endpoint: An Endpoint represents an identifier for one side of a | ||||
transport connection. Endpoints can be Local Endpoints or Remote | ||||
Endpoints, and respectively represent an identity that the | ||||
application uses for the source or destination of a connection. | ||||
An Endpoint can be specified at various levels of abstraction, and | ||||
an Endpoint at a higher level of abstraction (such as a hostname) | ||||
can be resolved to more concrete identities (such as IP | ||||
addresses). | ||||
* Remote Endpoint: The Remote Endpoint represents the application's | ||||
identifier for a peer that can participate in a transport | ||||
connection; for example, the combination of a DNS name for the | ||||
peer and a service name/port. | ||||
* Local Endpoint: The Local Endpoint represents the application's | ||||
identifier for itself that it uses for transport connections; for | ||||
example, a local IP address and port. | ||||
* Selection Properties: The Selection Properties consist of the | * Selection Properties: The Selection Properties consist of the | |||
options that an application can set to influence the selection of | properties that an application can set to influence the selection | |||
paths between the local and remote systems, to influence the | of paths between the local and remote systems, to influence the | |||
selection of transport protocols, or to configure the behavior of | selection of transport protocols, or to configure the behavior of | |||
generic transport protocol features. These options can take the | generic transport protocol features. These properties can take | |||
form of requirements, prohibitions, or preferences. Examples of | the form of requirements, prohibitions, or preferences. Examples | |||
options that influence path selection include the interface type | of properties that influence path selection include the interface | |||
(such as a Wi-Fi connection, or a Cellular LTE connection), | type (such as a Wi-Fi connection, or a Cellular LTE connection), | |||
requirements around the largest Message that can be sent, or | requirements around the largest Message that can be sent, or | |||
preferences for throughput and latency properties. Examples of | preferences for throughput and latency. Examples of properties | |||
options that influence protocol selection and configuration of | that influence protocol selection and configuration of transport | |||
transport protocol features include reliability, multipath | protocol features include reliability, multipath support, and fast | |||
support, and fast open support. | open support. | |||
* Connection Properties: The Connection Properties are used to | * Connection Properties: The Connection Properties are used to | |||
configure protocol-specific options and control per-connection | configure protocol-specific options and control per-connection | |||
behavior of the Transport Services system; for example, a | behavior of the Transport Services system; for example, a | |||
protocol-specific Connection Property can express that if TCP is | protocol-specific Connection Property can express that if TCP is | |||
used, the implementation ought to use the User Timeout Option. | used, the implementation ought to use the User Timeout Option. | |||
Note that the presence of such a property does not require that a | Note that the presence of such a property does not require that a | |||
specific protocol will be used. In general, these properties do | specific protocol will be used. In general, these properties do | |||
not explicitly determine the selection of paths or protocols, but | not explicitly determine the selection of paths or protocols, but | |||
can be used in this way by an implementation during connection | can be used by an implementation during connection establishment. | |||
establishment. Connection Properties are specified on a | Connection Properties are specified on a Preconnection prior to | |||
Preconnection prior to Connection establishment, and can be | Connection establishment, and can be modified on the Connection | |||
modified on the Connection later. Changes made to Connection | later. Changes made to Connection Properties after Connection | |||
Properties after Connection establishment take effect on a best- | establishment take effect on a best-effort basis. | |||
effort basis. | ||||
* Security Parameters: Security Parameters define an application's | * Security Parameters: Security Parameters define an application's | |||
requirements for authentication and encryption on a Connection. | requirements for authentication and encryption on a Connection. | |||
They are used by Transport Security protocols (such as those | They are used by Transport Security protocols (such as those | |||
described in [I-D.ietf-taps-transport-security]) to establish | described in [RFC8922]) to establish secure Connections. Examples | |||
secure Connections. Examples of parameters that can be set | of parameters that can be set include local identities, private | |||
include local identities, private keys, supported cryptographic | keys, supported cryptographic algorithms, and requirements for | |||
algorithms, and requirements for validating trust of remote | validating trust of remote identities. Security Parameters are | |||
identities. Security Parameters are primarily associated with a | primarily associated with a Preconnection object, but properties | |||
Preconnection object, but properties related to identities can be | related to identities can be associated directly with Endpoints. | |||
associated directly with Endpoints. | ||||
4.1.4. Establishment Actions | ||||
4.1.3. Establishment Actions | ||||
* Initiate: The primary action that an application can take to | * Initiate: The primary action that an application can take to | |||
create a Connection to a Remote Endpoint, and prepare any required | create a Connection to a Remote Endpoint, and prepare any required | |||
local or remote state to enable the transmission of Messages. For | local or remote state to enable the transmission of Messages. For | |||
some protocols, this will initiate a client-to-server style | some protocols, this will initiate a client-to-server style | |||
handshake; for other protocols, this will just establish local | handshake; for other protocols, this will just establish local | |||
state (e.g., with connectionless protocols such as UDP). The | state (e.g., with connectionless protocols such as UDP). The | |||
process of identifying options for connecting, such as resolution | process of identifying options for connecting, such as resolution | |||
of the Remote Endpoint, occurs in response to the Initiate call. | of the Remote Endpoint, occurs in response to the Initiate call. | |||
* Listen: Enables a listener to accept incoming Connections. The | * Listen: Enables a listener to accept incoming Connections. The | |||
Listener will then create Connection objects as incoming | Listener will then create Connection objects as incoming | |||
connections are accepted (Section 4.1.5). Listeners by default | connections are accepted (Section 4.1.6). Listeners by default | |||
register with multiple paths, protocols, and local endpoints, | register with multiple paths, protocols, and local endpoints, | |||
unless constrained by Selection Properties and/or the specified | unless constrained by Selection Properties and/or the specified | |||
Local Endpoint(s). Connections can be accepted on any of the | Local Endpoint(s). Connections can be accepted on any of the | |||
available paths or endpoints. | available paths or endpoints. | |||
* Rendezvous: The action of establishing a peer-to-peer connection | * Rendezvous: The action of establishing a peer-to-peer connection | |||
with a Remote Endpoint. It simultaneously attempts to initiate a | with a Remote Endpoint. It simultaneously attempts to initiate a | |||
connection to a Remote Endpoint while listening for an incoming | connection to a Remote Endpoint while listening for an incoming | |||
connection from that endpoint. The process of identifying options | connection from that endpoint. The process of identifying options | |||
for the connection, such as resolution of the Remote Endpoint, | for the connection, such as resolution of the Remote Endpoint, | |||
skipping to change at page 18, line 40 ¶ | skipping to change at page 18, line 32 ¶ | |||
connection. The processes by which connections are initiated | connection. The processes by which connections are initiated | |||
during a Rendezvous action will depend on the set of Local and | during a Rendezvous action will depend on the set of Local and | |||
Remote Endpoints configured on the Preconnection. For example, if | Remote Endpoints configured on the Preconnection. For example, if | |||
the Local and Remote Endpoints are TCP host candidates, then a TCP | the Local and Remote Endpoints are TCP host candidates, then a TCP | |||
simultaneous open [RFC0793] will be performed. However, if the | simultaneous open [RFC0793] will be performed. However, if the | |||
set of Local Endpoints includes server reflexive candidates, such | set of Local Endpoints includes server reflexive candidates, such | |||
as those provided by STUN, a Rendezvous action will race | as those provided by STUN, a Rendezvous action will race | |||
candidates in the style of the ICE algorithm [RFC8445] to perform | candidates in the style of the ICE algorithm [RFC8445] to perform | |||
NAT binding discovery and initiate a peer-to-peer connection. | NAT binding discovery and initiate a peer-to-peer connection. | |||
4.1.4. Data Transfer Objects and Actions | 4.1.5. Data Transfer Objects and Actions | |||
* Message: A Message object is a unit of data that can be | * Message: A Message object is a unit of data that can be | |||
represented as bytes that can be transferred between two systems | represented as bytes that can be transferred between two systems | |||
over a transport connection. The bytes within a Message are | over a transport connection. The bytes within a Message are | |||
assumed to be ordered. If an application does not care about the | assumed to be ordered. If an application does not care about the | |||
order in which a peer receives two distinct spans of bytes, those | order in which a peer receives two distinct spans of bytes, those | |||
spans of bytes are considered independent Messages. | spans of bytes are considered independent Messages. | |||
* Message Properties: Message Properties are used to specify details | * Message Properties: Message Properties are used to specify details | |||
about Message transmission. They can be specified directly on | about Message transmission. They can be specified directly on | |||
skipping to change at page 19, line 19 ¶ | skipping to change at page 19, line 23 ¶ | |||
information about the received Message, such as metadata generated | information about the received Message, such as metadata generated | |||
at the receiver and information signalled by the remote endpoint. | at the receiver and information signalled by the remote endpoint. | |||
For example, a Message can be marked with a Message Property | For example, a Message can be marked with a Message Property | |||
indicating that it is the final message on a connection if the | indicating that it is the final message on a connection if the | |||
peer sent a TCP FIN. | peer sent a TCP FIN. | |||
* Send: The action to transmit a Message over a Connection to the | * Send: The action to transmit a Message over a Connection to the | |||
remote system. The interface to Send can accept Message | remote system. The interface to Send can accept Message | |||
Properties specific to how the Message content is to be sent. The | Properties specific to how the Message content is to be sent. The | |||
status of the Send operation is delivered back to the sending | status of the Send operation is delivered back to the sending | |||
application in an event (Section 4.1.5). | application in an event (Section 4.1.6). | |||
* Receive: An action that indicates that the application is ready to | * Receive: An action that indicates that the application is ready to | |||
asynchronously accept a Message over a Connection from a remote | asynchronously accept a Message over a Connection from a remote | |||
system, while the Message content itself will be delivered in an | system, while the Message content itself will be delivered in an | |||
event (Section 4.1.5). The interface to Receive can include | event (Section 4.1.6). The interface to Receive can include | |||
Message Properties specific to the Message that is to be delivered | Message Properties specific to the Message that is to be delivered | |||
to the application. | to the application. | |||
* Framer: A Framer is a data translation layer that can be added to | * Framer: A Framer is a data translation layer that can be added to | |||
a Connection to define how application-layer Messages are | a Connection to define how application-layer Messages are | |||
transmitted over a transport protocol. This is particularly | transmitted over a transport protocol. This is particularly | |||
relevant for protocols that otherwise present unstructured | relevant for protocols that otherwise present unstructured | |||
streams, such as TCP. | streams, such as TCP. | |||
4.1.5. Event Handling | 4.1.6. Event Handling | |||
The following categories of events can be delivered to an | The following categories of events can be delivered to an | |||
application: | application: | |||
* Connection Ready: Signals to an application that a given | * Connection Ready: Signals to an application that a given | |||
Connection is ready to send and/or receive Messages. If the | Connection is ready to send and/or receive Messages. If the | |||
Connection relies on handshakes to establish state between peers, | Connection relies on handshakes to establish state between peers, | |||
then it is assumed that these steps have been taken. | then it is assumed that these steps have been taken. | |||
* Connection Closed: Signals to an application that a given | * Connection Closed: Signals to an application that a given | |||
skipping to change at page 20, line 19 ¶ | skipping to change at page 20, line 22 ¶ | |||
* Message Sent: Notifies the application of the status of its Send | * Message Sent: Notifies the application of the status of its Send | |||
action. This might indicate a failure if the Message cannot be | action. This might indicate a failure if the Message cannot be | |||
sent, or an indication that the Message has been processed by the | sent, or an indication that the Message has been processed by the | |||
protocol stack. | protocol stack. | |||
* Path Properties Changed: Notifies the application that some | * Path Properties Changed: Notifies the application that some | |||
property of the Connection has changed that might influence how | property of the Connection has changed that might influence how | |||
and where data is sent and/or received. | and where data is sent and/or received. | |||
4.1.6. Termination Actions | 4.1.7. Termination Actions | |||
* Close: The action an application takes on a Connection to indicate | * Close: The action an application takes on a Connection to indicate | |||
that it no longer intends to send data, is no longer willing to | that it no longer intends to send data, is no longer willing to | |||
receive data, and that the protocol should signal this state to | receive data, and that the protocol should signal this state to | |||
the remote system if the transport protocol allows this. (Note | the remote system if the transport protocol allows this. (Note | |||
that this is distinct from the concept of "half-closing" a | that this is distinct from the concept of "half-closing" a | |||
bidirectional connection, such as when a FIN is sent in one | bidirectional connection, such as when a FIN is sent in one | |||
direction of a TCP connection. Indicating the end of a stream in | direction of a TCP connection. Indicating the end of a stream in | |||
the Transport Services architecture is possible using Message | the Transport Services architecture is possible using Message | |||
Properties when sending.) | Properties when sending.) | |||
* Abort: The action the application takes on a Connection to | * Abort: The action the application takes on a Connection to | |||
indicate a Close and also indicate that the Transport Services | indicate a Close and also indicate that the Transport Services | |||
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.8. 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.3. | 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 | |||
skipping to change at page 23, line 45 ¶ | skipping to change at page 24, line 14 ¶ | |||
6. Security Considerations | 6. Security Considerations | |||
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]. | [RFC8922]. | |||
As described above in Section 3.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 need to use the | races between two different Protocol Stacks, both need to use the | |||
same security protocols and options. However, a Transport Services | same security protocols and options. However, a Transport Services | |||
system can race different security protocols, e.g., if the | system can race different security protocols, e.g., if the | |||
application 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 | |||
skipping to change at page 25, line 5 ¶ | skipping to change at page 25, line 24 ¶ | |||
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-06, 9 March 2020, | draft-ietf-taps-interface-09, 27 July 2020, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-taps- | <http://www.ietf.org/internet-drafts/draft-ietf-taps- | |||
interface-06.txt>. | interface-09.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-06, 9 March | Progress, Internet-Draft, draft-ietf-taps-impl-07, 13 July | |||
2020, <http://www.ietf.org/internet-drafts/draft-ietf- | 2020, <http://www.ietf.org/internet-drafts/draft-ietf- | |||
taps-impl-06.txt>. | taps-impl-07.txt>. | |||
[I-D.ietf-taps-minset] | ||||
Welzl, M. and S. Gjessing, "A Minimal Set of Transport | ||||
Services for End Systems", Work in Progress, Internet- | ||||
Draft, draft-ietf-taps-minset-11, 27 September 2018, | ||||
<http://www.ietf.org/internet-drafts/draft-ietf-taps- | ||||
minset-11.txt>. | ||||
[I-D.ietf-taps-transport-security] | ||||
Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. | ||||
Wood, "A Survey of the Interaction Between Security | ||||
Protocols and Transport Services", Work in Progress, | ||||
Internet-Draft, draft-ietf-taps-transport-security-12, 23 | ||||
April 2020, <http://www.ietf.org/internet-drafts/draft- | ||||
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 26, line 44 ¶ | skipping to change at page 26, line 48 ¶ | |||
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive | [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive | |||
Connectivity Establishment (ICE): A Protocol for Network | Connectivity Establishment (ICE): A Protocol for Network | |||
Address Translator (NAT) Traversal", RFC 8445, | Address Translator (NAT) Traversal", RFC 8445, | |||
DOI 10.17487/RFC8445, July 2018, | DOI 10.17487/RFC8445, July 2018, | |||
<https://www.rfc-editor.org/info/rfc8445>. | <https://www.rfc-editor.org/info/rfc8445>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. | ||||
Wood, "A Survey of the Interaction between Security | ||||
Protocols and Transport Services", RFC 8922, | ||||
DOI 10.17487/RFC8922, October 2020, | ||||
<https://www.rfc-editor.org/info/rfc8922>. | ||||
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport | ||||
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, | ||||
October 2020, <https://www.rfc-editor.org/info/rfc8923>. | ||||
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 Switzerland GmbH | 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 | |||
End of changes. 54 change blocks. | ||||
157 lines changed or deleted | 154 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/ |