idnits 2.17.1 draft-ietf-taps-arch-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-04 == Outdated reference: A later version (-18) exists of draft-ietf-taps-impl-04 == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-09 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group T. Pauly, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track B. Trammell, Ed. 5 Expires: May 7, 2020 Google 6 A. Brunstrom 7 Karlstad University 8 G. Fairhurst 9 University of Aberdeen 10 C. Perkins 11 University of Glasgow 12 P. Tiesel 13 TU Berlin 14 C. Wood 15 Apple Inc. 16 November 04, 2019 18 An Architecture for Transport Services 19 draft-ietf-taps-arch-05 21 Abstract 23 This document provides an overview of the architecture of Transport 24 Services, a model for exposing transport protocol features to 25 applications for network communication. In contrast to what is 26 provided by most existing Application Programming Interfaces (APIs), 27 Transport Services is based on an asynchronous, event-driven 28 interaction pattern; it uses messages for representing data transfer 29 to applications; and it assumes an implementation that can use 30 multiple IP addresses, multiple protocols, and multiple paths, and 31 provide multiple application streams. This document further defines 32 the common set of terminology and concepts to be used in definitions 33 of Transport Services APIs and implementations. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 7, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.3. Specification of Requirements . . . . . . . . . . . . . . 5 72 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 6 74 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 75 2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 76 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8 77 3.1. Common APIs for Common Features . . . . . . . . . . . . . 9 78 3.2. Access to Specialized Features . . . . . . . . . . . . . 9 79 3.3. Scope for API and Implementation Definitions . . . . . . 10 80 4. Transport Services Architecture and Concepts . . . . . . . . 11 81 4.1. Transport Services API Concepts . . . . . . . . . . . . . 12 82 4.1.1. Connection Objects . . . . . . . . . . . . . . . . . 14 83 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 15 84 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 16 85 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 17 86 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 18 87 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 18 88 4.2. Transport System Implementation Concepts . . . . . . . . 18 89 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20 90 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 20 91 4.2.3. Protocol Stack Equivalence . . . . . . . . . . . . . 20 92 4.2.4. Separating Connection Groups . . . . . . . . . . . . 22 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 98 8.2. Informative References . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 101 1. Introduction 103 Many application programming interfaces (APIs) to perform transport 104 networking have been deployed, perhaps the most widely known and 105 imitated being the BSD socket() [POSIX] interface. The naming of 106 objects and functions across these APIs is not consistent, and varies 107 depending on the protocol being used. For example, sending and 108 receiving streams of data is conceptually the same for both an 109 unencrypted Transmission Control Protocol (TCP) stream and operating 110 on an encrypted Transport Layer Security (TLS) [RFC8446] stream over 111 TCP, but applications cannot use the same socket send() and recv() 112 calls on top of both kinds of connections. Similarly, terminology 113 for the implementation of transport protocols varies based on the 114 context of the protocols themselves: terms such as "flow", "stream", 115 "message", and "connection" can take on many different meanings. 116 This variety can lead to confusion when trying to understand the 117 similarities and differences between protocols, and how applications 118 can use them effectively. 120 The goal of the Transport Services architecture is to provide a 121 common, flexible, and reusable interface for transport protocols. As 122 applications adopt this interface, they will benefit from a wide set 123 of transport features that can evolve over time, and ensure that the 124 system providing the interface can optimize its behavior based on the 125 application requirements and network conditions, without requiring 126 changes to the applications. This flexibility enables faster 127 deployment of new features and protocols. It can also support 128 applications by offering racing and fallback mechanisms, which 129 otherwise need to be implemented in each application separately. 131 This document is developed in parallel with the specification of the 132 Transport Services API [I-D.ietf-taps-interface] and Implementation 133 Guidelines [I-D.ietf-taps-impl]. Although following the Transport 134 Services Architecture does not require that all APIs and 135 implementations are identical, a common minimal set of features 136 represented in a consistent fashion will enable applications to be 137 easily ported from one system to another. 139 1.1. Background 141 The Transport Services architecture is based on the survey of 142 Services Provided by IETF Transport Protocols and Congestion Control 143 Mechanisms [RFC8095], and the distilled minimal set of the features 144 offered by transport protocols [I-D.ietf-taps-minset]. These 145 documents identified common features and patterns across all 146 transport protocols developed thus far in the IETF. 148 Since transport security is an increasingly relevant aspect of using 149 transport protocols on the Internet, this architecture also considers 150 the impact of transport security protocols on the feature-set exposed 151 by transport services [I-D.ietf-taps-transport-security]. 153 One of the key insights to come from identifying the minimal set of 154 features provided by transport protocols [I-D.ietf-taps-minset] was 155 that features either require application interaction and guidance 156 (referred to as Functional or Optimizing Features), or else can be 157 handled automatically by a system implementing Transport Services 158 (referred to as Automatable Features). Among the Functional and 159 Optimizing Features, some were common across all or nearly all 160 transport protocols, while others could be seen as features that, if 161 specified, would only be useful with a subset of protocols, but would 162 not harm the functionality of other protocols. For example, some 163 protocols can deliver messages faster for applications that do not 164 require messages to arrive in the order in which they were sent. 165 However, this functionality needs to be explicitly allowed by the 166 application, since reordering messages would be undesirable in many 167 cases. 169 1.2. Overview 171 This document describes the Transport Services architecture in three 172 sections: 174 o Section 2 describes how the API model of Transport Services 175 differs from traditional socket-based APIs. Specifically, it 176 offers asynchronous event-driven interaction, the use of messages 177 for data transfer, and the ability to easily adopt different 178 transport protocols. 180 o Section 3 explains the design principles that guide the Transport 181 Services API. These principles are intended to make sure that 182 transport protocols can continue to be enhanced and evolve without 183 requiring too many changes by application developers. 185 o Section 4 presents the Transport Services architecture diagram and 186 defines the concepts that are used by both the API and 187 implementation documents. The Preconnection allows applications 188 to configure connection properties, and the Connection represents 189 an object that can be used to send and receive Messages. 191 1.3. Specification of Requirements 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 2. API Model 201 The traditional model of using sockets for networking can be 202 represented as follows: 204 o Applications create connections and transfer data using the socket 205 API. 207 o The socket API provides the interface to the implementations of 208 TCP and UDP (typically implemented in the system's kernel). 210 o TCP and UDP in the kernel send and receive data over the available 211 network layer interfaces. 213 +-----------------------------------------------------+ 214 | Application | 215 +-----------------------------------------------------+ 216 | | 217 +---------------------+ +-----------------------+ 218 | Socket Stream API | | Socket Datagram API | 219 +---------------------+ +-----------------------+ 220 | | 221 +-----------------------------------------------------+ 222 | TCP UDP | 223 | Kernel Protocol Implementation | 224 +-----------------------------------------------------+ 225 | 226 +-----------------------------------------------------+ 227 | Network Layer Interface | 228 +-----------------------------------------------------+ 230 Figure 1: socket() API Model 232 The Transport Services architecture maintains this general model of 233 interaction, but aims to both modernize the API surface exposed for 234 transport protocols and enrich the capabilities of the transport 235 system implementation. 237 +-----------------------------------------------------+ 238 | Application | 239 +-----------------------------------------------------+ 240 | 241 +-----------------------------------------------------+ 242 | Transport Services API | 243 +-----------------------------------------------------+ 244 | 245 +-----------------------------------------------------+ 246 | Transport System Implementation | 247 | (UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) | 248 +-----------------------------------------------------+ 249 | 250 +-----------------------------------------------------+ 251 | Network Layer Interface | 252 +-----------------------------------------------------+ 254 Figure 2: Transport Services API Model 256 The Transport Services API [I-D.ietf-taps-interface] defines the 257 mechanism for an application to create network connections and 258 transfer data. The implementation [I-D.ietf-taps-impl] is 259 responsible for mapping the API to the various available transport 260 protocols and managing the available network interfaces and paths. 262 There are key differences between the architecture of the Transport 263 Services system and the architecture of the sockets API: it presents 264 an asynchronous, event-driven API; it uses messages for representing 265 data transfer to applications; and it assumes an implementation that 266 can use multiple IP addresses, multiple protocols, multiple paths, 267 and provide multiple application streams. 269 2.1. Event-Driven API 271 Originally, sockets presented a blocking interface for establishing 272 connections and transferring data. However, most modern applications 273 interact with the network asynchronously. When sockets are presented 274 as an asynchronous interface, they generally use a try-and-fail 275 model. If the application wants to read, but data has not yet been 276 received from the peer, the call to read will fail. The application 277 then waits and can try again later. 279 All interaction with a Transport Services system is expected to be 280 asynchronous, and use an event-driven model unlike sockets 281 Section 4.1.5. For example, if the application wants to read, its 282 call to read will not fail, but will deliver an event containing the 283 received data once it is available. 285 The Transport Services API also delivers events regarding the 286 lifetime of a connection and changes in the available network links, 287 which were not previously made explicit in sockets. 289 Using asynchronous events allows for a much simpler interaction model 290 when establishing connections and transferring data. Events in time 291 more closely reflect the nature of interactions over networks, as 292 opposed to how sockets represent network resources as file system 293 objects that may be temporarily unavailable. 295 2.2. Data Transfer Using Messages 297 Sockets provide a message interface for datagram protocols like UDP, 298 but provide an unstructured stream abstraction for TCP. While TCP 299 does indeed provide the ability to send and receive data as streams, 300 most applications need to interpret structure within these streams. 301 For example, HTTP/1.1 uses character delimiters to segment messages 302 over a stream [RFC7230]; TLS record headers carry a version, content 303 type, and length [RFC8446]; and HTTP/2 uses frames to segment its 304 headers and bodies [RFC7540]. 306 The Transport Services API represents data as messages, so that it 307 more closely matches the way applications use the network. Messages 308 seamlessly work with transport protocols that support datagrams or 309 records, but can also be used over a stream by defining an 310 application-layer framer Section 4.1.4. When framing protocols are 311 placed on top of unstructured streams, the messages used in the API 312 represent the framed messages within the stream. In the absence of a 313 framer, protocols that deal only in byte streams, such as TCP, 314 represent their data in each direction as a single, long message. 316 Providing a message-based abstraction provides many benefits, such 317 as: 319 o the ability to associate deadlines with messages, for applications 320 that care about timing; 322 o the ability to provide control of reliability, choosing which 323 messages to retransmit in the event of packet loss, and how best 324 to make use of the data that arrived; 326 o the ability to manage dependencies between messages, when the 327 transport system could decide to not deliver a message, either 328 following packet loss or because it has missed a deadline. In 329 particular, this can avoid (re-)sending data that relies on a 330 previous transmission that was never received. 332 o the ability to automatically assign messages and connections to 333 underlaying transport connections to utilize multi-streaming and 334 pooled connections. 336 Allowing applications to interact with messages is backwards- 337 compatible with existings protocols and APIs, as it does not change 338 the wire format of any protocol. Instead, it gives the protocol 339 stack additional information to allow it to make better use of modern 340 transport services, while simplifying the application's role in 341 parsing data. 343 2.3. Flexibile Implementation 345 Sockets, for protocols like TCP, are generally limited to connecting 346 to a single address over a single interface. They also present a 347 single stream to the application. Software layers built upon sockets 348 often propagate this limitation of a single-address single-stream 349 model. The Transport Services architecture is designed to handle 350 multiple candidate endpoints, protocols, and paths; and support 351 multipath and multistreaming protocols. 353 Transport Services implementations are meant to be flexible at 354 connection establishment time, considering many different options and 355 trying to select the most optimal combinations (Section 4.2.1 and 356 Section 4.2.2). This requires applications to provide higher-level 357 endpoints than IP addresses, such as hostnames and URLs, which are 358 used by a Transport Services implementation for resolution, path 359 selection, and racing. 361 Flexibility after connection establishment is also important. 362 Transport protocols that can migrate between multiple network-layer 363 interfaces need to be able to process and react to interface changes. 364 Protocols that support multiple application-layer streams need to 365 support initiating and receiving new streams using existing 366 connections. 368 3. Design Principles 370 The goal of the Transport Services architecture is to redefine the 371 interface between applications and transports in a way that allows 372 the transport layer to evolve and improve without fundamentally 373 changing the contract with the application. This requires a careful 374 consideration of how to expose the capabilities of protocols. 376 There are several degrees in which a Transport Services system is 377 intended to offer flexibility to an application: it can provide 378 access to multiple sets of protocols and protocol features; it can 379 use these protocols across multiple paths that could have different 380 performance and functional characteristics; and it can communicate 381 with different remote systems to optimize performance, robustness to 382 failure, or some other metric. Beyond these, if the API for the 383 system remains the same over time, new protocols and features could 384 be added to the system's implementation without requiring changes in 385 applications for adoption. 387 3.1. Common APIs for Common Features 389 Functionality that is common across multiple transport protocols 390 SHOULD be accessible through a unified set of API calls. An 391 application ought to be able to implement logic for its basic use of 392 transport networking (establishing the transport, and sending and 393 receiving data) once, and expect that implementation to continue to 394 function as the transports change. 396 Any Transport Services API is REQUIRED to allow access to the 397 distilled minimal set of features offered by transport protocols 398 [I-D.ietf-taps-minset]. 400 3.2. Access to Specialized Features 402 There are applications that will need to control fine-grained details 403 of transport protocols to optimize their behavior and ensure 404 compatibility with remote systems. A Transport Services system 405 therefore SHOULD also permit more specialized protocol features to be 406 used. The interface for these specialized options ought to be 407 exposed differently from the common options to ensure flexibility. 409 A specialized feature could be required by an application only when 410 using a specific protocol, and not when using others. For example, 411 if an application is using UDP, it could require control over the 412 checksum or fragmentation behavior for UDP; if it used a protocol to 413 frame its data over a byte stream like TCP, it would not need these 414 options. In such cases, the API ought to expose the features in such 415 a way that they take effect when a particular protocol is selected, 416 but do not imply that only that protocol could be used. For example, 417 if the API allows an application to specify a preference for 418 constrained checksum usage, communication would not fail when a 419 protocol such as TCP is selected, which uses a checksum covering the 420 entire payload. 422 Other specialized features, however, could be strictly required by an 423 application and thus constrain the set of protocols that can be used. 424 For example, if an application requires encryption of its transport 425 data, only protocol stacks that include a transport security function 426 are eligible to be used. A Transport Services API MUST allow 427 applications to define such requirements and constrain the system's 428 options. Since such options are not part of the core/common 429 features, it will generally be simple for an application to modify 430 its set of constraints and change the set of allowable protocol 431 features without changing the core implementation. 433 3.3. Scope for API and Implementation Definitions 435 The Transport Services API is envisioned as the abstract model for a 436 family of APIs that share a common way to expose transport features 437 and encourage flexibility. The abstract API definition 438 [I-D.ietf-taps-interface] describes this interface and how it can be 439 exposed to application developers. 441 Implementations that provide the Transport Services API 442 [I-D.ietf-taps-impl] will vary due to system-specific support and the 443 needs of the deployment scenario. It is expected that all 444 implementations of Transport Services will offer the entire mandatory 445 API. All implementations are REQUIRED to offer an API that is 446 sufficient to use the distilled minimal set of features offered by 447 transport protocols [I-D.ietf-taps-minset], including API support for 448 TCP and UDP transport. However, some features provided by this API 449 will not be functional in certain implementations. For example, it 450 is possible that some very constrained devices might not have a full 451 TCP implementation beneath the API. 453 To preserve flexibility and compatibility with future protocols, top- 454 level features in the Transport Services API SHOULD avoid referencing 455 particular transport protocols. The mappings of these API features 456 to specific implementations of each feature is explained in the 457 [I-D.ietf-taps-impl] along with the implications of the feature on 458 existing protocols. It is expected that [I-D.ietf-taps-interface] 459 will be updated and supplemented as new protocols and protocol 460 features are developed. 462 It is important to note that neither the Transport Services API 463 [I-D.ietf-taps-interface] nor the Implementation document 464 [I-D.ietf-taps-impl] define new protocols or protocol capabilities 465 that affect what is communicated across the network. The Transport 466 Services system MUST be deployable on one side only. A Transport 467 Services system acting as a connection initiator can communicate with 468 any existing system that implements the transport protocol(s) 469 selected by the Transport Services system. Similarly, a Transport 470 Services system acting as a listener can receive connections for any 471 protocol that is supported by the system, from existing initiators. 473 4. Transport Services Architecture and Concepts 475 The concepts defined in this document are intended primarily for use 476 in the documents and specifications that describe the Transport 477 Services architecture and API. While the specific terminology can be 478 used in some implementations, it is expected that there will remain a 479 variety of terms used by running code. 481 The architecture divides the concepts for Transport Services into two 482 categories: 484 1. API concepts, which are intended to be exposed to applications; 485 and 487 2. System-implementation concepts, which are intended to be 488 internally used when building systems that implement Transport 489 Services. 491 The following diagram summarizes the top-level concepts in the 492 architecture and how they relate to one another. 494 +-----------------------------------------------------+ 495 | Application | 496 +-+----------------+------^-------+--------^----------+ 497 | | | | | 498 pre- | data | events 499 establishment | transfer | | 500 | establishment | termination | 501 | | | | | 502 | +--v------v-------v+ | 503 +-v-------------+ Connection(s) +-------+----------+ 504 | Transport +--------+---------+ | 505 | Services | | 506 | API | | 507 +------------------------|----------------------------+ 508 | 509 +------------------------|----------------------------+ 510 | Transport | | 511 | System | +-----------------+ | 512 | Implementation | | Cached | | 513 | | | State | | 514 | (Candidate Gathering) | +-----------------+ | 515 | | | 516 | (Candidate Racing) | +-----------------+ | 517 | | | System | | 518 | | | Policy | | 519 | +----------v-----+ +-----------------+ | 520 | | Protocol | | 521 +-------------+ Stack(s) +----------------------+ 522 +-------+--------+ 523 V 524 Network Layer Interface 526 Figure 3: Concepts and Relationships in the Transport Services 527 Architecture 529 4.1. Transport Services API Concepts 531 Fundamentally, a Transport Services API needs to provide connection 532 objects (Section 4.1.1) that allow applications to establish 533 communication, and then send and receive data. These could be 534 exposed as handles or referenced objects, depending on the language. 536 Beyond the connection objects, there are several high-level groups of 537 actions that any Transport Services API implementing this 538 specification MUST provide: 540 o Pre-Establishment (Section 4.1.2) encompasses the properties that 541 an application can pass to describe its intent, requirements, 542 prohibitions, and preferences for its networking operations. For 543 any system that provides generic Transport Services, these 544 properties SHOULD be defined to apply to multiple transport 545 protocols. Properties specified during Pre-Establishment can have 546 a large impact on the rest of the interface: they modify how 547 establishment occurs, they influence the expectations around data 548 transfer, and they determine the set of events that will be 549 supported. 551 o Establishment (Section 4.1.3) focuses on the actions that an 552 application takes on the connection objects to prepare for data 553 transfer. 555 o Data Transfer (Section 4.1.4) consists of how an application 556 represents the data to be sent and received, the functions 557 required to send and receive that data, and how the application is 558 notified of the status of its data transfer. 560 o Event Handling (Section 4.1.5) defines the set of properties about 561 which an application can receive notifications during the lifetime 562 of transport objects. Events MAY also provide opportunities for 563 the application to interact with the underlying transport by 564 querying state or updating maintenance options. 566 o Termination (Section 4.1.6) focuses on the methods by which data 567 transmission is stopped, and state is torn down in the transport. 569 The diagram below provides a high-level view of the actions and 570 events during the lifetime of a connection. Note that some actions 571 are alternatives (e.g., whether to initiate a connection or to listen 572 for incoming connections), others are optional (e.g., setting 573 Connection and Message Properties in Pre-Establishment), or have been 574 omitted for brevity. 576 Pre-Establishment : Established : Termination 577 ----------------- : ----------- : ----------- 578 : Close() : 579 +---------------+ Initiate() +------------+ Abort() : 580 +-->| Preconnection |------------->| Connection |-----------> Closed 581 | +---------------+ Rendezvous() +------------+ Conn. : 582 | : ^ | Finished : 583 +-- Local Endpoint : | | : 584 | : | | : 585 +-- Remote Endpoint : | v : 586 | : | Connection : 587 +-- Selection Properties : | Ready : 588 +-- Connection Properties : | : 589 +-- Message Properties : | : 590 | : | : 591 | +----------+ : | : 592 +-->| Listener |----------------------+ : 593 +----------+ Connection Received : 594 ^ : : 595 | : : 596 Listen() : : 598 Figure 4: The lifetime of a connection 600 4.1.1. Connection Objects 602 o Preconnection: A Preconnection object is a representation of a 603 potential connection. It has state that describes parameters of a 604 Connection that might exist in the future: the Local Endpoint from 605 which that Connection will be established, the Remote Endpoint 606 (Section 4.1.2) to which it will connect, and Selection Properties 607 (Section 4.1.2) that influence the paths and protocols a 608 Connection will use. A Preconnection can be fully specified such 609 that it represents a single possible Connection, or it can be 610 partially specified such that it represents a family of possible 611 Connections. The Local Endpoint (Section 4.1.2) MUST be specified 612 if the Preconnection is used to Listen for incoming connections. 613 The Local Endpoint is OPTIONAL if it is used to Initiate 614 connections. The Remote Endpoint MUST be specified in the 615 Preconnection that is used to Initiate connections. The Remote 616 Endpoint is OPTIONAL if it is used to Listen for incoming 617 connections. The Local Endpoint and the Remote Endpoint MUST both 618 be specified if a peer-to-peer Rendezvous is to occur based on the 619 Preconnection. 621 o Transport Properties: Transport Properties can be specified as 622 part of a Preconnection to allow the application to configure the 623 Transport System and express their requirements, prohibitions, and 624 preferences. There are three kinds of Transport Properties: 626 * Selection Properties (Section 4.1.2) 628 * Connection Properties (Section 4.1.2) 630 * and Message Properties (Section 4.1.4); note that Message 631 Properties can also be specified during data transfer to affect 632 specific Messages. 634 o Connection: A Connection object represents one or more active 635 transport protocol instances that can send and/or receive Messages 636 between local and remote systems. It holds state pertaining to 637 the underlying transport protocol instances and any ongoing data 638 transfers. This represents, for example, an active connection in 639 a connection-oriented protocol such as TCP, or a fully-specified 640 5-tuple for a connectionless protocol such as UDP. It can also 641 represent a pool of transport protocol instance, e.g., a set of 642 TCP and QUIC connections to equivalent endpoints, or a stream of a 643 multi-streaming transport protocol instance. 645 o Listener: A Listener object accepts incoming transport protocol 646 connections from remote systems and generates corresponding 647 Connection objects. It is created from a Preconnection object 648 that specifies the type of incoming connections it will accept. 650 4.1.2. Pre-Establishment 652 o Endpoint: An Endpoint represents an identifier for one side of a 653 transport connection. Endpoints can be Local Endpoints or Remote 654 Endpoints, and respectively represent an identity that the 655 application uses for the source or destination of a connection. 656 An Endpoint can be specified at various levels, and an Endpoint 657 with wider scope (such as a hostname) can be resolved to more 658 concrete identities (such as IP addresses). 660 o Remote Endpoint: The Remote Endpoint represents the application's 661 identifier for a peer that can participate in a transport 662 connection. For example, the combination of a DNS name for the 663 peer and a service name/port. 665 o Local Endpoint: The Local Endpoint represents the application's 666 identifier for itself that it uses for transport connections. For 667 example, a local IP address and port. 669 o Selection Properties: The Selection Properties consist of the 670 options that an application can set to influence the selection of 671 paths between the local and remote systems, to influence the 672 selection of transport protocols, or to configure the behavior of 673 generic transport protocol features. These options can take the 674 form of requirements, prohibitions, or preferences. Examples of 675 options that influence path selection include the interface type 676 (such as a Wi-Fi Ethernet connection, or a Cellular LTE 677 connection), requirements around the Maximum Transmission Unit 678 (MTU) or path MTU (PMTU), or preferences for throughput and 679 latency properties. Examples of options that influence protocol 680 selection and configuration of transport protocol features include 681 reliability, service class, multipath support, and fast open 682 support. 684 o Connection Properties: The Connection Properties are used to 685 configure protocol-specific options and control per-connection 686 behavior of the Transport System. For example, a protocol- 687 specific Connection Property can express that if UDP is used, the 688 implementation ought to use checksums. Note that the presence of 689 such a property does not require that a specific protocol will be 690 used. In general, these properties do not explicitly determine 691 the selection of paths or protocols, but MAY be used in this way 692 by an implementation during connection establishment. Connection 693 Properties SHOULD be specified on a Preconnection prior to 694 Connection establishment, but MAY be modified later. Changes made 695 to Connection Properties after establishment take effect on a 696 best-effort basis. Such changes do not affect protocol or path 697 selection, but only modify the manner in which a connection sends 698 and receives data. 700 4.1.3. Establishment Actions 702 o Initiate: The primary action that an application can take to 703 create a Connection to a Remote Endpoint, and prepare any required 704 local or remote state to enable the transmission of Messages. For 705 some protocols, this will initiate a client-to-server style 706 handshake; for other protocols, this will just establish local 707 state. The process of identifying options for connecting, such as 708 resolution of the Remote Endpoint, occurs in response the Initiate 709 call. 711 o Listen: The action of marking a Listener as willing to accept 712 incoming Connections. The Listener will then create Connection 713 objects as incoming connections are accepted (Section 4.1.5). 715 o Rendezvous: The action of establishing a peer-to-peer connection 716 with a Remote Endpoint. It simultaneously attempts to initiate a 717 connection to a Remote Endpoint whilst listening for an incoming 718 connection from that endpoint. This corresponds, for example, to 719 a TCP simultaneous open [RFC0793]. The process of identifying 720 options for the connection, such as resolution of the Remote 721 Endpoint, occurs during the Rendezvous call. If successful, the 722 rendezvous call returns a Connection object to represent the 723 established peer-to-peer connection. 725 4.1.4. Data Transfer Objects and Actions 727 o Message: A Message object is a unit of data that can be 728 represented as bytes that can be transferred between two systems 729 over a transport connection. The bytes within a Message are 730 assumed to be ordered within the Message. If an application does 731 not care about the order in which a peer receives two distinct 732 spans of bytes, those spans of bytes are considered independent 733 Messages. Boundaries of a Message might or might not be 734 understood or transmitted by transport protocols. Specifically, 735 what one application considers to be two Messages sent on a 736 stream-based transport can be treated as a single Message by the 737 application on the other side. 739 o Message Properties: Message Properties can be used to annotate 740 specific Messages. These properties might only apply to how 741 Message is sent (such as how the transport will treat 742 prioritization and reliability), but can also include properties 743 that specific protocols encode and communicate to the Remote 744 Endpoint. Message Properties MAY be set on a Preconnection to 745 define defaults properties for sending. When receiving Messages, 746 Message Properties can contain per-protocol properties for 747 properties that are sent between the endpoints. 749 o Send: The action to transmit a Message or partial Message over a 750 Connection to the remote system. The interface to Send MAY 751 include Message Properties specific to how the Message content is 752 to be sent. The status of the Send operation can be delivered 753 back to the sending application in an event (Section 4.1.5). 755 o Receive: An action that indicates that the application is ready to 756 asynchronously accept a Message over a Connection from a remote 757 system, while the Message content itself will be delivered in an 758 event (Section 4.1.5). The interface to Receive MAY include 759 Message Properties specific to the Message that is to be delivered 760 to the application. 762 o Framer: A Framer is a data translation layer that can be added to 763 a Connection to define how application-level Messages are 764 transmitted over a transport protocol. This is particularly 765 relevant for protocols that otherwise present unstructured 766 streams, such as TCP. 768 4.1.5. Event Handling 770 This section provides the top-level categories of events events that 771 can be delivered to an application. This list is not exhaustive. 773 o Connection Ready: Signals to an application that a given 774 Connection is ready to send and/or receive Messages. If the 775 Connection relies on handshakes to establish state between peers, 776 then it is assumed that these steps have been taken. 778 o Connection Finished: Signals to an application that a given 779 Connection is no longer usable for sending or receiving Messages. 780 The event SHOULD deliver a reason or error to the application that 781 describes the nature of the termination. 783 o Connection Received: Signals to an application that a given 784 Listener has passively received a Connection. 786 o Message Received: Delivers received Message content to the 787 application, based on a Receive action. This MAY include an error 788 if the Receive action cannot be satisfied due to the Connection 789 being closed. 791 o Message Sent: Notifies the application of the status of its Send 792 action. This might indicate a failure if the Message cannot be 793 sent, or an indication that Message has been processed by the 794 protocol stack. 796 o Path Properties Changed: Notifies the application that some 797 property of the Connection has changed that might influence how 798 and where data is sent and/or received. 800 4.1.6. Termination Actions 802 o Close: The action an application takes on a Connection to indicate 803 that it no longer intends to send data, is no longer willing to 804 receive data, and that the protocol SHOULD signal this state to 805 the remote system if the transport protocol allows this. 807 o Abort: The action the application takes on a Connection to 808 indicate a Close and also indicate that the transport system 809 SHOULD NOT attempt to deliver any outstanding data. 811 4.2. Transport System Implementation Concepts 813 This section defines the set of objects used internally to a system 814 or library to implement the functionality needed to provide a 815 transport service across a network, as required by the abstract 816 interface. 818 o Connection Group: A set of Connections that share properties and 819 caches. For multiplexing transport protocols, only Connections 820 within the same Connection Group are allowed to be multiplexed 821 together. An application can explicitly define Connection Groups 822 to control caching boundaries, as discussed in Section 4.2.4. 824 o Path: Represents an available set of properties that a local 825 system can use to communicate with a remote system, such as 826 routes, addresses, and physical and virtual network interfaces. 828 o Protocol Instance: A single instance of one protocol, including 829 any state necessary to establish connectivity or send and receive 830 Messages. 832 o Protocol Stack: A set of Protocol Instances (including relevant 833 application, security, transport, or Internet protocols) that are 834 used together to establish connectivity or send and receive 835 Messages. A single stack can be simple (a single transport 836 protocol instance over IP), or complex (multiple application 837 protocol streams going through a single security and transport 838 protocol, over IP; or, a multi-path transport protocol over 839 multiple transport sub-flows). 841 o Candidate Path: One path that is available to an application and 842 conforms to the Selection Properties and System Policy. Candidate 843 Paths are identified during the gathering phase (Section 4.2.1) 844 and can be used during the racing phase (Section 4.2.2). 846 o Candidate Protocol Stack: One protocol stack that can be used by 847 an application for a connection, of which there can be several. 848 Candidate Protocol Stacks are identified during the gathering 849 phase (Section 4.2.1) and are started during the racing phase 850 (Section 4.2.2). 852 o System Policy: Represents the input from an operating system or 853 other global preferences that can constrain or influence how an 854 implementation will gather candidate paths and protocol stacks 855 (Section 4.2.1) and race the candidates during establishment 856 (Section 4.2.2). Specific aspects of the System Policy either 857 apply to all Connections or only certain ones, depending on the 858 runtime context and properties of the Connection. 860 o Cached State: The state and history that the implementation keeps 861 for each set of associated Endpoints that have been used 862 previously. This can include DNS results, TLS session state, 863 previous success and quality of transport protocols over certain 864 paths. 866 4.2.1. Candidate Gathering 868 o Path Selection: Path Selection represents the act of choosing one 869 or more paths that are available to use based on the Selection 870 Properties provided by the application, the policies and 871 heuristics of a Transport Services system. 873 o Protocol Selection: Protocol Selection represents the act of 874 choosing one or more sets of protocol options that are available 875 to use based on the Transport Properties provided by the 876 application, and the heuristics or policies within the Transport 877 Services system. 879 4.2.2. Candidate Racing 881 o Protocol Option Racing: Protocol Racing is the act of attempting 882 to establish, or scheduling attempts to establish, multiple 883 Protocol Stacks that differ based on the composition of protocols 884 or the options used for protocols. 886 o Path Racing: Path Racing is the act of attempting to establish, or 887 scheduling attempts to establish, multiple Protocol Stacks that 888 differ based on a selection from the available Paths. Since 889 different Paths will have distinct configurations for local 890 addresses and DNS servers, attempts across different Paths will 891 perform separate DNS resolution stepss, which can lead to further 892 racing of the resolved Remote Endpoints. 894 o Remote Endpoint Racing: Remote Endpoint Racing is the act of 895 attempting to establish, or scheduling attempts to establish, 896 multiple Protocol Stacks that differ based on the specific 897 representation of the Remote Endpoint, such as IP addresses 898 resolved from a DNS hostname. 900 4.2.3. Protocol Stack Equivalence 902 The Transport Services architecture defines a mechanism that allows 903 applications to easily use different network paths and Protocol 904 Stacks. In some cases, changing which Protocol Stacks or network 905 paths are used will require updating the preferences expressed by the 906 application that uses the Transport Services system. For example, an 907 application can enable the use of a multipath or multistreaming 908 transport protocol by modifying the properties in its Pre-Connection 909 configuration. In some cases, however, the Transport Services system 910 will be able to automatically change Protocol Stacks without an 911 update to the application, either by selecting a new stack entirely, 912 or by racing multiple candidate Protocol Stacks during connection 913 establishment. This functionality in the API can be a powerful 914 driver of new protocol adoption, but needs to be constrained 915 carefully to avoid unexpected behavior that can lead to functional or 916 security problems. 918 If two different Protocol Stacks can be safely swapped, or raced in 919 parallel (see Section 4.2.2), then they are considered to be 920 "equivalent". Equivalent Protocol Stacks need to meet the following 921 criteria: 923 1. Both stacks MUST offer the same interface to the application for 924 connection establishment and data transmission. For example, if 925 one Protocol Stack has UDP as the top-level interface to the 926 application, then it is not equivalent to a Protocol Stack that 927 runs TCP as the top-level interface. Among other differences, 928 the UDP stack would allow an application to read out message 929 boundaries based on datagrams sent from the remote system, 930 whereas TCP does not preserve message boundaries on its own. 932 2. Both stacks MUST offer the transport services that are required 933 by the application. For example, if an application specifies 934 that it requires reliable transmission of data, then a Protocol 935 Stack using UDP without any reliability layer on top would not be 936 allowed to replace a Protocol Stack using TCP. However, if the 937 application does not require reliability, then a Protocol Stack 938 that adds reliability could be regarded as an equivalent Protocol 939 Stack as long providing this would not conflict with any other 940 application-requested properties. 942 3. Both stacks MUST offer the same security properties. The 943 inclusion of transport security protocols 944 [I-D.ietf-taps-transport-security] in a Protocol Stack adds 945 additional restrictions to Protocol Stack equivalence. Security 946 features and properties, such as cryptographic algorithms, peer 947 authentication, and identity privacy vary across security 948 protocols, and across versions of security protocols. Protocol 949 equivalence ought not to be assumed for different protocols or 950 protocol versions, even if they offer similar application 951 configuration options. To ensure that security protocols are not 952 incorrectly swapped, Transport Services systems SHOULD only 953 automatically generate equivalent Protocol Stacks when the 954 transport security protocols within the stacks are identical. 955 Specifically, a transport system would consider protocols 956 identical only if they are of the same type and version. For 957 example, the same version of TLS running over two different 958 transport protocol stacks are considered equivalent, whereas TLS 959 1.2 and TLS 1.3 [RFC8446] are not considered equivalent. 961 4.2.4. Separating Connection Groups 963 By default, all stored properties of the implementation are shared 964 within a process, such as cached protocol state, cached path state, 965 and heuristics. This provides efficiency and convenience for the 966 application, since the Transport System implementation can 967 automatically optimize behavior. 969 There are several reasons, however, that an application might want to 970 isolate some Connections within a single process. These reasons 971 include: 973 o Privacy concerns about re-using cached protocol state that can 974 lead to linkability. Sensitive state may include TLS session 975 state [RFC8446] and HTTP cookies [RFC6265]. 977 o Privacy concerns about allowing Connections to multiplex together, 978 which can tell a Remote Endpoint that all of the Connections are 979 coming from the same application (for example, when Connections 980 are multiplexed HTTP/2 or QUIC streams). 982 o Performance concerns about Connections introducing head-of-line 983 blocking due to multiplexing or needing to share state on a single 984 thread. 986 The Transport Services API SHOULD allow applications to explicitly 987 define Connection Groups that force separation of Cached State and 988 Protocol Stacks. For example, a web browser application might use 989 Connection Groups with separate caches for different tabs in the 990 browser to decrease linkability. 992 The interface to specify these groups MAY expose fine-grained tuning 993 for which properties and cached state is allowed to be shared with 994 other Connections. For example, an application might want to allow 995 sharing TCP Fast Open cookies across groups, but not TLS session 996 state. 998 5. IANA Considerations 1000 RFC-EDITOR: Please remove this section before publication. 1002 This document has no actions for IANA. 1004 6. Security Considerations 1006 The Transport Services architecture does not recommend use of 1007 specific security protocols or algorithms. Its goal is to offer ease 1008 of use for existing protocols by providing a generic security-related 1009 interface. Each provided interface translates to an existing 1010 protocol-specific interface provided by supported security protocols. 1011 For example, trust verification callbacks are common parts of TLS 1012 APIs. Transport Services APIs will expose similar functionality 1013 [I-D.ietf-taps-transport-security]. 1015 As described above in Section 4.2.3, if a Transport Services system 1016 races between two different Protocol Stacks, both MUST use the same 1017 security protocols and options. 1019 Clients need to ensure that security APIs are used appropriately. In 1020 cases where clients use an interface to provide sensitive keying 1021 material, e.g., access to private keys or copies of pre-shared keys 1022 (PSKs), key use needs to be validated. For example, clients ought 1023 not to use PSK material created for the Encapsulating Security 1024 Protocol (ESP, part of IPsec) [RFC4303] with QUIC, and clients ought 1025 not to use private keys intended for server authentication as a keys 1026 for client authentication. 1028 Moreover, Transport Services systems MUST NOT automatically fall back 1029 from secure protocols to insecure protocols, or to weaker versions of 1030 secure protocols. For example, if a client requests TLS, but the 1031 desired version of TLS is not available, its connection will fail. 1032 Clients are thus responsible for implementing security protocol 1033 fallback or version fallback by creating multiple Transport Services 1034 Connections, if so desired. 1036 7. Acknowledgements 1038 This work has received funding from the European Union's Horizon 2020 1039 research and innovation programme under grant agreements No. 644334 1040 (NEAT) and No. 688421 (MAMI). 1042 This work has been supported by Leibniz Prize project funds of DFG - 1043 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 1044 FE 570/4-1). 1046 This work has been supported by the UK Engineering and Physical 1047 Sciences Research Council under grant EP/R04144X/1. 1049 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 1050 Kinnear for their implementation and design efforts, including Happy 1051 Eyeballs, that heavily influenced this work. 1053 8. References 1055 8.1. Normative References 1057 [I-D.ietf-taps-interface] 1058 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1059 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 1060 Pauly, "An Abstract Application Layer Interface to 1061 Transport Services", draft-ietf-taps-interface-04 (work in 1062 progress), July 2019. 1064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1065 Requirement Levels", BCP 14, RFC 2119, 1066 DOI 10.17487/RFC2119, March 1997, 1067 . 1069 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1070 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1071 May 2017, . 1073 8.2. Informative References 1075 [I-D.ietf-taps-impl] 1076 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 1077 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 1078 "Implementing Interfaces to Transport Services", draft- 1079 ietf-taps-impl-04 (work in progress), July 2019. 1081 [I-D.ietf-taps-minset] 1082 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 1083 Services for End Systems", draft-ietf-taps-minset-11 (work 1084 in progress), September 2018. 1086 [I-D.ietf-taps-transport-security] 1087 Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. 1088 Rose, "A Survey of Transport Security Protocols", draft- 1089 ietf-taps-transport-security-09 (work in progress), 1090 September 2019. 1092 [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology 1093 -- Portable Operating System Interface (POSIX). Open 1094 group Technical Standard: Base Specifications, Issue 7", 1095 n.d.. 1097 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1098 RFC 793, DOI 10.17487/RFC0793, September 1981, 1099 . 1101 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1102 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1103 . 1105 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1106 DOI 10.17487/RFC6265, April 2011, 1107 . 1109 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1110 Protocol (HTTP/1.1): Message Syntax and Routing", 1111 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1112 . 1114 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1115 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1116 DOI 10.17487/RFC7540, May 2015, 1117 . 1119 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1120 Ed., "Services Provided by IETF Transport Protocols and 1121 Congestion Control Mechanisms", RFC 8095, 1122 DOI 10.17487/RFC8095, March 2017, 1123 . 1125 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1126 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1127 . 1129 Authors' Addresses 1131 Tommy Pauly (editor) 1132 Apple Inc. 1133 One Apple Park Way 1134 Cupertino, California 95014 1135 United States of America 1137 Email: tpauly@apple.com 1139 Brian Trammell (editor) 1140 Google 1141 Gustav-Gull-Platz 1 1142 8004 Zurich 1143 Switzerland 1145 Email: ietf@trammell.ch 1146 Anna Brunstrom 1147 Karlstad University 1148 Universitetsgatan 2 1149 651 88 Karlstad 1150 Sweden 1152 Email: anna.brunstrom@kau.se 1154 Godred Fairhurst 1155 University of Aberdeen 1156 Fraser Noble Building 1157 Aberdeen, AB24 3UE 1158 Scotland 1160 Email: gorry@erg.abdn.ac.uk 1161 URI: http://www.erg.abdn.ac.uk/ 1163 Colin Perkins 1164 University of Glasgow 1165 School of Computing Science 1166 Glasgow G12 8QQ 1167 United Kingdom 1169 Email: csp@csperkins.org 1171 Philipp S. Tiesel 1172 TU Berlin 1173 Einsteinufer 25 1174 10587 Berlin 1175 Germany 1177 Email: philipp@tiesel.net 1179 Chris Wood 1180 Apple Inc. 1181 One Apple Park Way 1182 Cupertino, California 95014 1183 United States of America 1185 Email: cawood@apple.com