idnits 2.17.1 draft-ietf-taps-arch-03.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 (March 11, 2019) is 1865 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 (-18) exists of draft-ietf-taps-impl-02 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-02 == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: September 12, 2019 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 March 11, 2019 18 An Architecture for Transport Services 19 draft-ietf-taps-arch-03 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 September 12, 2019. 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Event-Driven API . . . . . . . . . . . . . . . . . . . . 5 71 1.3. Data Transfer Using Messages . . . . . . . . . . . . . . 5 72 1.4. Flexibile Implementation . . . . . . . . . . . . . . . . 6 73 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.1. Specification of Requirements . . . . . . . . . . . . . . 7 75 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8 76 3.1. Common APIs for Common Features . . . . . . . . . . . . . 8 77 3.2. Access to Specialized Features . . . . . . . . . . . . . 8 78 3.3. Scope for API and Implementation Definitions . . . . . . 9 79 4. Transport Services Architecture and Concepts . . . . . . . . 10 80 4.1. Transport Services API Concepts . . . . . . . . . . . . . 11 81 4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 13 82 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 14 83 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 15 84 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 16 85 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 16 86 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 17 87 4.2. Transport System Implementation Concepts . . . . . . . . 17 88 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 19 89 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 19 90 4.2.3. Protocol Stack Equivalence . . . . . . . . . . . . . 19 91 4.2.4. Separating Connection Groups . . . . . . . . . . . . 21 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 95 8. Informative References . . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 Many application programming interfaces (APIs) to perform transport 101 networking have been deployed, perhaps the most widely known and 102 imitated being the BSD socket() [POSIX] interface. The naming of 103 objects and functions across these APIs is not consistent, and varies 104 depending on the protocol being used. For example, sending and 105 receiving streams of data is conceptually the same for both an 106 unencrypted Transmission Control Protocol (TCP) stream and operating 107 on an encrypted Transport Layer Security (TLS) [RFC8446] stream over 108 TCP, but applications cannot use the same socket send() and recv() 109 calls on top of both kinds of connections. Similarly, terminology 110 for the implementation of transport protocols varies based on the 111 context of the protocols themselves: terms such as "flow", "stream", 112 "message", and "connection" can take on many different meanings. 113 This variety can lead to confusion when trying to understand the 114 similarities and differences between protocols, and how applications 115 can use them effectively. 117 The goal of the Transport Services architecture is to provide a 118 common, flexible, and reusable interface for transport protocols. As 119 applications adopt this interface, they will benefit from a wide set 120 of transport features that can evolve over time, and ensure that the 121 system providing the interface can optimize its behavior based on the 122 application requirements and network conditions, without requiring 123 changes to the applications. This flexibility does not only enable 124 faster deployment of new feature and protocols, but it can also 125 support applications with racing and fallback mechanisms which 126 otherwise need to be implemented in each application separately. 128 This document is developed in parallel with the specification of the 129 Transport Services API [I-D.ietf-taps-interface] and Implementation 130 Guidelines [I-D.ietf-taps-impl]. Although following the Transport 131 Services Architecture does of course not mean that all APIs and 132 implementations have to be identical, a common minimal set of 133 features represented in a consistent fashion will enable applications 134 to be easily ported from one system to the another. 136 1.1. Overview 138 The model of using sockets for networking can be represented as 139 follows: applications create connections and transfer data using the 140 socket API, which provides the interface to the implementations of 141 UDP and TCP (typically implemented in the system's kernel), which in 142 turn send data over the available network layer interfaces. 144 +-----------------------------------------------------+ 145 | Application | 146 +-----------------------------------------------------+ 147 | | 148 +---------------------+ +-----------------------+ 149 | Socket Stream API | | Socket Datagram API | 150 +---------------------+ +-----------------------+ 151 | | 152 +-----------------------------------------------------+ 153 | TCP UDP | 154 | Kernel Protocol Implementation | 155 +-----------------------------------------------------+ 156 | 157 +-----------------------------------------------------+ 158 | Network Layer Interface | 159 +-----------------------------------------------------+ 161 Figure 1: socket() API Model 163 The Transport Services architecture maintains this general model of 164 interaction, but aims to both modernize the API surface exposed for 165 transport protocols and enrich the capabilities of the transport 166 system implementation. 168 +-----------------------------------------------------+ 169 | Application | 170 +-----------------------------------------------------+ 171 | 172 +-----------------------------------------------------+ 173 | Transport Services API | 174 +-----------------------------------------------------+ 175 | 176 +-----------------------------------------------------+ 177 | Transport System Implementation | 178 | (UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) | 179 +-----------------------------------------------------+ 180 | 181 +-----------------------------------------------------+ 182 | Network Layer Interface | 183 +-----------------------------------------------------+ 185 Figure 2: Transport Services API Model 187 The Transport Services API [I-D.ietf-taps-interface] defines the 188 mechanism for an application to create network connections and 189 transfer data. The Implementation [I-D.ietf-taps-impl] is 190 responsible for mapping the API into the various available transport 191 protocols and managing the available network interfaces and paths. 193 There are a few key departures that Transport Services makes from the 194 sockets API: it presents an asynchronous, event-driven API; it uses 195 messages for representing data transfer to applications; and it 196 assumes an implementation that can use multiple IP addresses, 197 multiple protocols, multiple paths, and provide multiple application 198 streams. 200 1.2. Event-Driven API 202 Originally, sockets presented a blocking interface for establishing 203 connections and transferring data. However, most modern applications 204 interact with the network asynchronously. When sockets are presented 205 as an asynchronous interface, they generally use a try-and-fail 206 model. If the application wants to read, but data has not yet been 207 received from the peer, the call to read will fail. The application 208 then waits and can try again later. 210 All interaction with a Transport Services system is expected to be 211 asynchronous, and use an event-driven model unlike sockets 212 Section 4.1.5. For example, if the application wants to read, its 213 call to read will not fail, but will deliver an event containing the 214 received data once it is available. 216 The Transport Services API also delivers events regarding the 217 lifetime of a connection and changes to available network links, 218 which were not previously made explicit in sockets. 220 Using asynchronous events allows for a much simpler interaction model 221 when establishing connections and transferring data. Events in time 222 more closely reflect the nature of interactions over networks, as 223 opposed to how sockets represent network resources as file system 224 objects that may be temporarily unavailable. 226 1.3. Data Transfer Using Messages 228 Sockets provide a message interface for datagram protocols like UDP, 229 but provide an unstructured stream abstraction for TCP. While TCP 230 does indeed provide the ability to send and receive data as streams, 231 most applications need to interpret structure within these streams. 232 For example, HTTP/1.1 uses character delimiters to segment messages 233 over a stream; TLS record headers carry a version, content type, and 234 length; and HTTP/2 uses frames to segment its headers and bodies. 236 The Transport Services API represents data as messages, so that it 237 more closely matches the way applications use the network. Messages 238 seamlessly work with transport protocols that support datagrams or 239 records, but can also be used over a stream by defining an 240 application-layer framer Section 4.1.4. When framing protocols are 241 placed on top of unstructured streams, the messages used in the API 242 represent the framed messages within the stream. In the absence of a 243 framer, protocols that deal only in byte streams, such as TCP, 244 represent their data in each direction as a single, long message. 246 Providing a message-based abstraction provides many benefits, such 247 as: 249 o the ability to associate deadlines with messages, for applications 250 that care about timing; 252 o the ability to provide control of reliability, choosing which 253 messages to retransmit in the event of packet loss, and how best 254 to make use of the data that arrived; 256 o the ability to manage dependencies between messages, when the 257 transport system could decide to not deliver a message, either 258 following packet loss or because it has missed a deadline. In 259 particular, this can avoid (re-)sending data that relies on a 260 previous transmission that was never received. 262 Allowing applications to interact with messages is backwards- 263 compatible with existings protocols and APIs, as it does not change 264 the wire format of any protocol. Instead, it gives the protocol 265 stack additional information to allow it to make better use of modern 266 transport services, while simplifying the application's role in 267 parsing data. 269 1.4. Flexibile Implementation 271 Sockets, for protocols like TCP, are generally limited to connecting 272 to a single address over a single interface. They also present a 273 single stream to the application. Software layers built upon sockets 274 often propagate this limitation of a single-address single-stream 275 model. The Transport Services architecture is designed to handle 276 multiple candidate endpoints, protocols, and paths; and support 277 multipath and multistreaming protocols. 279 Transport Services implementations are meant to be flexible at 280 connection establishment time, considering many different options and 281 trying to select the most optimal combinations (Section 4.2.1 and 282 Section 4.2.2). This requires applications to provide higher-level 283 endpoints than IP addresses, such as hostnames and URLs, which are 284 used by a Transport Services implementation for resolution, path 285 selection, and racing. 287 Flexibility after connection establishment is also important. 288 Transport protocols that can migrate between multiple network-layer 289 interfaces need to be able to process and react to interface changes. 290 Protocols that support multiple application-layer streams need to 291 support initiating and receiving new streams using existing 292 connections. 294 2. Background 296 The Transport Services architecture is based on the survey of 297 Services Provided by IETF Transport Protocols and Congestion Control 298 Mechanisms [RFC8095], and the distilled minimal set of the features 299 offered by transport protocols [I-D.ietf-taps-minset]. These 300 documents identified common features and patterns across all 301 transport protocols developed thus far in the IETF. 303 Since transport security is an increasingly relevant aspect of using 304 transport protocols on the Internet, this architecture also considers 305 the impact of transport security protocols on the feature-set exposed 306 by transport services [I-D.ietf-taps-transport-security]. 308 One of the key insights to come from identifying the minimal set of 309 features provided by transport protocols [I-D.ietf-taps-minset] was 310 that features either require application interaction and guidance 311 (referred to as Functional Features), or else can be handled 312 automatically by a system implementing Transport Services (referred 313 to as Automatable Features). Among the Functional Features, some 314 were common across all or nearly all transport protocols, while 315 others could be seen as features that, if specified, would only be 316 useful with a subset of protocols, but would not harm the 317 functionality of other protocols. For example, some protocols can 318 deliver messages faster for applications that do not require messages 319 to arrive in the order in which they were sent. However, this 320 functionality needs to be explicitly allowed by the application, 321 since reordering messages would be undesirable in many cases. 323 2.1. Specification of Requirements 325 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 326 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 327 "OPTIONAL" in this document are to be interpreted as described in BCP 328 14 [RFC2119] [RFC8174] when, and only when, they appear in all 329 capitals, as shown here. 331 3. Design Principles 333 The goal of the Transport Services architecture is to redefine the 334 interface between applications and transports in a way that allows 335 the transport layer to evolve and improve without fundamentally 336 changing the contract with the application. This requires a careful 337 consideration of how to expose the capabilities of protocols. 339 There are several degrees in which a Transport Services system can 340 offer flexibility to an application: it can provide access to 341 multiple sets of protocols and protocol features; it can use these 342 protocols across multiple paths that could have different performance 343 and functional characteristics; and it can communicate with different 344 remote systems to optimize performance, robustness to failure, or 345 some other metric. Beyond these, if the API for the system remains 346 the same over time, new protocols and features could be added to the 347 system's implementation without requiring changes in applications for 348 adoption. 350 The following considerations were used in the design of this 351 architecture. 353 3.1. Common APIs for Common Features 355 Functionality that is common across multiple transport protocols 356 SHOULD be accessible through a unified set of API calls. An 357 application ought to be able to implement logic for its basic use of 358 transport networking (establishing the transport, and sending and 359 receiving data) once, and expect that implementation to continue to 360 function as the transports change. 362 Any Transport Services API is REQUIRED to allow access to the 363 distilled minimal set of features offered by transport protocols 364 [I-D.ietf-taps-minset]. 366 3.2. Access to Specialized Features 368 There are applications that will need to control fine-grained details 369 of transport protocols to optimize their behavior and ensure 370 compatibility with remote systems. A Transport Services system 371 therefore SHOULD also permit more specialized protocol features to be 372 used. The interface for these specialized options should be exposed 373 differently from the common options to ensure flexibility. 375 A specialized feature could be required by an application only when 376 using a specific protocol, and not when using others. For example, 377 if an application is using UDP, it could require control over the 378 checksum or fragmentation behavior for UDP; if it used a protocol to 379 frame its data over a byte stream like TCP, it would not need these 380 options. In such cases, the API ought to expose the features in such 381 a way that they take effect when a particular protocol is selected, 382 but do not imply that only that protocol could be used. For example, 383 if the API allows an application to specify a preference for 384 constrained checksum usage, communication would not fail when a 385 protocol such as TCP is selected, which uses a checksum covering the 386 entire payload. 388 Other specialized features, however, could be strictly required by an 389 application and thus constrain the set of protocols that can be used. 390 For example, if an application requires encryption of its transport 391 data, only protocol stacks that include some transport security 392 protocol are eligible to be used. A Transport Services API MUST 393 allow applications to define such requirements and constrain the 394 system's options. Since such options are not part of the core/common 395 features, it will generally be simple for an application to modify 396 its set of constraints and change the set of allowable protocol 397 features without changing the core implementation. 399 3.3. Scope for API and Implementation Definitions 401 The Transport Services API is envisioned as the abstract model for a 402 family of APIs that share a common way to expose transport features 403 and encourage flexibility. The abstract API definition 404 [I-D.ietf-taps-interface] describes this interface and is aimed at 405 application developers. 407 Implementations that provide the Transport Services API 408 [I-D.ietf-taps-impl] will vary due to system-specific support and the 409 needs of the deployment scenario. It is expected that all 410 implementations of Transport Services will offer the entire mandatory 411 API, but that some features will not be functional in certain 412 implementations. All implementations are REQUIRED to offer 413 sufficient APIs to use the distilled minimal set of features offered 414 by transport protocols [I-D.ietf-taps-minset], including API support 415 for TCP and UDP transport, but it is possible that some very 416 constrained devices might not have, for example, a full TCP 417 implementation beneath the API. 419 To preserve flexibility and compatibility with future protocols, top- 420 level features in the Transport Services API SHOULD avoid referencing 421 particular transport protocols. The mappings of these API features 422 to specific implementations of each feature is explained in the 423 [I-D.ietf-taps-impl] along with the implications of the feature on 424 existing protocols. It is expected that this document will be 425 updated and supplemented as new protocols and protocol features are 426 developed. 428 It is important to note that neither the Transport Services API 429 [I-D.ietf-taps-interface] nor the Implementation document 430 [I-D.ietf-taps-impl] defines new protocols that require any changes 431 to a remote system. The Transport Services system MUST be deployable 432 on one side only. 434 4. Transport Services Architecture and Concepts 436 The concepts defined in this document are intended primarily for use 437 in the documents and specifications that describe the Transport 438 Services architecture and API. While the specific terminology can be 439 used in some implementations, it is expected that there will remain a 440 variety of terms used by running code. 442 The architecture divides the concepts for Transport Services into two 443 categories: 445 1. API concepts, which are intended to be exposed to applications; 446 and 448 2. System-implementation concepts, which are intended to be 449 internally used when building systems that implement Transport 450 Services. 452 The following diagram summarizes the top-level concepts in the 453 architecture and how they relate to one another. 455 +-----------------------------------------------------+ 456 | Application | 457 +-+----------------+------^-------+--------^----------+ 458 | | | | | 459 pre- | data | events 460 establishment | transfer | | 461 | establishment | termination | 462 | | | | | 463 | +--v------v-------v+ | 464 +-v-------------+ Connection(s) +-------+----------+ 465 | Transport +--------+---------+ | 466 | Services | | 467 | API | | 468 +------------------------|----------------------------+ 469 | 470 +------------------------|----------------------------+ 471 | Transport | | 472 | System | +-----------------+ | 473 | Implementation | | Cached | | 474 | | | State | | 475 | (Candidate Gathering) | +-----------------+ | 476 | | | 477 | (Candidate Racing) | +-----------------+ | 478 | | | System | | 479 | | | Policy | | 480 | +----------v-----+ +-----------------+ | 481 | | Protocol | | 482 +-------------+ Stack(s) +----------------------+ 483 +-------+--------+ 484 V 485 Network Layer Interface 487 Figure 3: Concepts and Relationships in the Transport Services 488 Architecture 490 4.1. Transport Services API Concepts 492 Fundamentally, a Transport Services API needs to provide basic 493 objects (Section 4.1.1) that allow applications to establish 494 communication and send and receive data. These could be exposed as 495 handles or referenced objects, depending on the language. 497 Beyond the basic objects, there are several high-level groups of 498 actions that any Transport Services API implementing this 499 specification MUST provide: 501 o Pre-Establishment (Section 4.1.2) encompasses the properties that 502 an application can pass to describe its intent, requirements, 503 prohibitions, and preferences for its networking operations. For 504 any system that provides generic Transport Services, these 505 properties SHOULD be defined to apply to multiple transport 506 protocols. Properties specified during Pre-Establishment can have 507 a large impact on the rest of the interface: they modify how 508 establishment occurs, they influence the expectations around data 509 transfer, and they determine the set of events that will be 510 supported. 512 o Establishment (Section 4.1.3) focuses on the actions that an 513 application takes on the basic objects to prepare for data 514 transfer. 516 o Data Transfer (Section 4.1.4) consists of how an application 517 represents the data to be sent and received, the functions 518 required to send and receive that data, and how the application is 519 notified of the status of its data transfer. 521 o Event Handling (Section 4.1.5) defines the set of properties about 522 which an application can receive notifications during the lifetime 523 of transport objects. Events MAY also provide opportunities for 524 the application to interact with the underlying transport by 525 querying state or updating maintenance options. 527 o Termination (Section 4.1.6) focuses on the methods by which data 528 transmission is stopped, and state is torn down in the transport. 530 The diagram below provides a high-level view of the actions taken 531 during the lifetime of a connection. Note that some actions are 532 alternatives (e.g., whether to initiate a connection or to listen for 533 incoming connections), others are optional (e.g., setting Connection 534 and Message Properties in Pre-Establishment), or have been omitted 535 for brevity. 537 Pre-Establishment : Established : Termination 538 ----------------- : ----------- : ----------- 539 : Close() : 540 +---------------+ Initiate() +------------+ Abort() : 541 +-->| Preconnection |----------->| Connection |---------------> Closed 542 | +---------------+ : +------------+ Connection: 543 | : ^ ^ ^ | Finished : 544 +-- Local Endpoint : | | | | : 545 | : | | | +---------+ : 546 +-- Remote Endpoint : +----+ | +-----+ | : 547 | : | |Send() | | : 548 +-- Selection Properties : | +---------+ | v : 549 +-- Connection Properties ---+ | Message | | Message : 550 +-- Message Properties -------->| to send | | Received : 551 | : +---------+ | : 552 | +----------+ : | : 553 +-->| Listener |------------------------------+ : 554 +----------+ Connection Received : 555 ^ : : 556 | : : 557 Listen() : : 559 Figure 4: The lifetime of a connection 561 4.1.1. Basic Objects 563 o Preconnection: A Preconnection object is a representation of a 564 potential connection. It has state that describes parameters of a 565 Connection that might exist in the future: the Local Endpoint from 566 which that Connection will be established, the Remote Endpoint 567 (Section 4.1.2) to which it will connect, and Selection Properties 568 (Section 4.1.2) that influence the paths and protocols a 569 Connection will use. A Preconnection can be fully specified and 570 represent a single possible Connection, or it can be partially 571 specified such that it represents a family of possible 572 Connections. The Local Endpoint (Section 4.1.2) MUST be specified 573 if the Preconnection is used to Listen for incoming connections. 574 The Local Endpoint is OPTIONAL if it is used to Initiate 575 connections. The Remote Endpoint MUST be specified in the 576 Preconnection is used to Initiate connections. The Remote 577 Endpoint is OPTIONAL if it is used to Listen for incoming 578 connections. The Local Endpoint and the Remote Endpoint MUST both 579 be specified if a peer-to-peer Rendezvous is to occur based on the 580 Preconnection. 582 * Transport Properties: Transport Properties can be specified as 583 part of a Preconnection to allow the application to configure 584 the Transport System and express their requirements, 585 prohibitions, and preferences. There are three kinds of 586 Transport Properties: Selection Properties (Section 4.1.2), 587 Connection Properties (Section 4.1.2), and Message Properties 588 (Section 4.1.4). Message Properties can also be specified 589 during data transfer to affect specific Messages. 591 o Connection: A Connection object represents an active transport 592 protocol instance that can send and/or receive Messages between 593 local and remote systems. It holds state pertaining to the 594 underlying transport protocol instance and any ongoing data 595 transfer. This represents, for example, an active connection in a 596 connection-oriented protocol such as TCP, or a fully-specified 597 5-tuple for a connectionless protocol such as UDP. 599 o Listener: A Listener object accepts incoming transport protocol 600 connections from remote systems and generates corresponding 601 Connection objects. It is created from a Preconnection object 602 that specifies the type of incoming connections it will accept. 604 4.1.2. Pre-Establishment 606 o Endpoint: An Endpoint represents an identifier for one side of a 607 transport connection. Endpoints can be Local Endpoints or Remote 608 Endpoints, and respectively represent an identity that the 609 application uses for the source or destination of a connection. 610 An Endpoint can be specified at various levels, and an Endpoint 611 with wider scope (such as a hostname) can be resolved to more 612 concrete identities (such as IP addresses). 614 o Remote Endpoint: The Remote Endpoint represents the application's 615 identifier for a peer that can participate in a transport 616 connection. For example, the combination of a DNS name for the 617 peer and a service name/port. 619 o Local Endpoint: The Local Endpoint represents the application's 620 identifier for itself that it uses for transport connections. For 621 example, a local IP address and port. 623 o Selection Properties: The Selection Properties consist of the 624 options that an application can set to influence the selection of 625 paths between the local and remote systems, to influence the 626 selection of transport protocols, or to configure the behavior of 627 generic transport protocol features. These options can take the 628 form of requirements, prohibitions, or preferences. Examples of 629 options that influence path selection include the interface type 630 (such as a Wi-Fi Ethernet connection, or a Cellular LTE 631 connection), requirements around the Maximum Transmission Unit 632 (MTU) or path MTU (PMTU), or preferences for throughput and 633 latency properties. Examples of options that influence protocol 634 selection and configuration of transport protocol features include 635 reliability, service class, multipath support, and fast open 636 support. 638 o Connection Properties: The Connection Properties are used to 639 configure protocol-specific options and control per-connection 640 behavior of the Transport System. For example, a protocol- 641 specific Connection Property can express that if UDP is used, the 642 implementation ought to use checksums. Note that the presence of 643 such a property does not require that a specific protocol will be 644 used. In general, these properties do not explicitly determine 645 the selection of paths or protocols, but MAY be used in this way 646 by an implementation during connection establishment. Connection 647 Properties SHOULD be specified on a Preconnection prior to 648 Connection establishment, but MAY be modified later. Changes made 649 to Connection Properties after establishment take effect on a 650 best-effort basis. 652 4.1.3. Establishment Actions 654 o Initiate: The primary action that an application can take to 655 create a Connection to a Remote Endpoint, and prepare any required 656 local or remote state to be able to send and/or receive Messages. 657 For some protocols, this will initiate a client-to-server style 658 handshake; for other protocols, this will just establish local 659 state. The process of identifying options for connecting, such as 660 resolution of the Remote Endpoint, occurs in response the Initiate 661 call. 663 o Listen: The action of marking a Listener as willing to accept 664 incoming Connections. The Listener will then create Connection 665 objects as incoming connections are accepted (Section 4.1.5). 667 o Rendezvous: The action of establishing a peer-to-peer connection 668 with a Remote Endpoint. It simultaneously attempts to initiate a 669 connection to a Remote Endpoint whilst listening for an incoming 670 connection from that endpoint. This corresponds, for example, to 671 a TCP simultaneous open [RFC0793]. The process of identifying 672 options for the connection, such as resolution of the Remote 673 Endpoint, occurs during the Rendezvous call. If successful, the 674 rendezvous call returns a Connection object to represent the 675 established peer-to-peer connection. 677 4.1.4. Data Transfer Objects and Actions 679 o Message: A Message object is a unit of data that can be 680 represented as bytes that can be transferred between two systems 681 over a transport connection. The bytes within a Message are 682 assumed to be ordered within the Message. If an application does 683 not care about the order in which a peer receives two distinct 684 spans of bytes, those spans of bytes are considered independent 685 Messages. If a received Message is incomplete or corrupted, it 686 might or might not be usable by certain applications. Boundaries 687 of a Message might or might not be understood or transmitted by 688 transport protocols. Specifically, what one application considers 689 to be two Messages sent on a stream-based transport can be treated 690 as a single Message by the application on the other side. 692 o Message Properties: Message Properties can be used to annotate 693 specific Messages. These properties can specify how the transport 694 will send the Message (for prioritization and reliability), along 695 with any per-protocol properties to send with the Message. 696 Message Properties MAY be set on a Preconnection to define 697 defaults properties for sending. When receiving Messages, Message 698 Properties can contain per-protocol properties. 700 o Send: The action to transmit a Message or partial Message over a 701 Connection to the remote system. The interface to Send MAY 702 include Message Properties specific to how the Message's content 703 is to be sent. Status of the Send operation can be delivered back 704 to the application in an event (Section 4.1.5). 706 o Receive: An action that indicates that the application is ready to 707 asynchronously accept a Message over a Connection from a remote 708 system, while the Message content itself will be delivered in an 709 event (Section 4.1.5). The interface to Receive MAY include 710 Message Properties specific to the Message that is to be delivered 711 to the application. 713 o Framer: A Framer is a data translation layer that can be added to 714 a Connection to define how application-level Messages are 715 transmitted over a transport protocol. This is particularly 716 relevant for protocols that otherwise present unstructured 717 streams, such as TCP. 719 4.1.5. Event Handling 721 This list of events that can be delivered to an application is not 722 exhaustive, but gives the top-level categories of events. The API 723 MAY expand this list. 725 o Connection Ready: Signals to an application that a given 726 Connection is ready to send and/or receive Messages. If the 727 Connection relies on handshakes to establish state between peers, 728 then it is assumed that these steps have been taken. 730 o Connection Finished: Signals to an application that a given 731 Connection is no longer usable for sending or receiving Messages. 732 The event SHOULD deliver a reason or error to the application that 733 describes the nature of the termination. 735 o Connection Received: Signals to an application that a given 736 Listener has passively received a Connection. 738 o Message Received: Delivers received Message content to the 739 application, based on a Receive action. This MAY include an error 740 if the Receive action cannot be satisfied due to the Connection 741 being closed. 743 o Message Sent: Notifies the application of the status of its Send 744 action. This might indicate a failure if the Message cannot be 745 sent, or an indication that Message has been processed by the 746 protocol stack. 748 o Path Properties Changed: Notifies the application that some 749 property of the Connection has changed that might influence how 750 and where data is sent and/or received. 752 4.1.6. Termination Actions 754 o Close: The action an application takes on a Connection to indicate 755 that it no longer intends to send data, is no longer willing to 756 receive data, and that the protocol SHOULD signal this state to 757 the remote system if the transport protocol allows this. 759 o Abort: The action the application takes on a Connection to 760 indicate a Close and also indicate that the transport system 761 SHOULD NOT attempt to deliver any outstanding data. 763 4.2. Transport System Implementation Concepts 765 The Transport System Implementation Concepts define the set of 766 objects used internally to a system or library to implement the 767 functionality needed to provide a transport service across a network, 768 as required by the abstract interface. 770 o Connection Group: A set of Connections that share properties and 771 caches. For multiplexing transport protocols, only Connections 772 within the same Connection Group are allowed be multiplexed 773 together. Applications can use their explicitly defined 774 Connection Groups to control caching boundaries, as discussed in 775 Section 4.2.4. 777 o Path: Represents an available set of properties that a local 778 system can use to communicate with a remote system, such as 779 routes, addresses, and physical and virtual network interfaces. 781 o Protocol Instance: A single instance of one protocol, including 782 any state it has necessary to establish connectivity or send and 783 receive Messages. 785 o Protocol Stack: A set of Protocol Instances (including relevant 786 application, security, transport, or Internet protocols) that are 787 used together to establish connectivity or send and receive 788 Messages. A single stack can be simple (a single transport 789 protocol instance over IP), or complex (multiple application 790 protocol streams going through a single security and transport 791 protocol, over IP; or, a multi-path transport protocol over 792 multiple transport sub-flows). 794 o Candidate Path: One path that is available to an application and 795 conforms to the Selection Properties and System Policy. Candidate 796 Paths are identified during the gathering phase (Section 4.2.1) 797 and can be used during the racing phase (Section 4.2.2). 799 o Candidate Protocol Stack: One protocol stack that can be used by 800 an application for a connection, of which there can be several. 801 Candidate Protocol Stacks are identified during the gathering 802 phase (Section 4.2.1) and are started during the racing phase 803 (Section 4.2.2). 805 o System Policy: Represents the input from an operating system or 806 other global preferences that can constrain or influence how an 807 implementation will gather candidate paths and protocol stacks 808 (Section 4.2.1) and race the candidates during establishment 809 (Section 4.2.2). Specific aspects of the System Policy either 810 apply to all Connections or only certain ones, depending on the 811 runtime context and properties of the Connection. 813 o Cached State: The state and history that the implementation keeps 814 for each set of associated Endpoints that have been used 815 previously. This can include DNS results, TLS session state, 816 previous success and quality of transport protocols over certain 817 paths. 819 4.2.1. Candidate Gathering 821 o Path Selection: Path Selection represents the act of choosing one 822 or more paths that are available to use based on the Selection 823 Properties provided by the application, the policies and 824 heuristics of a Transport Services system. 826 o Protocol Selection: Protocol Selection represents the act of 827 choosing one or more sets of protocol options that are available 828 to use based on the Transport Properties provided by the 829 application, and a Transport Services system's policies and 830 heuristics. 832 4.2.2. Candidate Racing 834 o Protocol Option Racing: Protocol Racing is the act of attempting 835 to establish, or scheduling attempts to establish, multiple 836 Protocol Stacks that differ based on the composition of protocols 837 or the options used for protocols. 839 o Path Racing: Path Racing is the act of attempting to establish, or 840 scheduling attempts to establish, multiple Protocol Stacks that 841 differ based on a selection from the available Paths. Since 842 different Paths will have distinct configurations for local 843 addresses and DNS servers, attempts across different Paths will 844 perform separate DNS resolution stepss, which can lead to further 845 racing of the resolved Remote Endpoints. 847 o Remote Endpoint Racing: Remote Endpoint Racing is the act of 848 attempting to establish, or scheduling attempts to establish, 849 multiple Protocol Stacks that differ based on the specific 850 representation of the Remote Endpoint, such as IP addresses 851 resolved from a DNS hostname. 853 4.2.3. Protocol Stack Equivalence 855 The Transport Services architecture defines a mechanism that allows 856 applications to easily use different network paths and Protocol 857 Stacks. Transitioning between different Protocol Stacks is in some 858 cases controlled by properties that only change when application code 859 is updated. For example, an application can enable the use of a 860 multipath or multistreaming transport protocol by modifying the 861 properties in its Pre-Connection configuration. In some cases, 862 however, the Transport Services system will be able to automatically 863 change Protocol Stacks without an update to the application, either 864 by selecting a new stack entirely, or by racing multiple candidate 865 Protocol Stacks during connection establishment. This functionality 866 can be a powerful driver of new protocol adoption, but needs to be 867 constrained carefully to avoid unexpected behavior that can lead to 868 functional or security problems. 870 If two different Protocol Stacks can be safely swapped, or raced in 871 parallel (see Section 4.2.2), then they are considered to be 872 "equivalent". Equivalent Protocol Stacks need to meet the following 873 criteria: 875 1. Both stacks MUST offer the same interface to the application for 876 connection establishment and data transmission. For example, if 877 one Protocol Stack has UDP as the top-level interface to the 878 application, then it is not equivalent to a Protocol Stack that 879 runs TCP as the top-level interface. Among other differences, 880 the UDP stack would allow an application to read out message 881 boundaries based on datagrams sent from the remote system, 882 whereas TCP does not preserve message boundaries on its own. 884 2. Both stacks MUST offer the same transport services, as required 885 by the application. For example, if an application specifies 886 that it requires reliable transmission of data, then a Protocol 887 Stack using UDP without any reliability layer on top would not be 888 allowed to replace a Protocol Stack using TCP. However, if the 889 application does not require reliability, then a Protocol Stack 890 that adds unnecessary reliability might be allowed as an 891 equivalent Protocol Stack as long as it does not conflict with 892 any other application-requested properties. 894 3. Both stacks MUST offer the same security properties. The 895 inclusion of transport security protocols 896 [I-D.ietf-taps-transport-security] in a Protocol Stack adds 897 additional restrictions to Protocol Stack equivalence. Security 898 features and properties, such as cryptographic algorithms, peer 899 authentication, and identity privacy vary across security 900 protocols, and across versions of security protocols. Protocol 901 equivalence ought not to be assumed for different protocols or 902 protocol versions, even if they offer similar application 903 configuration options. To ensure that security protocols are not 904 incorrectly swapped, Transport Services systems SHOULD only 905 automatically generate equivalent Protocol Stacks when the 906 transport security protocols within the stacks are identical. 907 Specifically, a transport system would consider protocols 908 identical only if they are of the same type and version. For 909 example, the same version of TLS running over two different 910 transport protocol stacks are considered equivalent, whereas TLS 911 1.2 and TLS 1.3 [RFC8446] are not considered equivalent. 913 4.2.4. Separating Connection Groups 915 By default, all stored properties of the Implementation are shared 916 within a process, such as cached protocol state, cached path state, 917 and heuristics. This provides efficiency and convenience for the 918 application, since the Transport System Implementation can 919 automatically optimize behavior. 921 There are several reasons, however, that an application might want to 922 isolate some Connections within a single process. These reasons 923 include: 925 o Privacy concerns about re-using cached protocol state that can 926 lead to linkability. Sensitive state may include TLS session 927 state [RFC8446] and HTTP cookies [RFC6265]. 929 o Privacy concerns about allowing Connections to multiplex together, 930 which can tell a Remote Endpoint that all of the Connections are 931 coming from the same application (for example, when Connections 932 are multiplexed HTTP/2 or QUIC streams). 934 o Performance concerns about Connections introducing head-of-line 935 blocking due to multiplexing or needing to share state on a single 936 thread. 938 The Transport Services API SHOULD allow applications to explicitly 939 define Connection Groups that force separation of Cached State and 940 Protocol Stacks. For example, a web browser application might use 941 Connection Groups with separate caches for different tabs in the 942 browser to decrease linkability. 944 The interface to specify these Groups MAY expose fine-grained tuning 945 for which properties and cached state is allowed to be shared with 946 other Connections. For example, an application might want to allow 947 sharing TCP Fast Open cookies across groups, but not TLS session 948 state. 950 5. IANA Considerations 952 RFC-EDITOR: Please remove this section before publication. 954 This document has no actions for IANA. 956 6. Security Considerations 958 The Transport Services architecture does not recommend use of 959 specific security protocols or algorithms. Its goal is to offer ease 960 of use for existing protocols by providing a generic security-related 961 interface. Each provided interface translates to an existing 962 protocol-specific interface provided by supported security protocols. 963 For example, trust verification callbacks are common parts of TLS 964 APIs. Transport Services APIs will expose similar functionality 965 [I-D.ietf-taps-transport-security]. 967 As described above in Section 4.2.3, if a Transport Services system 968 races between two different Protocol Stacks, both MUST use the same 969 security protocols and options. 971 Clients need to ensure that security APIs are used appropriately. In 972 cases where clients use an interface to provide sensitive keying 973 material, e.g., access to private keys or copies of pre-shared keys 974 (PSKs), key use needs to be validated. For example, clients ought 975 not to use PSK material created for the Encapsulating Security 976 Protocol (ESP, part of IPsec) [RFC4303] with QUIC, and clients ought 977 not to use private keys intended for server authentication as a keys 978 for client authentication. 980 Moreover, unlike certain transport features such as TCP Fast Open 981 (TFO) [RFC7413] or Explicit Congestion Notification (ECN) [RFC3168] 982 which can fall back to standard configurations, Transport Services 983 systems MUST prohibit fallback for security protocols. For example, 984 if a client requests TLS, yet TLS or the desired version are not 985 available, its connection will fail. Clients are thus responsible 986 for implementing security protocol fallback or version fallback by 987 creating multiple Transport Services Connections, if so desired. 989 7. Acknowledgements 991 This work has received funding from the European Union's Horizon 2020 992 research and innovation programme under grant agreements No. 644334 993 (NEAT) and No. 688421 (MAMI). 995 This work has been supported by Leibniz Prize project funds of DFG - 996 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 997 FE 570/4-1). 999 This work has been supported by the UK Engineering and Physical 1000 Sciences Research Council under grant EP/R04144X/1. 1002 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 1003 Kinnear for their implementation and design efforts, including Happy 1004 Eyeballs, that heavily influenced this work. 1006 8. Informative References 1008 [I-D.ietf-taps-impl] 1009 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 1010 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 1011 "Implementing Interfaces to Transport Services", draft- 1012 ietf-taps-impl-02 (work in progress), October 2018. 1014 [I-D.ietf-taps-interface] 1015 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1016 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 1017 Abstract Application Layer Interface to Transport 1018 Services", draft-ietf-taps-interface-02 (work in 1019 progress), October 2018. 1021 [I-D.ietf-taps-minset] 1022 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 1023 Services for End Systems", draft-ietf-taps-minset-11 (work 1024 in progress), September 2018. 1026 [I-D.ietf-taps-transport-security] 1027 Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. 1028 Rose, "A Survey of Transport Security Protocols", draft- 1029 ietf-taps-transport-security-06 (work in progress), March 1030 2019. 1032 [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology 1033 -- Portable Operating System Interface (POSIX). Open 1034 group Technical Standard: Base Specifications, Issue 7", 1035 n.d.. 1037 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1038 RFC 793, DOI 10.17487/RFC0793, September 1981, 1039 . 1041 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1042 Requirement Levels", BCP 14, RFC 2119, 1043 DOI 10.17487/RFC2119, March 1997, 1044 . 1046 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1047 of Explicit Congestion Notification (ECN) to IP", 1048 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1049 . 1051 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1052 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1053 . 1055 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1056 DOI 10.17487/RFC6265, April 2011, 1057 . 1059 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1060 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1061 . 1063 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1064 Ed., "Services Provided by IETF Transport Protocols and 1065 Congestion Control Mechanisms", RFC 8095, 1066 DOI 10.17487/RFC8095, March 2017, 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 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1074 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1075 . 1077 Authors' Addresses 1079 Tommy Pauly (editor) 1080 Apple Inc. 1081 One Apple Park Way 1082 Cupertino, California 95014 1083 United States of America 1085 Email: tpauly@apple.com 1087 Brian Trammell (editor) 1088 Google 1089 Gustav-Gull-Platz 1 1090 8004 Zurich 1091 Switzerland 1093 Email: ietf@trammell.ch 1094 Anna Brunstrom 1095 Karlstad University 1096 Universitetsgatan 2 1097 651 88 Karlstad 1098 Sweden 1100 Email: anna.brunstrom@kau.se 1102 Godred Fairhurst 1103 University of Aberdeen 1104 Fraser Noble Building 1105 Aberdeen, AB24 3UE 1106 Scotland 1108 Email: gorry@erg.abdn.ac.uk 1109 URI: http://www.erg.abdn.ac.uk/ 1111 Colin Perkins 1112 University of Glasgow 1113 School of Computing Science 1114 Glasgow G12 8QQ 1115 United Kingdom 1117 Email: csp@csperkins.org 1119 Philipp S. Tiesel 1120 TU Berlin 1121 Marchstrasse 23 1122 10587 Berlin 1123 Germany 1125 Email: philipp@inet.tu-berlin.de 1127 Chris Wood 1128 Apple Inc. 1129 One Apple Park Way 1130 Cupertino, California 95014 1131 United States of America 1133 Email: cawood@apple.com