idnits 2.17.1 draft-ietf-taps-arch-04.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 (July 08, 2019) is 1755 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-03 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-03 == 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: January 9, 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 July 08, 2019 18 An Architecture for Transport Services 19 draft-ietf-taps-arch-04 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 January 9, 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. 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 o the ability to automatically assign messages and connections to 263 underlaying transport connections to utilize multi-streaming and 264 pooled connections. 266 Allowing applications to interact with messages is backwards- 267 compatible with existings protocols and APIs, as it does not change 268 the wire format of any protocol. Instead, it gives the protocol 269 stack additional information to allow it to make better use of modern 270 transport services, while simplifying the application's role in 271 parsing data. 273 1.4. Flexibile Implementation 275 Sockets, for protocols like TCP, are generally limited to connecting 276 to a single address over a single interface. They also present a 277 single stream to the application. Software layers built upon sockets 278 often propagate this limitation of a single-address single-stream 279 model. The Transport Services architecture is designed to handle 280 multiple candidate endpoints, protocols, and paths; and support 281 multipath and multistreaming protocols. 283 Transport Services implementations are meant to be flexible at 284 connection establishment time, considering many different options and 285 trying to select the most optimal combinations (Section 4.2.1 and 286 Section 4.2.2). This requires applications to provide higher-level 287 endpoints than IP addresses, such as hostnames and URLs, which are 288 used by a Transport Services implementation for resolution, path 289 selection, and racing. 291 Flexibility after connection establishment is also important. 292 Transport protocols that can migrate between multiple network-layer 293 interfaces need to be able to process and react to interface changes. 294 Protocols that support multiple application-layer streams need to 295 support initiating and receiving new streams using existing 296 connections. 298 2. Background 300 The Transport Services architecture is based on the survey of 301 Services Provided by IETF Transport Protocols and Congestion Control 302 Mechanisms [RFC8095], and the distilled minimal set of the features 303 offered by transport protocols [I-D.ietf-taps-minset]. These 304 documents identified common features and patterns across all 305 transport protocols developed thus far in the IETF. 307 Since transport security is an increasingly relevant aspect of using 308 transport protocols on the Internet, this architecture also considers 309 the impact of transport security protocols on the feature-set exposed 310 by transport services [I-D.ietf-taps-transport-security]. 312 One of the key insights to come from identifying the minimal set of 313 features provided by transport protocols [I-D.ietf-taps-minset] was 314 that features either require application interaction and guidance 315 (referred to as Functional Features), or else can be handled 316 automatically by a system implementing Transport Services (referred 317 to as Automatable Features). Among the Functional Features, some 318 were common across all or nearly all transport protocols, while 319 others could be seen as features that, if specified, would only be 320 useful with a subset of protocols, but would not harm the 321 functionality of other protocols. For example, some protocols can 322 deliver messages faster for applications that do not require messages 323 to arrive in the order in which they were sent. However, this 324 functionality needs to be explicitly allowed by the application, 325 since reordering messages would be undesirable in many cases. 327 2.1. Specification of Requirements 329 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 330 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 331 "OPTIONAL" in this document are to be interpreted as described in BCP 332 14 [RFC2119] [RFC8174] when, and only when, they appear in all 333 capitals, as shown here. 335 3. Design Principles 337 The goal of the Transport Services architecture is to redefine the 338 interface between applications and transports in a way that allows 339 the transport layer to evolve and improve without fundamentally 340 changing the contract with the application. This requires a careful 341 consideration of how to expose the capabilities of protocols. 343 There are several degrees in which a Transport Services system can 344 offer flexibility to an application: it can provide access to 345 multiple sets of protocols and protocol features; it can use these 346 protocols across multiple paths that could have different performance 347 and functional characteristics; and it can communicate with different 348 remote systems to optimize performance, robustness to failure, or 349 some other metric. Beyond these, if the API for the system remains 350 the same over time, new protocols and features could be added to the 351 system's implementation without requiring changes in applications for 352 adoption. 354 The following considerations were used in the design of this 355 architecture. 357 3.1. Common APIs for Common Features 359 Functionality that is common across multiple transport protocols 360 SHOULD be accessible through a unified set of API calls. An 361 application ought to be able to implement logic for its basic use of 362 transport networking (establishing the transport, and sending and 363 receiving data) once, and expect that implementation to continue to 364 function as the transports change. 366 Any Transport Services API is REQUIRED to allow access to the 367 distilled minimal set of features offered by transport protocols 368 [I-D.ietf-taps-minset]. 370 3.2. Access to Specialized Features 372 There are applications that will need to control fine-grained details 373 of transport protocols to optimize their behavior and ensure 374 compatibility with remote systems. A Transport Services system 375 therefore SHOULD also permit more specialized protocol features to be 376 used. The interface for these specialized options should be exposed 377 differently from the common options to ensure flexibility. 379 A specialized feature could be required by an application only when 380 using a specific protocol, and not when using others. For example, 381 if an application is using UDP, it could require control over the 382 checksum or fragmentation behavior for UDP; if it used a protocol to 383 frame its data over a byte stream like TCP, it would not need these 384 options. In such cases, the API ought to expose the features in such 385 a way that they take effect when a particular protocol is selected, 386 but do not imply that only that protocol could be used. For example, 387 if the API allows an application to specify a preference for 388 constrained checksum usage, communication would not fail when a 389 protocol such as TCP is selected, which uses a checksum covering the 390 entire payload. 392 Other specialized features, however, could be strictly required by an 393 application and thus constrain the set of protocols that can be used. 394 For example, if an application requires encryption of its transport 395 data, only protocol stacks that include some transport security 396 protocol are eligible to be used. A Transport Services API MUST 397 allow applications to define such requirements and constrain the 398 system's options. Since such options are not part of the core/common 399 features, it will generally be simple for an application to modify 400 its set of constraints and change the set of allowable protocol 401 features without changing the core implementation. 403 3.3. Scope for API and Implementation Definitions 405 The Transport Services API is envisioned as the abstract model for a 406 family of APIs that share a common way to expose transport features 407 and encourage flexibility. The abstract API definition 408 [I-D.ietf-taps-interface] describes this interface and is aimed at 409 application developers. 411 Implementations that provide the Transport Services API 412 [I-D.ietf-taps-impl] will vary due to system-specific support and the 413 needs of the deployment scenario. It is expected that all 414 implementations of Transport Services will offer the entire mandatory 415 API, but that some features will not be functional in certain 416 implementations. All implementations are REQUIRED to offer 417 sufficient APIs to use the distilled minimal set of features offered 418 by transport protocols [I-D.ietf-taps-minset], including API support 419 for TCP and UDP transport, but it is possible that some very 420 constrained devices might not have, for example, a full TCP 421 implementation beneath the API. 423 To preserve flexibility and compatibility with future protocols, top- 424 level features in the Transport Services API SHOULD avoid referencing 425 particular transport protocols. The mappings of these API features 426 to specific implementations of each feature is explained in the 427 [I-D.ietf-taps-impl] along with the implications of the feature on 428 existing protocols. It is expected that this document will be 429 updated and supplemented as new protocols and protocol features are 430 developed. 432 It is important to note that neither the Transport Services API 433 [I-D.ietf-taps-interface] nor the Implementation document 434 [I-D.ietf-taps-impl] defines new protocols that require any changes 435 to a remote system. The Transport Services system MUST be deployable 436 on one side only. 438 4. Transport Services Architecture and Concepts 440 The concepts defined in this document are intended primarily for use 441 in the documents and specifications that describe the Transport 442 Services architecture and API. While the specific terminology can be 443 used in some implementations, it is expected that there will remain a 444 variety of terms used by running code. 446 The architecture divides the concepts for Transport Services into two 447 categories: 449 1. API concepts, which are intended to be exposed to applications; 450 and 452 2. System-implementation concepts, which are intended to be 453 internally used when building systems that implement Transport 454 Services. 456 The following diagram summarizes the top-level concepts in the 457 architecture and how they relate to one another. 459 +-----------------------------------------------------+ 460 | Application | 461 +-+----------------+------^-------+--------^----------+ 462 | | | | | 463 pre- | data | events 464 establishment | transfer | | 465 | establishment | termination | 466 | | | | | 467 | +--v------v-------v+ | 468 +-v-------------+ Connection(s) +-------+----------+ 469 | Transport +--------+---------+ | 470 | Services | | 471 | API | | 472 +------------------------|----------------------------+ 473 | 474 +------------------------|----------------------------+ 475 | Transport | | 476 | System | +-----------------+ | 477 | Implementation | | Cached | | 478 | | | State | | 479 | (Candidate Gathering) | +-----------------+ | 480 | | | 481 | (Candidate Racing) | +-----------------+ | 482 | | | System | | 483 | | | Policy | | 484 | +----------v-----+ +-----------------+ | 485 | | Protocol | | 486 +-------------+ Stack(s) +----------------------+ 487 +-------+--------+ 488 V 489 Network Layer Interface 491 Figure 3: Concepts and Relationships in the Transport Services 492 Architecture 494 4.1. Transport Services API Concepts 496 Fundamentally, a Transport Services API needs to provide basic 497 objects (Section 4.1.1) that allow applications to establish 498 communication and send and receive data. These could be exposed as 499 handles or referenced objects, depending on the language. 501 Beyond the basic objects, there are several high-level groups of 502 actions that any Transport Services API implementing this 503 specification MUST provide: 505 o Pre-Establishment (Section 4.1.2) encompasses the properties that 506 an application can pass to describe its intent, requirements, 507 prohibitions, and preferences for its networking operations. For 508 any system that provides generic Transport Services, these 509 properties SHOULD be defined to apply to multiple transport 510 protocols. Properties specified during Pre-Establishment can have 511 a large impact on the rest of the interface: they modify how 512 establishment occurs, they influence the expectations around data 513 transfer, and they determine the set of events that will be 514 supported. 516 o Establishment (Section 4.1.3) focuses on the actions that an 517 application takes on the basic objects to prepare for data 518 transfer. 520 o Data Transfer (Section 4.1.4) consists of how an application 521 represents the data to be sent and received, the functions 522 required to send and receive that data, and how the application is 523 notified of the status of its data transfer. 525 o Event Handling (Section 4.1.5) defines the set of properties about 526 which an application can receive notifications during the lifetime 527 of transport objects. Events MAY also provide opportunities for 528 the application to interact with the underlying transport by 529 querying state or updating maintenance options. 531 o Termination (Section 4.1.6) focuses on the methods by which data 532 transmission is stopped, and state is torn down in the transport. 534 The diagram below provides a high-level view of the actions taken 535 during the lifetime of a connection. Note that some actions are 536 alternatives (e.g., whether to initiate a connection or to listen for 537 incoming connections), others are optional (e.g., setting Connection 538 and Message Properties in Pre-Establishment), or have been omitted 539 for brevity. 541 Pre-Establishment : Established : Termination 542 ----------------- : ----------- : ----------- 543 : Close() : 544 +---------------+ Initiate() +------------+ Abort() : 545 +-->| Preconnection |----------->| Connection |---------------> Closed 546 | +---------------+ : +------------+ Connection: 547 | : ^ ^ ^ | Finished : 548 +-- Local Endpoint : | | | | : 549 | : | | | +---------+ : 550 +-- Remote Endpoint : +----+ | +-----+ | : 551 | : | |Send() | | : 552 +-- Selection Properties : | +---------+ | v : 553 +-- Connection Properties ---+ | Message | | Message : 554 +-- Message Properties -------->| to send | | Received : 555 | : +---------+ | : 556 | +----------+ : | : 557 +-->| Listener |------------------------------+ : 558 +----------+ Connection Received : 559 ^ : : 560 | : : 561 Listen() : : 563 Figure 4: The lifetime of a connection 565 4.1.1. Basic Objects 567 o Preconnection: A Preconnection object is a representation of a 568 potential connection. It has state that describes parameters of a 569 Connection that might exist in the future: the Local Endpoint from 570 which that Connection will be established, the Remote Endpoint 571 (Section 4.1.2) to which it will connect, and Selection Properties 572 (Section 4.1.2) that influence the paths and protocols a 573 Connection will use. A Preconnection can be fully specified and 574 represent a single possible Connection, or it can be partially 575 specified such that it represents a family of possible 576 Connections. The Local Endpoint (Section 4.1.2) MUST be specified 577 if the Preconnection is used to Listen for incoming connections. 578 The Local Endpoint is OPTIONAL if it is used to Initiate 579 connections. The Remote Endpoint MUST be specified in the 580 Preconnection is used to Initiate connections. The Remote 581 Endpoint is OPTIONAL if it is used to Listen for incoming 582 connections. The Local Endpoint and the Remote Endpoint MUST both 583 be specified if a peer-to-peer Rendezvous is to occur based on the 584 Preconnection. 586 * Transport Properties: Transport Properties can be specified as 587 part of a Preconnection to allow the application to configure 588 the Transport System and express their requirements, 589 prohibitions, and preferences. There are three kinds of 590 Transport Properties: Selection Properties (Section 4.1.2), 591 Connection Properties (Section 4.1.2), and Message Properties 592 (Section 4.1.4). Message Properties can also be specified 593 during data transfer to affect specific Messages. 595 o Connection: A Connection object represents one or more active 596 transport protocol instances that can send and/or receive Messages 597 between local and remote systems. It holds state pertaining to 598 the underlying transport protocol instances and any ongoing data 599 transfers. This represents, for example, an active connection in 600 a connection-oriented protocol such as TCP, or a fully-specified 601 5-tuple for a connectionless protocol such as UDP. It can also 602 represent a pool of transport protocol instance, e.g., a set of 603 TCP and QUIC connections to equivalent endpoints, or a stream of a 604 multi-streaming transport protocol instance. 606 o Listener: A Listener object accepts incoming transport protocol 607 connections from remote systems and generates corresponding 608 Connection objects. It is created from a Preconnection object 609 that specifies the type of incoming connections it will accept. 611 4.1.2. Pre-Establishment 613 o Endpoint: An Endpoint represents an identifier for one side of a 614 transport connection. Endpoints can be Local Endpoints or Remote 615 Endpoints, and respectively represent an identity that the 616 application uses for the source or destination of a connection. 617 An Endpoint can be specified at various levels, and an Endpoint 618 with wider scope (such as a hostname) can be resolved to more 619 concrete identities (such as IP addresses). 621 o Remote Endpoint: The Remote Endpoint represents the application's 622 identifier for a peer that can participate in a transport 623 connection. For example, the combination of a DNS name for the 624 peer and a service name/port. 626 o Local Endpoint: The Local Endpoint represents the application's 627 identifier for itself that it uses for transport connections. For 628 example, a local IP address and port. 630 o Selection Properties: The Selection Properties consist of the 631 options that an application can set to influence the selection of 632 paths between the local and remote systems, to influence the 633 selection of transport protocols, or to configure the behavior of 634 generic transport protocol features. These options can take the 635 form of requirements, prohibitions, or preferences. Examples of 636 options that influence path selection include the interface type 637 (such as a Wi-Fi Ethernet connection, or a Cellular LTE 638 connection), requirements around the Maximum Transmission Unit 639 (MTU) or path MTU (PMTU), or preferences for throughput and 640 latency properties. Examples of options that influence protocol 641 selection and configuration of transport protocol features include 642 reliability, service class, multipath support, and fast open 643 support. 645 o Connection Properties: The Connection Properties are used to 646 configure protocol-specific options and control per-connection 647 behavior of the Transport System. For example, a protocol- 648 specific Connection Property can express that if UDP is used, the 649 implementation ought to use checksums. Note that the presence of 650 such a property does not require that a specific protocol will be 651 used. In general, these properties do not explicitly determine 652 the selection of paths or protocols, but MAY be used in this way 653 by an implementation during connection establishment. Connection 654 Properties SHOULD be specified on a Preconnection prior to 655 Connection establishment, but MAY be modified later. Changes made 656 to Connection Properties after establishment take effect on a 657 best-effort basis. 659 4.1.3. Establishment Actions 661 o Initiate: The primary action that an application can take to 662 create a Connection to a Remote Endpoint, and prepare any required 663 local or remote state to be able to send and/or receive Messages. 664 For some protocols, this will initiate a client-to-server style 665 handshake; for other protocols, this will just establish local 666 state. The process of identifying options for connecting, such as 667 resolution of the Remote Endpoint, occurs in response the Initiate 668 call. 670 o Listen: The action of marking a Listener as willing to accept 671 incoming Connections. The Listener will then create Connection 672 objects as incoming connections are accepted (Section 4.1.5). 674 o Rendezvous: The action of establishing a peer-to-peer connection 675 with a Remote Endpoint. It simultaneously attempts to initiate a 676 connection to a Remote Endpoint whilst listening for an incoming 677 connection from that endpoint. This corresponds, for example, to 678 a TCP simultaneous open [RFC0793]. The process of identifying 679 options for the connection, such as resolution of the Remote 680 Endpoint, occurs during the Rendezvous call. If successful, the 681 rendezvous call returns a Connection object to represent the 682 established peer-to-peer connection. 684 4.1.4. Data Transfer Objects and Actions 686 o Message: A Message object is a unit of data that can be 687 represented as bytes that can be transferred between two systems 688 over a transport connection. The bytes within a Message are 689 assumed to be ordered within the Message. If an application does 690 not care about the order in which a peer receives two distinct 691 spans of bytes, those spans of bytes are considered independent 692 Messages. If a received Message is incomplete or corrupted, it 693 might or might not be usable by certain applications. Boundaries 694 of a Message might or might not be understood or transmitted by 695 transport protocols. Specifically, what one application considers 696 to be two Messages sent on a stream-based transport can be treated 697 as a single Message by the application on the other side. 699 o Message Properties: Message Properties can be used to annotate 700 specific Messages. These properties can specify how the transport 701 will send the Message (for prioritization and reliability), along 702 with any per-protocol properties to send with the Message. 703 Message Properties MAY be set on a Preconnection to define 704 defaults properties for sending. When receiving Messages, Message 705 Properties can contain per-protocol properties. 707 o Send: The action to transmit a Message or partial Message over a 708 Connection to the remote system. The interface to Send MAY 709 include Message Properties specific to how the Message's content 710 is to be sent. Status of the Send operation can be delivered back 711 to the application in an event (Section 4.1.5). 713 o Receive: An action that indicates that the application is ready to 714 asynchronously accept a Message over a Connection from a remote 715 system, while the Message content itself will be delivered in an 716 event (Section 4.1.5). The interface to Receive MAY include 717 Message Properties specific to the Message that is to be delivered 718 to the application. 720 o Framer: A Framer is a data translation layer that can be added to 721 a Connection to define how application-level Messages are 722 transmitted over a transport protocol. This is particularly 723 relevant for protocols that otherwise present unstructured 724 streams, such as TCP. 726 4.1.5. Event Handling 728 This list of events that can be delivered to an application is not 729 exhaustive, but gives the top-level categories of events. The API 730 MAY expand this list. 732 o Connection Ready: Signals to an application that a given 733 Connection is ready to send and/or receive Messages. If the 734 Connection relies on handshakes to establish state between peers, 735 then it is assumed that these steps have been taken. 737 o Connection Finished: Signals to an application that a given 738 Connection is no longer usable for sending or receiving Messages. 739 The event SHOULD deliver a reason or error to the application that 740 describes the nature of the termination. 742 o Connection Received: Signals to an application that a given 743 Listener has passively received a Connection. 745 o Message Received: Delivers received Message content to the 746 application, based on a Receive action. This MAY include an error 747 if the Receive action cannot be satisfied due to the Connection 748 being closed. 750 o Message Sent: Notifies the application of the status of its Send 751 action. This might indicate a failure if the Message cannot be 752 sent, or an indication that Message has been processed by the 753 protocol stack. 755 o Path Properties Changed: Notifies the application that some 756 property of the Connection has changed that might influence how 757 and where data is sent and/or received. 759 4.1.6. Termination Actions 761 o Close: The action an application takes on a Connection to indicate 762 that it no longer intends to send data, is no longer willing to 763 receive data, and that the protocol SHOULD signal this state to 764 the remote system if the transport protocol allows this. 766 o Abort: The action the application takes on a Connection to 767 indicate a Close and also indicate that the transport system 768 SHOULD NOT attempt to deliver any outstanding data. 770 4.2. Transport System Implementation Concepts 772 The Transport System Implementation Concepts define the set of 773 objects used internally to a system or library to implement the 774 functionality needed to provide a transport service across a network, 775 as required by the abstract interface. 777 o Connection Group: A set of Connections that share properties and 778 caches. For multiplexing transport protocols, only Connections 779 within the same Connection Group are allowed be multiplexed 780 together. Applications can use their explicitly defined 781 Connection Groups to control caching boundaries, as discussed in 782 Section 4.2.4. 784 o Path: Represents an available set of properties that a local 785 system can use to communicate with a remote system, such as 786 routes, addresses, and physical and virtual network interfaces. 788 o Protocol Instance: A single instance of one protocol, including 789 any state it has necessary to establish connectivity or send and 790 receive Messages. 792 o Protocol Stack: A set of Protocol Instances (including relevant 793 application, security, transport, or Internet protocols) that are 794 used together to establish connectivity or send and receive 795 Messages. A single stack can be simple (a single transport 796 protocol instance over IP), or complex (multiple application 797 protocol streams going through a single security and transport 798 protocol, over IP; or, a multi-path transport protocol over 799 multiple transport sub-flows). 801 o Candidate Path: One path that is available to an application and 802 conforms to the Selection Properties and System Policy. Candidate 803 Paths are identified during the gathering phase (Section 4.2.1) 804 and can be used during the racing phase (Section 4.2.2). 806 o Candidate Protocol Stack: One protocol stack that can be used by 807 an application for a connection, of which there can be several. 808 Candidate Protocol Stacks are identified during the gathering 809 phase (Section 4.2.1) and are started during the racing phase 810 (Section 4.2.2). 812 o System Policy: Represents the input from an operating system or 813 other global preferences that can constrain or influence how an 814 implementation will gather candidate paths and protocol stacks 815 (Section 4.2.1) and race the candidates during establishment 816 (Section 4.2.2). Specific aspects of the System Policy either 817 apply to all Connections or only certain ones, depending on the 818 runtime context and properties of the Connection. 820 o Cached State: The state and history that the implementation keeps 821 for each set of associated Endpoints that have been used 822 previously. This can include DNS results, TLS session state, 823 previous success and quality of transport protocols over certain 824 paths. 826 4.2.1. Candidate Gathering 828 o Path Selection: Path Selection represents the act of choosing one 829 or more paths that are available to use based on the Selection 830 Properties provided by the application, the policies and 831 heuristics of a Transport Services system. 833 o Protocol Selection: Protocol Selection represents the act of 834 choosing one or more sets of protocol options that are available 835 to use based on the Transport Properties provided by the 836 application, and a Transport Services system's policies and 837 heuristics. 839 4.2.2. Candidate Racing 841 o Protocol Option Racing: Protocol Racing is the act of attempting 842 to establish, or scheduling attempts to establish, multiple 843 Protocol Stacks that differ based on the composition of protocols 844 or the options used for protocols. 846 o Path Racing: Path Racing is the act of attempting to establish, or 847 scheduling attempts to establish, multiple Protocol Stacks that 848 differ based on a selection from the available Paths. Since 849 different Paths will have distinct configurations for local 850 addresses and DNS servers, attempts across different Paths will 851 perform separate DNS resolution stepss, which can lead to further 852 racing of the resolved Remote Endpoints. 854 o Remote Endpoint Racing: Remote Endpoint Racing is the act of 855 attempting to establish, or scheduling attempts to establish, 856 multiple Protocol Stacks that differ based on the specific 857 representation of the Remote Endpoint, such as IP addresses 858 resolved from a DNS hostname. 860 4.2.3. Protocol Stack Equivalence 862 The Transport Services architecture defines a mechanism that allows 863 applications to easily use different network paths and Protocol 864 Stacks. Transitioning between different Protocol Stacks is in some 865 cases controlled by properties that only change when application code 866 is updated. For example, an application can enable the use of a 867 multipath or multistreaming transport protocol by modifying the 868 properties in its Pre-Connection configuration. In some cases, 869 however, the Transport Services system will be able to automatically 870 change Protocol Stacks without an update to the application, either 871 by selecting a new stack entirely, or by racing multiple candidate 872 Protocol Stacks during connection establishment. This functionality 873 can be a powerful driver of new protocol adoption, but needs to be 874 constrained carefully to avoid unexpected behavior that can lead to 875 functional or security problems. 877 If two different Protocol Stacks can be safely swapped, or raced in 878 parallel (see Section 4.2.2), then they are considered to be 879 "equivalent". Equivalent Protocol Stacks need to meet the following 880 criteria: 882 1. Both stacks MUST offer the same interface to the application for 883 connection establishment and data transmission. For example, if 884 one Protocol Stack has UDP as the top-level interface to the 885 application, then it is not equivalent to a Protocol Stack that 886 runs TCP as the top-level interface. Among other differences, 887 the UDP stack would allow an application to read out message 888 boundaries based on datagrams sent from the remote system, 889 whereas TCP does not preserve message boundaries on its own. 891 2. Both stacks MUST offer the same transport services, as required 892 by the application. For example, if an application specifies 893 that it requires reliable transmission of data, then a Protocol 894 Stack using UDP without any reliability layer on top would not be 895 allowed to replace a Protocol Stack using TCP. However, if the 896 application does not require reliability, then a Protocol Stack 897 that adds unnecessary reliability might be allowed as an 898 equivalent Protocol Stack as long as it does not conflict with 899 any other application-requested properties. 901 3. Both stacks MUST offer the same security properties. The 902 inclusion of transport security protocols 903 [I-D.ietf-taps-transport-security] in a Protocol Stack adds 904 additional restrictions to Protocol Stack equivalence. Security 905 features and properties, such as cryptographic algorithms, peer 906 authentication, and identity privacy vary across security 907 protocols, and across versions of security protocols. Protocol 908 equivalence ought not to be assumed for different protocols or 909 protocol versions, even if they offer similar application 910 configuration options. To ensure that security protocols are not 911 incorrectly swapped, Transport Services systems SHOULD only 912 automatically generate equivalent Protocol Stacks when the 913 transport security protocols within the stacks are identical. 914 Specifically, a transport system would consider protocols 915 identical only if they are of the same type and version. For 916 example, the same version of TLS running over two different 917 transport protocol stacks are considered equivalent, whereas TLS 918 1.2 and TLS 1.3 [RFC8446] are not considered equivalent. 920 4.2.4. Separating Connection Groups 922 By default, all stored properties of the Implementation are shared 923 within a process, such as cached protocol state, cached path state, 924 and heuristics. This provides efficiency and convenience for the 925 application, since the Transport System Implementation can 926 automatically optimize behavior. 928 There are several reasons, however, that an application might want to 929 isolate some Connections within a single process. These reasons 930 include: 932 o Privacy concerns about re-using cached protocol state that can 933 lead to linkability. Sensitive state may include TLS session 934 state [RFC8446] and HTTP cookies [RFC6265]. 936 o Privacy concerns about allowing Connections to multiplex together, 937 which can tell a Remote Endpoint that all of the Connections are 938 coming from the same application (for example, when Connections 939 are multiplexed HTTP/2 or QUIC streams). 941 o Performance concerns about Connections introducing head-of-line 942 blocking due to multiplexing or needing to share state on a single 943 thread. 945 The Transport Services API SHOULD allow applications to explicitly 946 define Connection Groups that force separation of Cached State and 947 Protocol Stacks. For example, a web browser application might use 948 Connection Groups with separate caches for different tabs in the 949 browser to decrease linkability. 951 The interface to specify these Groups MAY expose fine-grained tuning 952 for which properties and cached state is allowed to be shared with 953 other Connections. For example, an application might want to allow 954 sharing TCP Fast Open cookies across groups, but not TLS session 955 state. 957 5. IANA Considerations 959 RFC-EDITOR: Please remove this section before publication. 961 This document has no actions for IANA. 963 6. Security Considerations 965 The Transport Services architecture does not recommend use of 966 specific security protocols or algorithms. Its goal is to offer ease 967 of use for existing protocols by providing a generic security-related 968 interface. Each provided interface translates to an existing 969 protocol-specific interface provided by supported security protocols. 970 For example, trust verification callbacks are common parts of TLS 971 APIs. Transport Services APIs will expose similar functionality 972 [I-D.ietf-taps-transport-security]. 974 As described above in Section 4.2.3, if a Transport Services system 975 races between two different Protocol Stacks, both MUST use the same 976 security protocols and options. 978 Clients need to ensure that security APIs are used appropriately. In 979 cases where clients use an interface to provide sensitive keying 980 material, e.g., access to private keys or copies of pre-shared keys 981 (PSKs), key use needs to be validated. For example, clients ought 982 not to use PSK material created for the Encapsulating Security 983 Protocol (ESP, part of IPsec) [RFC4303] with QUIC, and clients ought 984 not to use private keys intended for server authentication as a keys 985 for client authentication. 987 Moreover, unlike certain transport features such as TCP Fast Open 988 (TFO) [RFC7413] or Explicit Congestion Notification (ECN) [RFC3168] 989 which can fall back to standard configurations, Transport Services 990 systems MUST prohibit fallback for security protocols. For example, 991 if a client requests TLS, yet TLS or the desired version are not 992 available, its connection will fail. Clients are thus responsible 993 for implementing security protocol fallback or version fallback by 994 creating multiple Transport Services Connections, if so desired. 996 7. Acknowledgements 998 This work has received funding from the European Union's Horizon 2020 999 research and innovation programme under grant agreements No. 644334 1000 (NEAT) and No. 688421 (MAMI). 1002 This work has been supported by Leibniz Prize project funds of DFG - 1003 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 1004 FE 570/4-1). 1006 This work has been supported by the UK Engineering and Physical 1007 Sciences Research Council under grant EP/R04144X/1. 1009 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 1010 Kinnear for their implementation and design efforts, including Happy 1011 Eyeballs, that heavily influenced this work. 1013 8. Informative References 1015 [I-D.ietf-taps-impl] 1016 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 1017 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 1018 "Implementing Interfaces to Transport Services", draft- 1019 ietf-taps-impl-03 (work in progress), March 2019. 1021 [I-D.ietf-taps-interface] 1022 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1023 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 1024 Abstract Application Layer Interface to Transport 1025 Services", draft-ietf-taps-interface-03 (work in 1026 progress), March 2019. 1028 [I-D.ietf-taps-minset] 1029 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 1030 Services for End Systems", draft-ietf-taps-minset-11 (work 1031 in progress), September 2018. 1033 [I-D.ietf-taps-transport-security] 1034 Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. 1035 Rose, "A Survey of Transport Security Protocols", draft- 1036 ietf-taps-transport-security-06 (work in progress), March 1037 2019. 1039 [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology 1040 -- Portable Operating System Interface (POSIX). Open 1041 group Technical Standard: Base Specifications, Issue 7", 1042 n.d.. 1044 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1045 RFC 793, DOI 10.17487/RFC0793, September 1981, 1046 . 1048 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1049 Requirement Levels", BCP 14, RFC 2119, 1050 DOI 10.17487/RFC2119, March 1997, 1051 . 1053 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1054 of Explicit Congestion Notification (ECN) to IP", 1055 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1056 . 1058 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1059 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1060 . 1062 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1063 DOI 10.17487/RFC6265, April 2011, 1064 . 1066 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1067 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1068 . 1070 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1071 Ed., "Services Provided by IETF Transport Protocols and 1072 Congestion Control Mechanisms", RFC 8095, 1073 DOI 10.17487/RFC8095, March 2017, 1074 . 1076 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1077 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1078 May 2017, . 1080 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1081 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1082 . 1084 Authors' Addresses 1086 Tommy Pauly (editor) 1087 Apple Inc. 1088 One Apple Park Way 1089 Cupertino, California 95014 1090 United States of America 1092 Email: tpauly@apple.com 1094 Brian Trammell (editor) 1095 Google 1096 Gustav-Gull-Platz 1 1097 8004 Zurich 1098 Switzerland 1100 Email: ietf@trammell.ch 1101 Anna Brunstrom 1102 Karlstad University 1103 Universitetsgatan 2 1104 651 88 Karlstad 1105 Sweden 1107 Email: anna.brunstrom@kau.se 1109 Godred Fairhurst 1110 University of Aberdeen 1111 Fraser Noble Building 1112 Aberdeen, AB24 3UE 1113 Scotland 1115 Email: gorry@erg.abdn.ac.uk 1116 URI: http://www.erg.abdn.ac.uk/ 1118 Colin Perkins 1119 University of Glasgow 1120 School of Computing Science 1121 Glasgow G12 8QQ 1122 United Kingdom 1124 Email: csp@csperkins.org 1126 Philipp S. Tiesel 1127 TU Berlin 1128 Einsteinufer 25 1129 10587 Berlin 1130 Germany 1132 Email: philipp@tiesel.net 1134 Chris Wood 1135 Apple Inc. 1136 One Apple Park Way 1137 Cupertino, California 95014 1138 United States of America 1140 Email: cawood@apple.com