draft-ietf-taps-arch-12.txt   draft-ietf-taps-arch-13.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: 7 July 2022 Google Switzerland GmbH Expires: 29 December 2022 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
3 January 2022 27 June 2022
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-12 draft-ietf-taps-arch-13
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, a protocol features to applications for network communication, a
Transport Services system. The Transport Services Application Transport Services system. 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. This API uses messages for representing data interaction pattern. This API uses messages for representing data
transfer to applications, and describes how implementations can use transfer to applications, and 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 1, line 46 skipping to change at page 1, line 46
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 7 July 2022. This Internet-Draft will expire on 29 December 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . 8 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 8
2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 8 2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 9
3. API and Implementation Requirements . . . . . . . . . . . . . 9 3. API and Implementation Requirements . . . . . . . . . . . . . 10
3.1. Provide Common APIs for Common Features . . . . . . . . . 10 3.1. Provide Common APIs for Common Features . . . . . . . . . 10
3.2. Allow Access to Specialized Features . . . . . . . . . . 11 3.2. Allow Access to Specialized Features . . . . . . . . . . 11
3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 12 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 12
3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 13 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 13
4. Transport Services Architecture and Concepts . . . . . . . . 13 4. Transport Services Architecture and Concepts . . . . . . . . 13
4.1. Transport Services API Concepts . . . . . . . . . . . . . 14 4.1. Transport Services API Concepts . . . . . . . . . . . . . 15
4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16
4.1.2. Connections and Related Objects . . . . . . . . . . . 16 4.1.2. Connections and Related Objects . . . . . . . . . . . 16
4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 18 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 18
4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18
4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19
4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20
4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21
4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21
4.2. Transport Services Implementation . . . . . . . . . . . . 22 4.2. Transport Services Implementation . . . . . . . . . . . . 22
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23
skipping to change at page 7, line 34 skipping to change at page 7, line 34
protocols, multiple paths, and provide multiple application streams. protocols, multiple paths, and provide multiple application streams.
2.1. Event-Driven API 2.1. Event-Driven API
Originally, the Socket API presented a blocking interface for Originally, the Socket API presented a blocking interface for
establishing connections and transferring data. However, most modern establishing connections and transferring data. However, most modern
applications interact with the network asynchronously. Emulation of applications interact with the network asynchronously. Emulation of
an asynchronous interface using the Socket API generally uses a try- an asynchronous interface using the Socket API generally uses a try-
and-fail model. If the application wants to read, but data has not and-fail model. If the application wants to read, but data has not
yet been received from the peer, the call to read will fail. The yet been received from the peer, the call to read will fail. The
application then waits and can try again later. In contrast to the application then waits and can try again later.
Socket API, all interaction using the Transport Services API is
expected to be asynchronous and use an event-driven model (see In contrast to the Socket API, all interaction using the Transport
Section 4.1.6). For example, an application first issues a call to Services API is expected to be asynchronous. The API is defined
receive new data from the connection. When delivered data becomes around an event-driven model (see Section 4.1.6) in order to model
available, this data is delivered to the application using this asynchronous interaction, though other forms of asynchronous
asynchronous events that contain the data. Error handling is also communication may be available to applications depending on the
asynchronous; a failure to send data results in an asynchronous error platform implementing the interface.
event.
For example, an application first issues a call to receive new data
from the connection. When delivered data becomes available, this
data is delivered to the application using asynchronous events that
contain the data. Error handling is also asynchronous; a failure to
send data results in an asynchronous error event.
This API also delivers events regarding the lifetime of a connection This API also delivers events regarding the lifetime of a connection
and changes in the available network links, which were not previously and changes in the available network links, which were not previously
made explicit in the Socket API. made explicit in the Socket API.
Using asynchronous events allows for a more natural interaction model Using asynchronous events allows for a more natural interaction model
when establishing connections and transferring data. Events in time when establishing connections and transferring data. Events in time
more closely reflect the nature of interactions over networks, as more closely reflect the nature of interactions over networks, as
opposed to how the Socket API represent network resources as file opposed to how the Socket API represent network resources as file
system objects that may be temporarily unavailable. system objects that may be temporarily unavailable.
skipping to change at page 8, line 27 skipping to change at page 8, line 33
version, content type, and length [RFC8446]; and HTTP/2 uses frames version, content type, and length [RFC8446]; and HTTP/2 uses frames
to segment its headers and bodies [RFC7540]. to segment its headers and bodies [RFC7540].
The Transport Services API represents data as messages, so that it The Transport Services API represents data as messages, so that it
more closely matches the way applications use the network. Providing more closely matches the way applications use the network. Providing
a message-based abstraction provides many benefits, such as: a message-based abstraction provides many benefits, such as:
* the ability to associate deadlines with messages, for applications * the ability to associate deadlines with messages, for applications
that care about timing; that care about timing;
* the ability control reliability, which messages to retransmit when * the ability to control reliability, which messages to retransmit
there is packet loss, and how best to make use of the data that when there is packet loss, and how best to make use of the data
arrived; that arrived;
* 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 existing protocols and APIs because it does not compatible with existing protocols and APIs because it does not
change the wire format of any protocol. Instead, it gives the change the wire format of any protocol. Instead, it gives the
protocol stack additional information to allow it to make better use protocol stack additional information to allow it to make better use
of modern transport services, while simplifying the application's of modern transport services, while simplifying the application's
skipping to change at page 12, line 47 skipping to change at page 13, line 13
conflict with any other application-requested properties. conflict with any other application-requested properties.
To ensure that security protocols are not incorrectly swapped, a To ensure that security protocols are not incorrectly swapped, a
Transport Services implementation MUST only select Protocol Stacks Transport Services implementation MUST only select Protocol Stacks
that meet application requirements ([RFC8922]). A Transport Services that meet application requirements ([RFC8922]). A Transport Services
implementation SHOULD only race Protocol Stacks where the transport implementation SHOULD only race Protocol Stacks where the transport
security protocols within the stacks are identical. A Transport security protocols within the stacks are identical. A Transport
Services implementation MUST NOT automatically fall back from secure Services implementation MUST NOT automatically fall back from secure
protocols to insecure protocols, or to weaker versions of secure protocols to insecure protocols, or to weaker versions of secure
protocols. A Transport Services implementation MAY allow protocols. A Transport Services implementation MAY allow
applications to explicitly specify that fallback to a specific other applications to explicitly specify which versions of a protocol ought
version of a protocol \, e.g., to allow fallback to TLS 1.2 if TLS to be permitted, e.g., to allow a minimum version of TLS 1.2 in case
1.3 is not available. TLS 1.3 is not 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 guidelines for the Transport [I-D.ietf-taps-interface] nor the guidelines for the Transport
Service implementation [I-D.ietf-taps-impl] define new protocols or Service implementation [I-D.ietf-taps-impl] define new protocols or
protocol capabilities that affect what is communicated across the protocol capabilities that affect what is communicated across the
network. A Transport Services system MUST NOT require that a peer on network. A Transport Services system MUST NOT require that a peer on
the other side of a connection uses the same API or implementation. the other side of a connection uses the same API or implementation.
A Transport Services implementation acting as a connection initiator A Transport Services implementation acting as a connection initiator
skipping to change at page 13, line 47 skipping to change at page 14, line 12
in some implementations, it is expected that there will remain a 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 system The architecture divides the concepts for Transport Services system
into two categories: into two categories:
1. API concepts, which are intended to be exposed to applications; 1. API concepts, which are intended to be exposed to applications;
and and
2. System-implementation concepts, which are intended to be 2. System-implementation concepts, which are intended to be
internally used by aTransport Services implementation. internally used by a Transport Services implementation.
The following diagram summarizes the top-level concepts in the The following diagram summarizes the top-level concepts in the
architecture and how they relate to one another. architecture and how they relate to one another.
+-----------------------------------------------------+ +-----------------------------------------------------+
| Application | | Application |
+-+----------------+------^-------+--------^----------+ +-+----------------+------^-------+--------^----------+
| | | | | | | | | |
pre- | data | events pre- | data | events
establishment | transfer | | establishment | transfer | |
skipping to change at page 25, line 34 skipping to change at page 25, line 34
attempts, or other information about past communications that was attempts, or other information about past communications that was
cached by the Transport Services system is used during establishment. cached by the Transport Services system is used during establishment.
This allows applications to make tradeoffs between efficiency This allows applications to make tradeoffs between efficiency
(through racing) and privacy (via information that might leak from (through racing) and privacy (via information that might leak from
the cache toward an on-path observer). Some applications have native the cache toward an on-path observer). Some applications have native
concepts (e.g. "incognito mode") that align with this functionality. concepts (e.g. "incognito mode") that align with this functionality.
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 and
example, applications ought not to use PSK material created for the scoped to the intended protocols and roles. For example, if an
Encapsulating Security Protocol (ESP, part of IPsec) [RFC4303] with application provides a certificate to only be used as client
QUIC, and applications ought not to use private keys intended for authentication for outbound TLS and QUIC connections, the Transport
server authentication as keys for client authentication. Services system MUST NOT use this automatically in other contexts
(such as server authentication for inbound connections, or in other
another security protocol handshake that is not equivalent to TLS).
A Transport Services system must not automatically fall back from A Transport Services system must not automatically fall back from
secure protocols to insecure protocols, or to weaker versions of secure protocols to insecure protocols, or to weaker versions of
secure protocols (see Section 3.3). For example, if an application secure protocols (see Section 3.3). For example, if an application
requests a specific version of TLS, but the desired version of TLS is requests a specific version of TLS, but the desired version of TLS is
not available, its connection will fail. Applications are thus not available, its connection will fail. The Transport Services API
responsible for implementing security protocol fallback or version MAY allow applications to specify minimum versions that are allowed
fallback by creating multiple Connections, if so desired. to be used by the Transport Services system.
Alternatively, the Transport Services API MAY allow applications to
specify that fallback to a specific other version of a protocol is
allowed by the Transport Services system.
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), No. 688421 (MAMI) and No 815178 (5GENESIS). (NEAT), No. 688421 (MAMI) and No 815178 (5GENESIS).
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 26, line 34 skipping to change at page 26, line 34
Josh Graessley, David Schinazi, and Eric Kinnear for their Josh Graessley, David Schinazi, and Eric Kinnear for their
implementation and design efforts, including Happy Eyeballs, that implementation and design efforts, including Happy Eyeballs, that
heavily influenced this work. heavily influenced this work.
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. S., Wood, C. A., Kuehlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
Pauly, T., and K. Rose, "An Abstract Application Layer "An Abstract Application Layer Interface to Transport
Interface to Transport Services", Work in Progress, Services", Work in Progress, Internet-Draft, draft-ietf-
Internet-Draft, draft-ietf-taps-interface-14, 3 January taps-interface-15, 7 March 2022,
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
taps-interface-14>. interface-15>.
[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/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/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/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/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., Tiesel, P. S., and
Jones, T., Tiesel, P. S., Perkins, C., and M. Welzl, M. Welzl, "Implementing Interfaces to Transport Services",
"Implementing Interfaces to Transport Services", Work in Work in Progress, Internet-Draft, draft-ietf-taps-impl-12,
Progress, Internet-Draft, draft-ietf-taps-impl-10, 12 July 7 March 2022, <https://datatracker.ietf.org/doc/html/
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- draft-ietf-taps-impl-12>.
taps-impl-10>.
[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/rfc/rfc793>. <https://www.rfc-editor.org/rfc/rfc793>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/rfc/rfc4303>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/rfc/rfc7230>. <https://www.rfc-editor.org/rfc/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
 End of changes. 15 change blocks. 
50 lines changed or deleted 49 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/