idnits 2.17.1 draft-ietf-taps-arch-01.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 01, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-taps-impl-00 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-00 == Outdated reference: A later version (-11) exists of draft-ietf-taps-minset-04 == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-02 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 5 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: Informational B. Trammell, Ed. 5 Expires: January 2, 2019 ETH Zurich 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 01, 2018 18 An Architecture for Transport Services 19 draft-ietf-taps-arch-01 21 Abstract 23 This document provides an overview of the architecture of Transport 24 Services, a system for exposing the features of transport protocols 25 to applications. This architecture serves as a basis for Application 26 Programming Interfaces (APIs) and implementations that provide 27 flexible transport networking services. It defines the common set of 28 terminology and concepts to be used in more detailed discussion of 29 Transport Services. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 2, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Common APIs for Common Features . . . . . . . . . . . . . 4 69 3.2. Access to Specialized Features . . . . . . . . . . . . . 4 70 3.3. Scope for API and Implementation Definitions . . . . . . 5 71 4. Transport Services Architecture and Concepts . . . . . . . . 6 72 4.1. Transport Services API Concepts . . . . . . . . . . . . . 7 73 4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 9 74 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 10 75 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 11 76 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 11 77 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 12 78 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 13 79 4.2. Transport System Implementation Concepts . . . . . . . . 13 80 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 14 81 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 14 82 4.3. Protocol Stack Equivalence . . . . . . . . . . . . . . . 15 83 4.3.1. Transport Security Equivalence . . . . . . . . . . . 16 84 4.4. Message Framing, Parsing, and Serialization . . . . . . . 16 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 88 8. Informative References . . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Many APIs to perform transport networking have been deployed, perhaps 94 the most widely known and imitated being the BSD socket() [POSIX] 95 interface. The names and functions between these APIs are not 96 consistent, and vary depending on the protocol being used. For 97 example, sending and receiving on a stream of data is conceptually 98 the same between operating on an unencrypted Transmission Control 99 Protocol (TCP) stream and operating on an encrypted Transport Layer 100 Security (TLS) [I-D.ietf-tls-tls13] stream over TCP, but applications 101 cannot use the same socket send() and recv() calls on top of both 102 kinds of connections. Similarly, terminology for the implementation 103 of protocols offering transport services vary based on the context of 104 the protocols themselves. This variety can lead to confusion when 105 trying to understand the similarities and differences between 106 protocols, and how applications can use them effectively. 108 The goal of the Transport Services architecture is to provide a 109 common, flexible, and reusable interface for transport protocols. As 110 applications adopt this interface, they will benefit from a wide set 111 of transport features that can evolve over time, and ensure that the 112 system providing the interface can optimize its behavior based on the 113 application requirements and network conditions. 115 This document is developed in parallel with the specification of the 116 Transport Services API [I-D.ietf-taps-interface] and Implementation 117 [I-D.ietf-taps-impl] documents. 119 2. Background 121 The Transport Services architecture is based on the survey of 122 Services Provided by IETF Transport Protocols and Congestion Control 123 Mechanisms [RFC8095], and the distilled minimal set of the features 124 offered by transport protocols [I-D.ietf-taps-minset]. This work has 125 identified common features and patterns across all transport 126 protocols developed thus far in the IETF. 128 Since transport security is an increasingly relevant aspect of using 129 transport protocols on the Internet, this architecture also considers 130 the impact of transport security protocols on the feature set exposed 131 by transport services [I-D.ietf-taps-transport-security]. 133 One of the key insights to come from identifying the minimal set of 134 features provided by transport protocols [I-D.ietf-taps-minset] was 135 that features either require application interaction and guidance 136 (referred to as Functional Features), or else can be handled 137 automatically by a system implementing Transport Services (referred 138 to as Automatable Features). Among the Functional Features, some 139 were common across all or nearly all transport protocols, while 140 others could be seen as features that, if specified, would only be 141 useful with a subset of protocols, or perhaps even a single transport 142 protocol, but would not harm the functionality of other protocols. 143 For example, some protocols can deliver messages faster for 144 applications that do not require them to arrive in the order in which 145 they were sent. However, this functionality must be explicitly 146 allowed by the application, since reordering messages would be 147 undesirable in many cases. 149 3. Design Principles 151 The goal of the Transport Services architecture is to redefine the 152 interface between applications and transports in a way that allows 153 the transport layer to evolve and improve without fundamentally 154 changing the contract with the application. This requires a careful 155 consideration of how to expose the capabilities of protocols. 157 There are several degrees in which a Transport Services system can 158 offer flexibility to an application: it can provide access to 159 multiple sets of protocols and protocol features, it can use these 160 protocols across multiple paths that may have different performance 161 and functional characteristics, and it can communicate with different 162 Remote Endpoints to optimize performance. Beyond these, if the API 163 for the system remains the same over time, new protocols and features 164 may be added to the system's implementation without requiring changes 165 in applications for adoption. 167 The following considerations were used in the design of this 168 architecture. 170 3.1. Common APIs for Common Features 172 Functionality that is common across multiple transport protocols 173 should be accessible through a unified set of API calls. An 174 application should be able to implement logic for its basic use of 175 transport networking (establishing the transport, and sending and 176 receiving data) once, and expect that implementation to continue to 177 function as the transports change. 179 Any Transport Services API must allow access to the distilled minimal 180 set of features offered by transport protocols 181 [I-D.ietf-taps-minset]. 183 3.2. Access to Specialized Features 185 Since applications will often need to control fine-grained details of 186 transport protocols to optimize their behavior and ensure 187 compatibility with remote peers, a Transport Services system also 188 needs to allow more specialized protocol features to be used. The 189 interface for these specialized options should be exposed differently 190 from the common options to ensure flexibility. 192 A specialized feature may be required by an application only when 193 using a specific protocol, and not when using others. For example, 194 if an application is using UDP, it may require control over the 195 checksum or fragmentation behavior for UDP; if it used a protocol to 196 frame its data over a byte stream like TCP, it would not need these 197 options. In such cases, the API should expose the features in such a 198 way that they take effect when a particular protocol is selected, but 199 do not imply that only that protocol may be used if there are 200 equivalent options. 202 Other specialized features, however, may be strictly required by an 203 application and thus constrain the set of protocols that can be used. 204 For example, if an application requires encryption of its transport 205 data, only protocol stacks that include some transport security 206 protocol are eligible to be used. A Transport Services API must 207 allow applications to define such requirements and constrain the 208 system's options. Since such options are not part of the core/common 209 features, it should be simple for an application to modify its set of 210 constraints and change the set of allowable protocol features without 211 changing the core implementation. 213 3.3. Scope for API and Implementation Definitions 215 The Transport Services API is envisioned as the abstract model for a 216 family of APIs that share a common way to expose transport features 217 and encourage flexibility. The abstract API definition 218 [I-D.ietf-taps-interface] describes this interface and is aimed at 219 application developers. 221 Implementations that provide the Transport Services API 222 [I-D.ietf-taps-impl] will vary due to system-specific support and the 223 needs of the deployment scenario. It is expected that all 224 implementations of Transport Services will offer the entire mandatory 225 API, but that some features will not be functional in certain 226 implementations. All implementations must offer sufficient APIs to 227 use the distilled minimal set of features offered by transport 228 protocols [I-D.ietf-taps-minset], including API support for TCP and 229 UDP transport, but it is possible that some very constrained devices 230 might not have, for example, a full TCP implementation. 232 In order to preserve flexibility and compatibility with future 233 protocols, top-level features in the Transport Services API should 234 avoid referencing particular transport protocols. Mappings of these 235 API features in the Implementation document, on the other hand, must 236 explain the ramifications of each feature on existing protocols. It 237 is expected that the Implementation document will be updated and 238 supplemented as new protocols and protocol features are developed. 240 It is important to note that neither the Transport Services API nor 241 the Implementation document defines new protocols that require any 242 changes on remote hosts. The Transport Services system must be 243 deployable on one side only, as a way to allow an application to make 244 better use of available capabilities on a system and protocol 245 features that may be supported by peers across the network. 247 4. Transport Services Architecture and Concepts 249 The concepts defined in this document are intended primarily for use 250 in the documents and specifications that describe the Transport 251 Services architecture and API. While the specific terminology may be 252 used in some implementations, it is expected that there will remain a 253 variety of terms used by running code. 255 The architecture divides the concepts for Transport Services into two 256 categories: 258 1. API concepts, which are meant to be exposed to applications; and 260 2. System-implementation concepts, which are meant to be internally 261 used when building systems that implement Transport Services. 263 The following diagram summarizes the top-level concepts in the 264 architecture and how they relate to one another. 266 +-----------------------------------------------------+ 267 | Application | 268 +-+----------------+------^-------+--------^----------+ 269 | | | | | 270 pre- | data | events 271 establishment | transfer | | 272 | establishment | termination | 273 | | | | | 274 | +--v------v-------v+ | 275 +-v-------------+ Basic Objects +-------+----------+ 276 | Transport +--------+---------+ | 277 | Services | | 278 | API | | 279 +------------------------|----------------------------+ 280 | 281 +------------------------|----------------------------+ 282 | Transport | | 283 | System | +-----------------+ | 284 | Implementation | | Cached | | 285 | | | State | | 286 | (Candidate Gathering) | +-----------------+ | 287 | | | 288 | (Candidate Racing) | +-----------------+ | 289 | | | System | | 290 | | | Policy | | 291 | +----------v-----+ +-----------------+ | 292 | | Protocol | | 293 +-------------+ Stack(s) +----------------------+ 294 +-------+--------+ 295 V 296 Network Layer Interface 298 Figure 1: Concepts and Relationships in the Transport Services 299 Architecture 301 4.1. Transport Services API Concepts 303 Fundamentally, a Transport Services API needs to provide basic 304 objects (Section 4.1.1) that allow applications to establish 305 communication and send and receive data. These may be exposed as 306 handles or referenced objects, depending on the language. 308 Beyond the basic objects, there are several high-level groups of 309 actions that any Transport Services API must provide: 311 o Pre-Establishment (Section 4.1.2) encompasses the properties that 312 an application can pass to describe its intent, requirements, 313 prohibitions, and preferences for its networking operations. For 314 any system that provides generic Transport Services, these 315 properties should primarily be defined to apply to multiple 316 transports. Properties may have a large impact on the rest of the 317 aspects of the interface: they can modify how establishment 318 occurs, they can influence the expectations around data transfer, 319 and they determine the set of events that will be supported. 321 o Establishment (Section 4.1.3) focuses on the actions that an 322 application takes on the basic objects to prepare for data 323 transfer. 325 o Data Transfer (Section 4.1.4) consists of how an application 326 represents data to be sent and received, the functions required to 327 send and receive that data, and how the application is notified of 328 the status of its data transfer. 330 o Event Handling (Section 4.1.5) defines the set of properties about 331 which an application can receive notifications during the lifetime 332 of transport objects. Events can also provide opportunities for 333 the application to interact with the underlying transport by 334 querying state or updating maintenance options. 336 o Termination (Section 4.1.6) focuses on the methods by which data 337 transmission is stopped, and state is torn down in the transport. 339 The diagram below provides a high-level view of the actions taken 340 during the lifetime of a connection. 342 Pre-Establishment : Established : Termination 343 ----------------- : ----------- : ----------- 344 : Close() : 345 +---------------+ Initiate() +------------+ Abort() : 346 +-->| Preconnection |----------->| Connection |---------------> Closed 347 | +---------------+ : +------------+ Connection: 348 | : ^ ^ | Finished : 349 +-- Local Endpoint : | | | : 350 | : | | +---------+ : 351 +-- Remote Endpoint : | | | : 352 | : | |Send() | : 353 +-- Path Selection : | +---------+ v : 354 | Properties : | | Message | Message : 355 | : | | to send | Received : 356 +-- Protocol Selection : | +---------+ : 357 | Properties : | : 358 | : | : 359 +-- Specific Protocol : | : 360 | Properties : | : 361 | : | : 362 | +----------+ : | : 363 +-->| Listener |-----------------+ : 364 +----------+ Connection Received : 365 ^ : : 366 | : : 367 Listen() : : 369 Figure 2: The lifetime of a connection 371 4.1.1. Basic Objects 373 o Preconnection: A Preconnection object is a representation of a 374 potential connection. It has state that describes parameters of a 375 Connection that might exist in the future: the Local Endpoint from 376 which that Connection will be established, the Remote Endpoint to 377 which it will connect, and Path Selection Properties, Protocol 378 Selection Properties, and Specific Protocol Properties that 379 influence the choice of transport that a Connection will use. A 380 Preconnection can be fully specified and represent a single 381 possible Connection, or it can be partially specified such that it 382 represents a family of possible Connections. The Local Endpoint 383 must be specified if the Preconnection is used to Listen for 384 incoming connections, but is optional if it is used to Initiate 385 connections. The Remote Endpoint must be specified in the 386 Preconnection is used to Initiate connections, but is optional if 387 it is used to Listen for incoming connections. The Local Endpoint 388 and the Remote Endpoint must both be specified if a peer-to-peer 389 Rendezvous is to occur based on the Preconnection. 391 o Connection: A Connection object represents an active transport 392 protocol instance that can send and/or receive Messages between a 393 Local Endpoint and a Remote Endpoint. It holds state pertaining 394 to the underlying transport protocol instance and any ongoing data 395 transfer. This represents, for example, an active connection in a 396 connection-oriented protocol such as TCP, or a fully-specified 397 5-tuple for a connectionless protocol such as UDP. 399 o Listener: A Listener object accepts incoming transport protocol 400 connections from Remote Endpoints and generates corresponding 401 Connection objects. It is created from a Preconnection object 402 that specifies the type of incoming connections it will accept. 404 4.1.2. Pre-Establishment 406 o Endpoint: An Endpoint represents one side of a transport 407 connection. Endpoints can be Local Endpoints or Remote Endpoints, 408 and respectively represent an identity that the application uses 409 for the source or destination of a connection. An Endpoint may be 410 specified at various levels, and an Endpoint with wider scope 411 (such as a hostname) can be resolved to more concrete identities 412 (such as IP addresses). 414 o Remote Endpoint: The Remote Endpoint represents the application's 415 name for a peer that can participate in a transport connection. 416 For example, the combination of a DNS name for the peer and a 417 service name/port. 419 o Local Endpoint: The Local Endpoint represents the application's 420 name for itself that it uses for transport connections. For 421 example, a local IP address and port. 423 o Path Selection Properties: The Path Selection Properties consist 424 of the options that an application may set to influence the 425 selection of paths between the Local Endpoint and the Remote 426 Endpoint. These options can take the form of requirements, 427 prohibitions, or preferences. Examples of options that may 428 influence path selection include the interface type (such as a Wi- 429 Fi Ethernet connection, or a Cellular LTE connection), 430 characteristics of the path that are locally known like Maximum 431 Transmission Unit (MTU) or discovered like Path MTU (PMTU), or 432 predicted based on cached information like expected throughput or 433 latency. 435 o Protocol Selection Properties: The Protocol Selection Properties 436 consist of the options that an application may set to influence 437 the selection of transport protocol, or to configure the behavior 438 of generic transport protocol features. These options can take 439 the form of requirements, prohibitions, and preferences. Examples 440 include reliability, service class, multipath support, and fast 441 open support. 443 o Specific Protocol Properties: The Specific Protocol Properties 444 refer to the subset of Protocol Properties options that apply to a 445 single protocol (transport protocol, IP, or security protocol). 446 The presence of such Properties does not necessarily require that 447 a specific protocol must be used when a Connection is established, 448 but that if this protocol is employed, a particular set of options 449 should then be used.. 451 4.1.3. Establishment Actions 453 o Initiate: The primary action that an application can take to 454 create a Connection to a Remote Endpoint, and prepare any required 455 local or remote state to be able to send and/or receive Messages. 456 For some protocols, this may initiate a client-to-server style 457 handshake; for other protocols, this may just establish local 458 state. The process of identifying options for connecting, such as 459 resolution of the Remote Endpoint, occurs in response the Initiate 460 call. 462 o Listen: The action of marking a Listener as willing to accept 463 incoming Connections. The Listener will then create Connection 464 objects as incoming connections are accepted (Section 4.1.5). 466 o Rendezvous: The action of establishing a peer-to-peer connection 467 with a Remote Endpoint. It simultaneously attempts to initiate a 468 connection to a Remote Endpoint whilst listening for an incoming 469 connection from that endpoint. This corresponds, for example, to 470 a TCP simultaneous open [RFC0793]. The process of identifying 471 options for the connection, such as resolution of the Remote 472 Endpoint, occurs during the Rendezvous call. If successful, the 473 rendezvous call returns a Connection object to represent the 474 established peer-to-peer connection. 476 4.1.4. Data Transfer Objects and Actions 478 o Message: A Message object is a unit of data that can be 479 represented as bytes that can be transferred between two endpoints 480 over a transport connection. The bytes within a Message are 481 assumed to be ordered within the Message. If an application does 482 not care about the order in which a peer receives two distinct 483 spans of bytes, those spans of bytes are considered independent 484 Messages. If a received Message is incomplete or corrupted, it 485 may or may not be usable by certain applications. Boundaries of a 486 Message may or may not be understood or transmitted by transport 487 protocols. Specifically, what one application considers to be two 488 Messages sent on a stream-based transport may be treated as a 489 single Message by the application on the other side. 491 o Send: The action to transmit a Message or partial Message over a 492 Connection to a Remote Endpoint. The interface to Send may 493 include options specific to how the Message's content is to be 494 sent. Status of the Send operation may be delivered back to the 495 application in an event (Section 4.1.5). 497 o Receive: An action that indicates that the application is ready to 498 asynchronously accept a Message over a Connection from a Remote 499 Endpoint, while the Message content itself will be delivered in an 500 event (Section 4.1.5). The interface to Receive may include 501 options specific to the Message that is to be delivered to the 502 application. 504 4.1.5. Event Handling 506 This list of events that can be delivered to an application is not 507 exhaustive, but gives the top-level categories of events. The API 508 may expand this list. 510 o Connection Ready: Signals to an application that a given 511 Connection is ready to send and/or receive Messages. If the 512 Connection relies on handshakes to establish state between peers, 513 then it is assumed that these steps have been taken. 515 o Connection Finished: Signals to an application that a given 516 Connection is no longer usable for sending or receiving Messages. 517 This should deliver an error to the application that describes the 518 nature of the termination. 520 o Connection Received: Signals to an application that a given 521 Listener has passively received a Connection. 523 o Message Received: Delivers received Message content to the 524 application, based on a Receive action. This may include an error 525 if the Receive action cannot be satisfied due to the Connection 526 being closed. 528 o Message Sent: Notifies the application of the status of its Send 529 action. This may be an error if the Message cannot be sent, or an 530 indication that Message has been processed by the protocol stack. 532 o Path Properties Changed: Notifies the application that some 533 property of the Connection has changed that may influence how and 534 where data is sent and/or received. 536 4.1.6. Termination Actions 538 o Close: The action an application may take on a Connection to 539 indicate that it no longer intends to send data, is no longer 540 willing to receive data, and that the protocol should signal this 541 state to the remote endpoint if applicable. 543 o Abort: The action the application may take on a Connection to 544 indicate a Close, but with the additional indication that the 545 transport system should not attempt to deliver any outstanding 546 data. 548 4.2. Transport System Implementation Concepts 550 The Transport System Implementation Concepts define the set of 551 objects used internally to a system or library to provide the 552 functionality required to provide a transport service across a 553 network, as required by the abstract interface. 555 o Connection Group: A set of Connections that share properties. For 556 multiplexing transport protocols, the Connection Group defines the 557 set of Connections that can be multiplexed together. 559 o Path: Represents an available set of properties that a Local 560 Endpoint may use to send or receive packets with a Remote 561 Endpoint. 563 o Protocol Instance: A single instance of one protocol, including 564 any state it has necessary to establish connectivity or send and 565 receive Messages. 567 o Protocol Stack: A set of Protocol Instances (including relevant 568 application, security, transport, or Internet protocols) that are 569 used together to establish connectivity or send and receive 570 Messages. A single stack may be simple (a single transport 571 protocol instance over IP), or complex (multiple application 572 protocol streams going through a single security and transport 573 protocol, over IP; or, a multi-path transport protocol over 574 multiple transport sub-flows). 576 o Candidate Path: One path that is available to an application and 577 conforms to the Path Selection Properties and System Policy. 578 Candidate Paths are identified during the gathering phase 579 (Section 4.2.1) and may be used during the racing phase 580 (Section 4.2.2). 582 o Candidate Protocol Stack: One protocol stack that may be used by 583 an application for a connection, of which there may be several. 585 Candidate Protocol Stacks are identified during the gathering 586 phase (Section 4.2.1) and may be started during the racing phase 587 (Section 4.2.2). 589 o System Policy: Represents the input from an operating system or 590 other global preferences that can constrain or influence how an 591 implementation will gather candidate paths and protocol stacks 592 (Section 4.2.1) and race the candidates during establishment 593 (Section 4.2.2). Specific aspects of the System Policy may apply 594 to all Connections, or only certain ones depending on the runtime 595 context and properties of the Connection. 597 o Cached State: The state and history that the implementation keeps 598 for each set of associated endpoints that have been used 599 previously. This can include DNS results, TLS session state, 600 previous success and quality of transport protocols over certain 601 paths. 603 4.2.1. Candidate Gathering 605 o Path Selection: Path Selection represents the act of choosing one 606 or more paths that are available to use based on the Path 607 Selection Properties provided by the application, and a Transport 608 Services system's policies and heuristics. 610 o Protocol Selection: Protocol Selection represents the act of 611 choosing one or more sets of protocol options that are available 612 to use based on the Protocol Properties provided by the 613 application, and a Transport Services system's policies and 614 heuristics. 616 4.2.2. Candidate Racing 618 o Protocol Option Racing: Protocol Racing is the act of attempting 619 to establish, or scheduling attempts to establish, multiple 620 Protocol Stacks that differ based on the composition of protocols 621 or the options used for protocols. 623 o Path Racing: Path Racing is the act of attempting to establish, or 624 scheduling attempts to establish, multiple Protocol Stacks that 625 differ based on a selection from the available Paths. 627 o Endpoint Racing: Endpoint Racing is the act of attempting to 628 establish, or scheduling attempts to establish, multiple Protocol 629 Stacks that differ based on the specific representation of the 630 Remote Endpoint and the Local Endpoint, such as IP addresses 631 resolved from a DNS hostname. 633 4.3. Protocol Stack Equivalence 635 The Transport Services architecture defines a mechanism that allows 636 applications to easily use different network paths and Protocol 637 Stacks. Transitioning between different Protocol Stacks may in some 638 cases be controlled by properties that only change when application 639 code is updated. For example, an application may enable the use of a 640 multipath or multistreaming transport protocol by modifying the 641 properties in its Pre-Connection configuration. In some cases, 642 however, the Transport Services system will be able to automatically 643 change Protocol Stacks without an update to the application, either 644 by selecting a new stack entirely, or racing multiple candidate 645 Protocol Stacks during connection establishment. This functionality 646 can be a powerful driver of new protocol adoption, but must be 647 constrained carefully to avoid unexpected behavior that can lead to 648 functional or security problems. 650 If two different Protocol Stacks can be safely swapped, or raced in 651 parallel (see Section 4.2.2), then they are considered to be 652 "equivalent". Equivalent Protocol Stacks must meet the following 653 criteria: 655 1. Both stacks must offer the same interface to the application for 656 connection establishment and data transmission. For example, if 657 one Protocol Stack has UDP as the top-level interface to the 658 application, then it is not equivalent to a Protocol Stack that 659 runs TCP as the top-level interface. Among other differences, 660 the UDP stack would allow an application to read out message 661 boundaries based on datagrams sent from the Remote Endpoint, 662 whereas TCP does not preserve message boundaries on its own. 664 2. Both stacks must offer the same transport services, as required 665 by the application. For example, if an application specifies 666 that it requires reliable transmission of data, then a Protocol 667 Stack using UDP without any reliability layer on top would not be 668 allowed to replace a Protocol Stack using TCP. However, if the 669 application does not require reliability, then a Protocol Stack 670 that adds unnecessary reliability might be allowed as an 671 equivalent Protocol Stack as long as it does not conflict with 672 any other application-requested properties. 674 3. Both stacks must offer the same security properties. See the 675 security protocol equivalence section below for futher discussion 676 (Section 4.3.1). 678 4.3.1. Transport Security Equivalence 680 The inclusion of transport security protocols 681 [I-D.ietf-taps-transport-security] in a Protocol Stack adds extra 682 restrictions to Protocol Stack equivalence. Security features and 683 properties, such as cryptographic algorithms, peer authentication, 684 and identity privacy vary across security protocols, and across 685 versions of security protocols. Protocol equivalence should not be 686 assumed for different protocols or protocol versions, even if they 687 offer similar application configuration options. 689 To ensure that security protocols are not incorrectly swapped, 690 Transport Services systems should only automatically generate 691 equivalent Protocol Stacks when the transport security protocols 692 within the stacks are identical. Specifically, a system should 693 consider protocols identical only if they are of the same type and 694 version. For example, the same version of TLS running over two 695 different transport protocol stacks may be considered equivalent, 696 whereas TLS 1.2 and TLS 1.3 [I-D.ietf-tls-tls13] should not be 697 considered equivalent. 699 4.4. Message Framing, Parsing, and Serialization 701 While some transports expose a byte stream abstraction, most higher 702 level protocols impose some structure onto that byte stream. That 703 is, the higher level protocol operates in terms of messages, protocol 704 data units (PDUs), rather than using unstructured sequences of bytes, 705 with each message being processed in turn. Protocols are specified 706 in terms of state machines acting on semantic messages, with parsing 707 the byte stream into messages being a necessary annoyance, rather 708 than a semantic concern. Accordingly, the Transport Services 709 architecture exposes messages as the primary abstraction. Protocols 710 that deal only in byte streams, such as TCP, represent their data in 711 each direction as a single, long message. When framing protocols are 712 placed on top of byte streams, the messages used in the API represent 713 the framed messages within the stream. 715 Providing a message-based abstraction also provides: 717 o the ability to associate deadlines with messages, for transports 718 that care about timing; 720 o the ability to provide control of reliability, choosing what 721 messages to retransmit in the event of packet loss, and how best 722 to make use of the data that arrived; 724 o the ability to manage dependencies between messages, when some 725 messages may not be delivered due to either packet loss or missing 726 a deadline, in particular the ability to avoid (re-)sending data 727 that relies on a previous transmission that was never received. 729 All require explicit message boundaries, and application-level 730 framing of messages, to be effective. Once a message is passed to 731 the transport, it can not be cancelled or paused, but prioritization 732 as well as lifetime and retransmission management will provide the 733 protocol stack with all needed information to send the messages as 734 quickly as possible without blocking transmission unnecessarily. The 735 transport services architecture facilitates this by handling 736 messages, with known identity (sequence numbers, in the simple case), 737 lifetimes, niceness, and antecedents. 739 Transport protocols such as SCTP provide a message-oriented API that 740 has similar features to those we describe. Other transports, such as 741 TCP, do not. To support a message oriented API, while still being 742 compatible with stream-based transport protocols, implementations of 743 the transport services architecture should provide APIs for framing 744 and de-framing messages. That is, we push message framing down into 745 the transport services API, allowing applications to send and receive 746 complete messages. This is backwards compatible with existing 747 protocols and APIs, since the wire format of messages does not 748 change, but gives the protocol stack additional information to allow 749 it to make better use of modern transport services. 751 5. IANA Considerations 753 RFC-EDITOR: Please remove this section before publication. 755 This document has no actions for IANA. 757 6. Security Considerations 759 The Transport Services architecture does not recommend use of 760 specific security protocols or algorithms. Its goal is to offer ease 761 of use for existing protocols by providing a generic security-related 762 interface. Each provided interface mimics an existing protocol- 763 specific interface provided by supported security protocols. For 764 example, trust verification callbacks are common parts of TLS APIs. 765 Transport Services APIs will expose similar functionality. 767 Clients must take care to use security APIs appropriately. In cases 768 where clients use said interface to provide sensitive keying 769 material, e.g., access to private keys or copies of pre-shared keys 770 (PSKs), key use must be validated. For example, clients should not 771 use PSK material created for the Encapsulating Security Protocol 772 (ESP, part of IPsec) [RFC4303] with QUIC, and clients must not use 773 private keys intended for server authentication as a keys for client 774 authentication. Moreover, unlike certain transport features such as 775 TCP Fast Open (TFO) [RFC7413] or Explicit Congestion Notification 776 (ECN) [RFC3168] which can fall back to standard configurations, 777 Transport Services systems must not permit fallback for security 778 protocols. For example, if a client requests TLS, yet TLS or the 779 desired version are not available, its connection must fail. Clients 780 are responsible for implementing protocol or version fallback using a 781 Transport Services API if so desired. 783 7. Acknowledgements 785 This work has received funding from the European Union's Horizon 2020 786 research and innovation programme under grant agreement No. 644334 787 (NEAT). 789 This work has been supported by Leibniz Prize project funds of DFG - 790 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 791 FE 570/4-1). 793 This work has been supported by the UK Engineering and Physical 794 Sciences Research Council under grant EP/R04144X/1. 796 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 797 Kinnear for their implementation and design efforts, including Happy 798 Eyeballs, that heavily influenced this work. 800 8. Informative References 802 [I-D.ietf-taps-impl] 803 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 804 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 805 "Implementing Interfaces to Transport Services", draft- 806 ietf-taps-impl-00 (work in progress), May 2018. 808 [I-D.ietf-taps-interface] 809 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 810 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 811 Abstract Application Layer Interface to Transport 812 Services", draft-ietf-taps-interface-00 (work in 813 progress), April 2018. 815 [I-D.ietf-taps-minset] 816 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 817 Services for End Systems", draft-ietf-taps-minset-04 (work 818 in progress), June 2018. 820 [I-D.ietf-taps-transport-security] 821 Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey 822 of Transport Security Protocols", draft-ietf-taps- 823 transport-security-02 (work in progress), June 2018. 825 [I-D.ietf-tls-tls13] 826 Rescorla, E., "The Transport Layer Security (TLS) Protocol 827 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 828 March 2018. 830 [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology 831 -- Portable Operating System Interface (POSIX). Open 832 group Technical Standard: Base Specifications, Issue 7", 833 n.d.. 835 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 836 RFC 793, DOI 10.17487/RFC0793, September 1981, 837 . 839 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 840 of Explicit Congestion Notification (ECN) to IP", 841 RFC 3168, DOI 10.17487/RFC3168, September 2001, 842 . 844 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 845 RFC 4303, DOI 10.17487/RFC4303, December 2005, 846 . 848 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 849 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 850 . 852 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 853 Ed., "Services Provided by IETF Transport Protocols and 854 Congestion Control Mechanisms", RFC 8095, 855 DOI 10.17487/RFC8095, March 2017, 856 . 858 Authors' Addresses 860 Tommy Pauly (editor) 861 Apple Inc. 862 One Apple Park Way 863 Cupertino, California 95014 864 United States of America 866 Email: tpauly@apple.com 867 Brian Trammell (editor) 868 ETH Zurich 869 Gloriastrasse 35 870 8092 Zurich 871 Switzerland 873 Email: ietf@trammell.ch 875 Anna Brunstrom 876 Karlstad University 877 Universitetsgatan 2 878 651 88 Karlstad 879 Sweden 881 Email: anna.brunstrom@kau.se 883 Godred Fairhurst 884 University of Aberdeen 885 Fraser Noble Building 886 Aberdeen, AB24 3UE 887 Scotland 889 Email: gorry@erg.abdn.ac.uk 890 URI: http://www.erg.abdn.ac.uk/ 892 Colin Perkins 893 University of Glasgow 894 School of Computing Science 895 Glasgow G12 8QQ 896 United Kingdom 898 Email: csp@csperkins.org 900 Philipp S. Tiesel 901 TU Berlin 902 Marchstrasse 23 903 10587 Berlin 904 Germany 906 Email: philipp@inet.tu-berlin.de 907 Chris Wood 908 Apple Inc. 909 One Apple Park Way 910 Cupertino, California 95014 911 United States of America 913 Email: cawood@apple.com