idnits 2.17.1 draft-ietf-taps-arch-12.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 January 2022) is 837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-14 == Outdated reference: A later version (-18) exists of draft-ietf-taps-impl-10 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group T. Pauly, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track B. Trammell, Ed. 5 Expires: 7 July 2022 Google Switzerland GmbH 6 A. Brunstrom 7 Karlstad University 8 G. Fairhurst 9 University of Aberdeen 10 C. Perkins 11 University of Glasgow 12 3 January 2022 14 An Architecture for Transport Services 15 draft-ietf-taps-arch-12 17 Abstract 19 This document describes an architecture for exposing transport 20 protocol features to applications for network communication, a 21 Transport Services system. The Transport Services Application 22 Programming Interface (API) is based on an asynchronous, event-driven 23 interaction pattern. This API uses messages for representing data 24 transfer to applications, and describes how implementations can use 25 multiple IP addresses, multiple protocols, and multiple paths, and 26 provide multiple application streams. This document further defines 27 common terminology and concepts to be used in definitions of a 28 Transport Service API and a Transport Services implementation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 7 July 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Specification of Requirements . . . . . . . . . . . . . . 5 67 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 69 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 8 70 2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 8 71 3. API and Implementation Requirements . . . . . . . . . . . . . 9 72 3.1. Provide Common APIs for Common Features . . . . . . . . . 10 73 3.2. Allow Access to Specialized Features . . . . . . . . . . 11 74 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 12 75 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 13 76 4. Transport Services Architecture and Concepts . . . . . . . . 13 77 4.1. Transport Services API Concepts . . . . . . . . . . . . . 14 78 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16 79 4.1.2. Connections and Related Objects . . . . . . . . . . . 16 80 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 18 81 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18 82 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19 83 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20 84 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21 85 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21 86 4.2. Transport Services Implementation . . . . . . . . . . . . 22 87 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23 88 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 23 89 4.2.3. Separating Connection Contexts . . . . . . . . . . . 24 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 6. Security and Privacy Considerations . . . . . . . . . . . . . 25 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 95 8.2. Informative References . . . . . . . . . . . . . . . . . 26 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 (Socket API). The 103 naming of objects and functions across these APIs is not consistent, 104 and varies depending on the protocol being used. For example, 105 sending and receiving streams of data is conceptually the same for 106 both an unencrypted Transmission Control Protocol (TCP) stream and 107 operating on an encrypted Transport Layer Security (TLS) [RFC8446] 108 stream over TCP, but applications cannot use the same socket send() 109 and recv() calls on top of both kinds of connections. Similarly, 110 terminology for the implementation of transport protocols varies 111 based on the context of the protocols themselves: terms such as 112 "flow", "stream", "message", and "connection" can take on many 113 different meanings. This variety can lead to confusion when trying 114 to understand the similarities and differences between protocols, and 115 how applications can use them effectively. 117 The goal of the Transport Services architecture is to provide a 118 flexible and reusable architecture that provides a common interface 119 for transport protocols. As applications adopt this interface, they 120 will benefit from a wide set of transport features that can evolve 121 over time, and ensure that the system providing the interface can 122 optimize its behavior based on the application requirements and 123 network conditions, without requiring changes to the applications. 124 This flexibility enables faster deployment of new features and 125 protocols. It can also support applications by offering racing 126 mechanisms (attempting multiple IP addresses, protocols, or network 127 paths in parallel), which otherwise need to be implemented in each 128 application separately (see Section 4.2.2). 130 This document was developed in parallel with the specification of the 131 Transport Services API [I-D.ietf-taps-interface] and implementation 132 guidelines [I-D.ietf-taps-impl]. Although following the Transport 133 Services architecture does not require that all APIs and 134 implementations are identical, a common minimal set of features 135 represented in a consistent fashion will enable applications to be 136 easily ported from one system to another. 138 1.1. Background 140 The Transport Services architecture is based on the survey of 141 services provided by IETF transport protocols and congestion control 142 mechanisms [RFC8095], and the distilled minimal set of the features 143 offered by transport protocols [RFC8923]. These documents identified 144 common features and patterns across all transport protocols developed 145 thus far in the IETF. 147 Since transport security is an increasingly relevant aspect of using 148 transport protocols on the Internet, this architecture also considers 149 the impact of transport security protocols on the feature-set exposed 150 by Transport Services [RFC8922]. 152 One of the key insights to come from identifying the minimal set of 153 features provided by transport protocols [RFC8923] was that features 154 either require application interaction and guidance (referred to in 155 that document as Functional or Optimizing Features), or else can be 156 handled automatically by a system implementing Transport Services 157 (referred to as Automatable Features). Among the identified 158 Functional and Optimizing Features, some were common across all or 159 nearly all transport protocols, while others could be seen as 160 features that, if specified, would only be useful with a subset of 161 protocols, but would not harm the functionality of other protocols. 162 For example, some protocols can deliver messages faster for 163 applications that do not require messages to arrive in the order in 164 which they were sent. However, this functionality needs to be 165 explicitly allowed by the application, since reordering messages 166 would be undesirable in many cases. 168 1.2. Overview 170 This document describes the Transport Services architecture in three 171 sections: 173 * Section 2 describes how the API model of Transport Services 174 architecture differs from traditional socket-based APIs. 175 Specifically, it offers asynchronous event-driven interaction, the 176 use of messages for data transfer, and the flexibility to use 177 different transport protocols and paths without requiring major 178 changes to the application. 180 * Section 3 explains the fundamental requirements for a Transport 181 Services system. These principles are intended to make sure that 182 transport protocols can continue to be enhanced and evolve without 183 requiring significant changes by application developers. 185 * Section 4 presents a diagram showing the Transport Services 186 architecture and defines the concepts that are used by both the 187 API [I-D.ietf-taps-interface] and implementation guidelines 188 [I-D.ietf-taps-impl]. The Preconnection allows applications to 189 configure Connection Properties. 191 * Section 4 also presents how an abstract Connection is used to 192 select a transport protocol instance such as TCP, UDP, or another 193 transport. The Connection represents an object that can be used 194 to send and receive messages. 196 1.3. Specification of Requirements 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 2. API Model 206 The traditional model of using sockets for networking can be 207 represented as follows: 209 * Applications create connections and transfer data using the Socket 210 API. 212 * The Socket API provides the interface to the implementations of 213 TCP and UDP (typically implemented in the system's kernel). 215 * TCP and UDP in the kernel send and receive data over the available 216 network-layer interfaces. 218 * Sockets are bound directly to transport-layer and network-layer 219 addresses, obtained via a separate resolution step, usually 220 performed by a system-provided stub resolver. 222 +-----------------------------------------------------+ 223 | Application | 224 +-----------------------------------------------------+ 225 | | | 226 +------------+ +------------+ +--------------+ 227 | stub | | Stream API | | Datagram API | 228 | resolver | +------------+ +--------------+ 229 +------------+ | | 230 +---------------------------------+ 231 | TCP UDP | 232 | Kernel Networking Stack | 233 +---------------------------------+ 234 | 235 +-----------------------------------------------------+ 236 | Network Layer Interface | 237 +-----------------------------------------------------+ 239 Figure 1: Socket API Model 241 The Transport Services architecture evolves this general model of 242 interaction, to both modernize the API surface presented to 243 applications by the transport layer and to enrich the capabilities of 244 the implementation below the API. 246 +-----------------------------------------------------+ 247 | Application | 248 +-----------------------------------------------------+ 249 | 250 +-----------------------------------------------------+ 251 | Transport Services API | 252 +-----------------------------------------------------+ 253 | 254 +-----------------------------------------------------+ 255 | Transport Services Implementation | 256 | (Using: DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) | 257 +-----------------------------------------------------+ 258 | 259 +-----------------------------------------------------+ 260 | Network Layer Interface | 261 +-----------------------------------------------------+ 263 Figure 2: Transport Services API Model 265 The Transport Services API [I-D.ietf-taps-interface] defines the 266 interface for an application to create Connections and transfer data. 267 It combines interfaces for multiple interaction patterns into a 268 unified whole. By combining name resolution with connection 269 establishment and data transfer in a single API, it allows for more 270 flexible implementations to provide path and transport protocol 271 agility on the application's behalf. 273 The Transport Services implementation [I-D.ietf-taps-impl] implements 274 the transport layer protocols and other functions needed to send and 275 receive data. It is is responsible for mapping the API to a specific 276 available transport protocol stack and managing the available network 277 interfaces and paths. 279 There are key differences between the Transport Services architecture 280 and the architecture of the Socket API: the API of the Transport 281 Services architecture is asynchronous and event-driven; it uses 282 messages for representing data transfer to applications; and it 283 describes how implementations can use multiple IP addresses, multiple 284 protocols, multiple paths, and provide multiple application streams. 286 2.1. Event-Driven API 288 Originally, the Socket API presented a blocking interface for 289 establishing connections and transferring data. However, most modern 290 applications interact with the network asynchronously. Emulation of 291 an asynchronous interface using the Socket API generally uses a try- 292 and-fail model. If the application wants to read, but data has not 293 yet been received from the peer, the call to read will fail. The 294 application then waits and can try again later. In contrast to the 295 Socket API, all interaction using the Transport Services API is 296 expected to be asynchronous and use an event-driven model (see 297 Section 4.1.6). For example, an application first issues a call to 298 receive new data from the connection. When delivered data becomes 299 available, this data is delivered to the application using 300 asynchronous events that contain the data. Error handling is also 301 asynchronous; a failure to send data results in an asynchronous error 302 event. 304 This API also delivers events regarding the lifetime of a connection 305 and changes in the available network links, which were not previously 306 made explicit in the Socket API. 308 Using asynchronous events allows for a more natural interaction model 309 when establishing connections and transferring data. Events in time 310 more closely reflect the nature of interactions over networks, as 311 opposed to how the Socket API represent network resources as file 312 system objects that may be temporarily unavailable. 314 Separate from events, callbacks are also provided for asynchronous 315 interactions with the API not directly related to events on the 316 network or network interfaces. 318 2.2. Data Transfer Using Messages 320 The Socket API provides a message interface for datagram protocols 321 like UDP, but provides an unstructured stream abstraction for TCP. 322 While TCP has the ability to send and receive data as a byte-stream, 323 most applications need to interpret structure within this byte- 324 stream. For example, HTTP/1.1 uses character delimiters to segment 325 messages over a byte-stream [RFC7230]; TLS record headers carry a 326 version, content type, and length [RFC8446]; and HTTP/2 uses frames 327 to segment its headers and bodies [RFC7540]. 329 The Transport Services API represents data as messages, so that it 330 more closely matches the way applications use the network. Providing 331 a message-based abstraction provides many benefits, such as: 333 * the ability to associate deadlines with messages, for applications 334 that care about timing; 336 * the ability control reliability, which messages to retransmit when 337 there is packet loss, and how best to make use of the data that 338 arrived; 340 * the ability to automatically assign messages and connections to 341 underlying transport connections to utilize multi-streaming and 342 pooled connections. 344 Allowing applications to interact with messages is backwards- 345 compatible with existing protocols and APIs because it does not 346 change the wire format of any protocol. Instead, it gives the 347 protocol stack additional information to allow it to make better use 348 of modern transport services, while simplifying the application's 349 role in parsing data. For protocols which natively use a streaming 350 abstraction, framers (Section 4.1.5) bridge the gap between the two 351 abstractions. 353 2.3. Flexible Implementation 355 The Socket API for protocols like TCP is generally limited to 356 connecting to a single address over a single interface. It also 357 presents a single stream to the application. Software layers built 358 upon this API often propagate this limitation of a single-address 359 single-stream model. The Transport Services architecture is 360 designed: 362 * to handle multiple candidate endpoints, protocols, and paths; 364 * to support candidate protocol racing to select the most optimal 365 stack in each situation; 367 * to support multipath and multistreaming protocols; 369 * to provide state caching and application control over it. 371 A Transport Services implementation is intended to be flexible at 372 connection establishment time, considering many different options and 373 trying to select the most optimal combinations by racing them and 374 measuring the results (see Section 4.2.1 and Section 4.2.2). This 375 requires applications to provide higher-level endpoints than IP 376 addresses, such as hostnames and URLs, which are used by a Transport 377 Services implementation for resolution, path selection, and racing. 378 An implementation can further implement fallback mechanisms if 379 connection establishment of one protocol fails or performance is 380 detected to be unsatisfactory. 382 Information used in connection establishment (e.g. cryptographic 383 resumption tokens, information about usability of certain protocols 384 on the path, results of racing in previous connections) are cached in 385 the Transport Services implementation. Applications have control 386 over whether this information is used for a specific establishment, 387 in order to allow tradeoffs between efficiency and linkability. 389 Flexibility after connection establishment is also important. 390 Transport protocols that can migrate between multiple network-layer 391 interfaces need to be able to process and react to interface changes. 392 Protocols that support multiple application-layer streams need to 393 support initiating and receiving new streams using existing 394 connections. 396 3. API and Implementation Requirements 398 A goal of the Transport Services architecture is to redefine the 399 interface between applications and transports in a way that allows 400 the transport layer to evolve and improve without fundamentally 401 changing the contract with the application. This requires a careful 402 consideration of how to expose the capabilities of protocols. This 403 architecture also encompasses system policies that can influence and 404 inform how transport protocols use a network path or interface. 406 There are several ways the Transport Services system can offer 407 flexibility to an application: it can provide access to transport 408 protocols and protocol features; it can use these protocols across 409 multiple paths that could have different performance and functional 410 characteristics; and it can communicate with different remote systems 411 to optimize performance, robustness to failure, or some other metric. 412 Beyond these, if the Transport Services API remains the same over 413 time, new protocols and features can be added to the Transport 414 Services implementation without requiring changes in applications for 415 adoption. Similarly, this can provide a common basis for utilizing 416 information about a network path or interface, enabling evolution 417 below the transport layer. 419 The normative requirements described in this section allow Transport 420 Services APIs and Transport Services implementation to provide this 421 functionality without causing incompatibility or introducing security 422 vulnerabilities. 424 3.1. Provide Common APIs for Common Features 426 Any functionality that is common across multiple transport protocols 427 SHOULD be made accessible through a unified set of calls using the 428 Transport Services API. As a baseline, any Transport Services API 429 SHOULD allow access to the minimal set of features offered by 430 transport protocols [RFC8923]. 432 An application can specify constraints and preferences for the 433 protocols, features, and network interfaces it will use via 434 Properties. Properties are used by an application to declare its 435 preferences for how the transport service should operate at each 436 stage in the lifetime of a connection. Transport Properties are 437 subdivided into Selection Properties, which specify which paths and 438 protocol stacks can be used and are preferred by the application; 439 Connection Properties, which inform decisions made during connection 440 establishment and fine-tune the established connection; and Message 441 Properties, set on individual Messages. 443 It is RECOMMENDED that the Transport Services API offers properties 444 that are common to multiple transport protocols. This enables a 445 Transport Services implementation to appropriately select between 446 protocols that offer equivalent features. Similarly, it is 447 RECOMMENDED that the Properties offered by the Transport Services API 448 are applicable to a variety of network layer interfaces and paths, 449 which permits racing of different network paths without affecting the 450 applications using the API. Each is expected to have a default 451 value. 453 It is RECOMMENDED that the default values for Properties are selected 454 to ensure correctness for the widest set of applications, while 455 providing the widest set of options for selection. For example, 456 since both applications that require reliability and those that do 457 not require reliability can function correctly when a protocol 458 provides reliability, reliability ought to be enabled by default. As 459 another example, the default value for a Property regarding the 460 selection of network interfaces ought to permit as many interfaces as 461 possible. 463 Applications using the Transport Services API are REQUIRED to be 464 robust to the automated selection provided by the Transport Services 465 implementation. This automated selection is constrained by the 466 properties and preferences expressed by the application and requires 467 applications to explictly set properties that define any necssary 468 constraints on protocol, path, and interface selection. 470 3.2. Allow Access to Specialized Features 472 There are applications that will need to control fine-grained details 473 of transport protocols to optimize their behavior and ensure 474 compatibility with remote systems. It is therefore RECOMMENDED that 475 the Transport Services API and the Transport Services implementation 476 permit more specialized protocol features to be used. 478 A specialized feature could be needed by an application only when 479 using a specific protocol, and not when using others. For example, 480 if an application is using TCP, it could require control over the 481 User Timeout Option for TCP; these options would not take effect for 482 other transport protocols. In such cases, the API ought to expose 483 the features in such a way that they take effect when a particular 484 protocol is selected, but do not imply that only that protocol could 485 be used. For example, if the API allows an application to specify a 486 preference to use the User Timeout Option, communication would not 487 fail when a protocol such as QUIC is selected. 489 Other specialized features, however, can be strictly required by an 490 application and thus constrain the set of protocols that can be used. 491 For example, if an application requires support for automatic 492 handover or failover for a connection, only protocol stacks that 493 provide this feature are eligible to be used, e.g., protocol stacks 494 that include a multipath protocol or a protocol that supports 495 connection migration. A Transport Services API needs to allow 496 applications to define such requirements and constrain the options 497 available to a Transport Services implementation. Since such options 498 are not part of the core/common features, it will generally be simple 499 for an application to modify its set of constraints and change the 500 set of allowable protocol features without changing the core 501 implementation. 503 3.3. Select Equivalent Protocol Stacks 505 A Transport Services implementation can select Protocol Stacks based 506 on the Selection and Connection Properties communicated by the 507 application, along with any security parameters. If two different 508 Protocol Stacks can be safely swapped, or raced in parallel (see 509 Section 4.2.2), then they are considered to be "equivalent". 510 Equivalent Protocol Stacks are defined as stacks that can provide the 511 same Transport Properties and interface expectations as requested by 512 the application. 514 The following two examples show non-equivalent Protocol Stacks: 516 * If the application requires preservation of message boundaries, a 517 Protocol Stack that runs UDP as the top-level interface to the 518 application is not equivalent to a Protocol Stack that runs TCP as 519 the top-level interface. A UDP stack would allow an application 520 to read out message boundaries based on datagrams sent from the 521 remote system, whereas TCP does not preserve message boundaries on 522 its own, but needs a framing protocol on top to determine message 523 boundaries. 525 * If the application specifies that it requires reliable 526 transmission of data, then a Protocol Stack using UDP without any 527 reliability layer on top would not be allowed to replace a 528 Protocol Stack using TCP. 530 The following example shows equivalent Protocol Stacks: 532 * If the application does not require reliable transmission of data, 533 then a Protocol Stack that adds reliability could be regarded as 534 an equivalent Protocol Stack as long as providing this would not 535 conflict with any other application-requested properties. 537 To ensure that security protocols are not incorrectly swapped, a 538 Transport Services implementation MUST only select Protocol Stacks 539 that meet application requirements ([RFC8922]). A Transport Services 540 implementation SHOULD only race Protocol Stacks where the transport 541 security protocols within the stacks are identical. A Transport 542 Services implementation MUST NOT automatically fall back from secure 543 protocols to insecure protocols, or to weaker versions of secure 544 protocols. A Transport Services implementation MAY allow 545 applications to explicitly specify that fallback to a specific other 546 version of a protocol \, e.g., to allow fallback to TLS 1.2 if TLS 547 1.3 is not available. 549 3.4. Maintain Interoperability 551 It is important to note that neither the Transport Services API 552 [I-D.ietf-taps-interface] nor the guidelines for the Transport 553 Service implementation [I-D.ietf-taps-impl] define new protocols or 554 protocol capabilities that affect what is communicated across the 555 network. A Transport Services system MUST NOT require that a peer on 556 the other side of a connection uses the same API or implementation. 557 A Transport Services implementation acting as a connection initiator 558 is able to communicate with any existing endpoint that implements the 559 transport protocol(s) and all the required properties selected. 560 Similarly, a Transport Services implementation acting as a listener 561 can receive connections for any protocol that is supported from an 562 existing initiator that implements the protocol, independent of 563 whether the initiator uses the Transport Services architecture or 564 not. 566 A Transport Services system makes decisions that select protocols and 567 interfaces. In normal use, a given version of a Transport Services 568 system SHOULD result in consistent protocol and interface selection 569 decisions for the same network conditions given the same set of 570 Properties. This is intended to provide predictable outcomes to the 571 application using the API. 573 4. Transport Services Architecture and Concepts 575 This section and the remainder of this document describe the 576 architecture non-normatively. The concepts defined in this document 577 are intended primarily for use in the documents and specifications 578 that describe the Transport Services system. This includes the 579 architecture, the Transport Services API and the associated Transport 580 Services implementation. While the specific terminology can be used 581 in some implementations, it is expected that there will remain a 582 variety of terms used by running code. 584 The architecture divides the concepts for Transport Services system 585 into two categories: 587 1. API concepts, which are intended to be exposed to applications; 588 and 590 2. System-implementation concepts, which are intended to be 591 internally used by aTransport Services implementation. 593 The following diagram summarizes the top-level concepts in the 594 architecture and how they relate to one another. 596 +-----------------------------------------------------+ 597 | Application | 598 +-+----------------+------^-------+--------^----------+ 599 | | | | | 600 pre- | data | events 601 establishment | transfer | | 602 | establishment | termination | 603 | | | | | 604 | +--v------v-------v+ | 605 +-v-------------+ Connection(s) +-------+----------+ 606 | Transport +--------+---------+ | 607 | Services | | 608 | API | +-------------+ | 609 +------------------------+--+ Framer(s) |-----------+ 610 | +-------------+ 611 +------------------------|----------------------------+ 612 | Transport | | 613 | System | +-----------------+ | 614 | Implementation | | Cached | | 615 | | | State | | 616 | (Candidate Gathering) | +-----------------+ | 617 | | | 618 | (Candidate Racing) | +-----------------+ | 619 | | | System | | 620 | | | Policy | | 621 | +----------v-----+ +-----------------+ | 622 | | Protocol | | 623 +-------------+ Stack(s) +----------------------+ 624 +-------+--------+ 625 V 626 Network Layer Interface 628 Figure 3: Concepts and Relationships in the Transport Services 629 Architecture 631 4.1. Transport Services API Concepts 633 Fundamentally, a Transport Services API needs to provide connection 634 objects (Section 4.1.2) that allow applications to establish 635 communication, and then send and receive data. These could be 636 exposed as handles or referenced objects, depending on the chosen 637 programming language. 639 Beyond the connection objects, there are several high-level groups of 640 actions that any Transport Services API needs to provide: 642 * Pre-Establishment (Section 4.1.3) encompasses the properties that 643 an application can pass to describe its intent, requirements, 644 prohibitions, and preferences for its networking operations. 645 These properties apply to multiple transport protocols, unless 646 otherwise specified. Properties specified during Pre- 647 Establishment can have a large impact on the rest of the 648 interface: they modify how establishment occurs, they influence 649 the expectations around data transfer, and they determine the set 650 of events that will be supported. 652 * Establishment (Section 4.1.4) focuses on the actions that an 653 application takes on the connection objects to prepare for data 654 transfer. 656 * Data Transfer (Section 4.1.5) consists of how an application 657 represents the data to be sent and received, the functions 658 required to send and receive that data, and how the application is 659 notified of the status of its data transfer. 661 * Event Handling (Section 4.1.6) defines categories of notifications 662 which an application can receive during the lifetime of transport 663 objects. Events also provide opportunities for the application to 664 interact with the underlying transport by querying state or 665 updating maintenance options. 667 * Termination (Section 4.1.7) focuses on the methods by which data 668 transmission is stopped, and state is torn down in the transport. 670 The diagram below provides a high-level view of the actions and 671 events during the lifetime of a Connection object. Note that some 672 actions are alternatives (e.g., whether to initiate a connection or 673 to listen for incoming connections), while others are optional (e.g., 674 setting Connection and Message Properties in Pre-Establishment) or 675 have been omitted for brevity and simplicity. 677 Pre-Establishment : Established : Termination 678 ----------------- : ----------- : ----------- 679 : : 680 +-- Local Endpoint : Message : 681 +-- Remote Endpoint : Receive() | : 682 +-- Transport Properties : Send() | : 683 +-- Security Parameters : | : 684 | : | : 685 | InitiateWithSend() | Close() : 686 | +---------------+ Initiate() +-----+------+ Abort() : 687 +---+ Preconnection |------------->| Connection |-----------> Closed 688 +---------------+ Rendezvous() +------------+ : 689 Listen() | : | | : 690 | : | v : 691 v : | Connection : 692 +----------+ : | Ready : 693 | Listener |----------------------+ : 694 +----------+ Connection Received : 695 : : 697 Figure 4: The lifetime of a Connection object 699 4.1.1. Endpoint Objects 701 * Endpoint: An Endpoint represents an identifier for one side of a 702 transport connection. Endpoints can be Local Endpoints or Remote 703 Endpoints, and respectively represent an identity that the 704 application uses for the source or destination of a connection. 705 An Endpoint can be specified at various levels of abstraction. An 706 Endpoint at a higher level of abstraction (such as a hostname) can 707 be resolved to more concrete identities (such as IP addresses). 708 An endpoint may also represent a multicast group, in which case it 709 selects a multicast transport for communication. 711 * Remote Endpoint: The Remote Endpoint represents the application's 712 identifier for a peer that can participate in a transport 713 connection; for example, the combination of a DNS name for the 714 peer and a service name/port. 716 * Local Endpoint: The Local Endpoint represents the application's 717 identifier for itself that it uses for transport connections; for 718 example, a local IP address and port. 720 4.1.2. Connections and Related Objects 722 * Preconnection: A Preconnection object is a representation of a 723 Connection that has not yet been established. It has state that 724 describes parameters of the Connection: the Local Endpoint from 725 which that Connection will be established, the Remote Endpoint 726 (Section 4.1.3) to which it will connect, and Transport Properties 727 that influence the paths and protocols a Connection will use. A 728 Preconnection can be either fully specified (representing a single 729 possible Connection), or it can be partially specified 730 (representing a family of possible Connections). The Local 731 Endpoint (Section 4.1.3) is required for a Preconnection used to 732 Listen for incoming Connections, but optional if it is used to 733 Initiate a Connection. The Remote Endpoint is required in a 734 Preconnection that used to Initiate a Connection, but is optional 735 if it is used to Listen for incoming Connections. The Local 736 Endpoint and the Remote Endpoint are both required if a peer-to- 737 peer Rendezvous is to occur based on the Preconnection. 739 * Transport Properties: Transport Properties allow the application 740 to express their requirements, prohibitions, and preferences and 741 configure a Transport Services system. There are three kinds of 742 Transport Properties: 744 - Selection Properties (Section 4.1.3): Selection Properties can 745 only be specified on a Preconnection. 747 - Connection Properties (Section 4.1.3): Connection Properties 748 can be specified on a Preconnection and changed on the 749 Connection. 751 - Message Properties (Section 4.1.5): Message Properties can be 752 specified as defaults on a Preconnection or a Connection, and 753 can also be specified during data transfer to affect specific 754 Messages. 756 * Connection: A Connection object represents one or more active 757 transport protocol instances that can send and/or receive Messages 758 between Local and Remote Endpoints. It is an abstraction that 759 represents the communication. The Connection object holds state 760 pertaining to the underlying transport protocol instances and any 761 ongoing data transfers. For example, an active Connection can 762 represent a connection-oriented protocol such as TCP, or can 763 represent a fully-specified 5-tuple for a connectionless protocol 764 such as UDP, where the Connection remains an abstraction at the 765 end points. It can also represent a pool of transport protocol 766 instances, e.g., a set of TCP and QUIC connections to equivalent 767 endpoints, or a stream of a multi-streaming transport protocol 768 instance. Connections can be created from a Preconnection or by a 769 Listener. 771 * Listener: A Listener object accepts incoming transport protocol 772 connections from Remote Endpoints and generates corresponding 773 Connection objects. It is created from a Preconnection object 774 that specifies the type of incoming Connections it will accept. 776 4.1.3. Pre-Establishment 778 * Selection Properties: The Selection Properties consist of the 779 properties that an application can set to influence the selection 780 of paths between the Local and Remote Endpoints, to influence the 781 selection of transport protocols, or to configure the behavior of 782 generic transport protocol features. These properties can take 783 the form of requirements, prohibitions, or preferences. Examples 784 of properties that influence path selection include the interface 785 type (such as a Wi-Fi connection, or a Cellular LTE connection), 786 requirements around the largest Message that can be sent, or 787 preferences for throughput and latency. Examples of properties 788 that influence protocol selection and configuration of transport 789 protocol features include reliability, multipath support, and fast 790 open support. 792 * Connection Properties: The Connection Properties are used to 793 configure protocol-specific options and control per-connection 794 behavior of a Transport Services implementation; for example, a 795 protocol-specific Connection Property can express that if TCP is 796 used, the implementation ought to use the User Timeout Option. 797 Note that the presence of such a property does not require that a 798 specific protocol will be used. In general, these properties do 799 not explicitly determine the selection of paths or protocols, but 800 can be used by an implementation during connection establishment. 801 Connection Properties are specified on a Preconnection prior to 802 Connection establishment, and can be modified on the Connection 803 later. Changes made to Connection Properties after Connection 804 establishment take effect on a best-effort basis. 806 * Security Parameters: Security Parameters define an application's 807 requirements for authentication and encryption on a Connection. 808 They are used by Transport Security protocols (such as those 809 described in [RFC8922]) to establish secure Connections. Examples 810 of parameters that can be set include local identities, private 811 keys, supported cryptographic algorithms, and requirements for 812 validating trust of remote identities. Security Parameters are 813 primarily associated with a Preconnection object, but properties 814 related to identities can be associated directly with endpoints. 816 4.1.4. Establishment Actions 817 * Initiate: The primary action that an application can take to 818 create a Connection to a Remote Endpoint, and prepare any required 819 local or remote state to enable the transmission of Messages. For 820 some protocols, this will initiate a client-to-server style 821 handshake; for other protocols, this will just establish local 822 state (e.g., with connectionless protocols such as UDP). The 823 process of identifying options for connecting, such as resolution 824 of the Remote Endpoint, occurs in response to the Initiate call. 826 * Listen: Enables a listener to accept incoming Connections. The 827 Listener will then create Connection objects as incoming 828 connections are accepted (Section 4.1.6). Listeners by default 829 register with multiple paths, protocols, and Local Endpoints, 830 unless constrained by Selection Properties and/or the specified 831 Local Endpoint(s). Connections can be accepted on any of the 832 available paths or endpoints. 834 * Rendezvous: The action of establishing a peer-to-peer connection 835 with a Remote Endpoint. It simultaneously attempts to initiate a 836 connection to a Remote Endpoint while listening for an incoming 837 connection from that endpoint. The process of identifying options 838 for the connection, such as resolution of the Remote Endpoint, 839 occurs in response to the Rendezvous call. As with Listeners, the 840 set of local paths and endpoints is constrained by Selection 841 Properties. If successful, the Rendezvous call returns a 842 Connection object to represent the established peer-to-peer 843 connection. The processes by which connections are initiated 844 during a Rendezvous action will depend on the set of Local and 845 Remote Endpoints configured on the Preconnection. For example, if 846 the Local and Remote Endpoints are TCP host candidates, then a TCP 847 simultaneous open [RFC0793] will be performed. However, if the 848 set of Local Endpoints includes server reflexive candidates, such 849 as those provided by STUN, a Rendezvous action will race 850 candidates in the style of the ICE algorithm [RFC8445] to perform 851 NAT binding discovery and initiate a peer-to-peer connection. 853 4.1.5. Data Transfer Objects and Actions 855 * Message: A Message object is a unit of data that can be 856 represented as bytes that can be transferred between two endpoints 857 over a transport connection. The bytes within a Message are 858 assumed to be ordered. If an application does not care about the 859 order in which a peer receives two distinct spans of bytes, those 860 spans of bytes are considered independent Messages. 862 * Message Properties: Message Properties are used to specify details 863 about Message transmission. They can be specified directly on 864 individual Messages, or can be set on a Preconnection or 865 Connection as defaults. These properties might only apply to how 866 a Message is sent (such as how the transport will treat 867 prioritization and reliability), but can also include properties 868 that specific protocols encode and communicate to the Remote 869 Endpoint. When receiving Messages, Message Properties can contain 870 information about the received Message, such as metadata generated 871 at the receiver and information signalled by the Remote Endpoint. 872 For example, a Message can be marked with a Message Property 873 indicating that it is the final message on a connection. 875 * Send: The action to transmit a Message over a Connection to the 876 Remote Endpoint. The interface to Send can accept Message 877 Properties specific to how the Message content is to be sent. The 878 status of the Send operation is delivered back to the sending 879 application in an Event (Section 4.1.6). 881 * Receive: An action that indicates that the application is ready to 882 asynchronously accept a Message over a Connection from a Remote 883 Endpoint, while the Message content itself will be delivered in an 884 Event (Section 4.1.6). The interface to Receive can include 885 Message Properties specific to the Message that is to be delivered 886 to the application. 888 * Framer: A Framer is a data translation layer that can be added to 889 a Connection to define how application-layer Messages are 890 transmitted over a transport stack. This is particularly relevant 891 when using a protocol that otherwise presents unstructured 892 streams, such as TCP. 894 4.1.6. Event Handling 896 The following categories of events can be delivered to an 897 application: 899 * Connection Ready: Signals to an application that a given 900 Connection is ready to send and/or receive Messages. If the 901 Connection relies on handshakes to establish state between peers, 902 then it is assumed that these steps have been taken. 904 * Connection Closed: Signals to an application that a given 905 Connection is no longer usable for sending or receiving Messages. 906 The event delivers a reason or error to the application that 907 describes the nature of the termination. 909 * Connection Received: Signals to an application that a given 910 Listener has received a Connection. 912 * Message Received: Delivers received Message content to the 913 application, based on a Receive action. This can include an error 914 if the Receive action cannot be satisfied due to the Connection 915 being closed. 917 * Message Sent: Notifies the application of the status of its Send 918 action. This might indicate a failure if the Message cannot be 919 sent, or an indication that the Message has been processed by the 920 Transport Services system. 922 * Path Properties Changed: Notifies the application that a property 923 of the Connection has changed that might influence how and where 924 data is sent and/or received. 926 4.1.7. Termination Actions 928 * Close: The action an application takes on a Connection to indicate 929 that it no longer intends to send data, is no longer willing to 930 receive data, and that the protocol should signal this state to 931 the Remote Endpoint if the transport protocol allows this. (Note 932 that this is distinct from the concept of "half-closing" a 933 bidirectional connection, such as when a FIN is sent in one 934 direction of a TCP connection. The end of a stream can also be 935 indicated using Message Properties when sending.) 937 * Abort: The action the application takes on a Connection to 938 indicate a Close and also indicate that a Transport Services 939 system should not attempt to deliver any outstanding data, and 940 immediately drop the connection. This is intended for immediate, 941 usually abnormal, termination of a connection. 943 4.1.8. Connection Groups 945 A Connection Group is a set of Connections that shares properties and 946 caches. A Connection Group represents state for managing Connections 947 within a single application, and does not require end-to-end protocol 948 signaling. For multiplexing transport protocols, only Connections 949 within the same Connection Group are allowed to be multiplexed 950 together. 952 When the API clones an existing Connection, this adds a new 953 Connection to the Connection Group. A change to one of the 954 Connection Properties on any Connection in the Connection Group 955 automatically changes the Connection Property for all others. All 956 Connections in a Connection Group share the same set of Connection 957 Properties except for the Connection Priority. These Connection 958 Properties are said to be entangled. 960 For multiplexing transport protocols, only Connections within the 961 same Connection Group are allowed to be multiplexed together. 962 Passive Connections can also be added to a Connection Group, e.g., 963 when a Listener receives a new Connection that is just a new stream 964 of an already active multi-streaming protocol instance. 966 While Connection Groups are managed by the Transport Services system, 967 an application can define Connection Contexts to control caching 968 boundaries, as discussed in Section 4.2.3. 970 4.2. Transport Services Implementation 972 This section defines the key concepts of the Transport Services 973 architecture. 975 * Transport Service implementaion: This consists of all objects and 976 protocol instances used internally to a system or library to 977 implement the functionality needed to provide a transport service 978 across a network, as required by the abstract interface. 980 * Transport Service system: This consists of the Transport Service 981 implementaion and the Transport Services API. 983 * Path: Represents an available set of properties that a local 984 endpoint can use to communicate with a Remote Endpoint, such as 985 routes, addresses, and physical and virtual network interfaces. 987 * Protocol Instance: A single instance of one protocol, including 988 any state necessary to establish connectivity or send and receive 989 Messages. 991 * Protocol Stack: A set of Protocol Instances (including relevant 992 application, security, transport, or Internet protocols) that are 993 used together to establish connectivity or send and receive 994 Messages. A single stack can be simple (a single transport 995 protocol instance over IP), or it can be complex (multiple 996 application protocol streams going through a single security and 997 transport protocol, over IP; or, a multi-path transport protocol 998 over multiple transport sub-flows). 1000 * Candidate Path: One path that is available to an application and 1001 conforms to the Selection Properties and System Policy, of which 1002 there can be several. Candidate Paths are identified during the 1003 gathering phase (Section 4.2.1) and can be used during the racing 1004 phase (Section 4.2.2). 1006 * Candidate Protocol Stack: One Protocol Stack that can be used by 1007 an application for a Connection, which there can be several 1008 candidates. Candidate Protocol Stacks are identified during the 1009 gathering phase (Section 4.2.1) and are started during the racing 1010 phase (Section 4.2.2). 1012 * System Policy: Represents the input from an operating system or 1013 other global preferences that can constrain or influence how an 1014 implementation will gather candidate paths and Protocol Stacks 1015 (Section 4.2.1) and race the candidates during establishment 1016 (Section 4.2.2). Specific aspects of the System Policy either 1017 apply to all Connections or only certain ones, depending on the 1018 runtime context and properties of the Connection. 1020 * Cached State: The state and history that the implementation keeps 1021 for each set of associated Endpoints that have been used 1022 previously. This can include DNS results, TLS session state, 1023 previous success and quality of transport protocols over certain 1024 paths, as well as other information. 1026 4.2.1. Candidate Gathering 1028 * Candidate Path Selection: Candidate Path Selection represents the 1029 act of choosing one or more paths that are available to use based 1030 on the Selection Properties and any available Local and Remote 1031 Endpoints provided by the application, as well as the policies and 1032 heuristics of a Transport Services implementation. 1034 * Candidate Protocol Selection: Candidate Protocol Selection 1035 represents the act of choosing one or more sets of Protocol Stacks 1036 that are available to use based on the Transport Properties 1037 provided by the application, and the heuristics or policies within 1038 the Transport Services implementation. 1040 4.2.2. Candidate Racing 1042 Connection establishment attempts for a set of candidates may be 1043 performed simultaneously, synchronously, serially, or using some 1044 combination of all of these. We refer to this process as racing, 1045 borrowing terminology from Happy Eyeballs [RFC8305]. 1047 * Protocol Option Racing: Protocol Option Racing is the act of 1048 attempting to establish, or scheduling attempts to establish, 1049 multiple Protocol Stacks that differ based on the composition of 1050 protocols or the options used for protocols. 1052 * Path Racing: Path Racing is the act of attempting to establish, or 1053 scheduling attempts to establish, multiple Protocol Stacks that 1054 differ based on a selection from the available Paths. Since 1055 different Paths will have distinct configurations for local 1056 addresses and DNS servers, attempts across different Paths will 1057 perform separate DNS resolution steps, which can lead to further 1058 racing of the resolved Remote Endpoints. 1060 * Remote Endpoint Racing: Remote Endpoint Racing is the act of 1061 attempting to establish, or scheduling attempts to establish, 1062 multiple Protocol Stacks that differ based on the specific 1063 representation of the Remote Endpoint, such as a particular IP 1064 address that was resolved from a DNS hostname. 1066 4.2.3. Separating Connection Contexts 1068 By default, stored properties of the implementation, such as cached 1069 protocol state, cached path state, and heuristics, may be shared 1070 (e.g. across multiple connections in an application). This provides 1071 efficiency and convenience for the application, since the Transport 1072 Services system can automatically optimize behavior. 1074 The Transport Services API can allow applications to explicitly 1075 define Connection Contexts that force separation of Cached State and 1076 Protocol Stacks. For example, a web browser application could use 1077 Connection Contexts with separate caches when implementing different 1078 tabs. Possible reasons to isolate Connections using separate 1079 Connection Contexts include: 1081 * Privacy concerns about re-using cached protocol state that can 1082 lead to linkability. Sensitive state could include TLS session 1083 state [RFC8446] and HTTP cookies [RFC6265]. These concerns could 1084 be addressed using Connection Contexts with separate caches, such 1085 as for different browser tabs. 1087 * Privacy concerns about allowing Connections to multiplex together, 1088 which can tell a Remote Endpoint that all of the Connections are 1089 coming from the same application. Using Connection Contexts 1090 avoids the Connections being multiplexed in a HTTP/2 or QUIC 1091 stream. 1093 5. IANA Considerations 1095 RFC-EDITOR: Please remove this section before publication. 1097 This document has no actions for IANA. 1099 6. Security and Privacy Considerations 1101 The Transport Services architecture does not recommend use of 1102 specific security protocols or algorithms. Its goal is to offer ease 1103 of use for existing protocols by providing a generic security-related 1104 interface. Each provided interface translates to an existing 1105 protocol-specific interface provided by supported security protocols. 1106 For example, trust verification callbacks are common parts of TLS 1107 APIs; a Transport Services API exposes similar functionality 1108 [RFC8922]. 1110 As described above in Section 3.3, if a Transport Services 1111 implementation races between two different Protocol Stacks, both need 1112 to use the same security protocols and options. However, a Transport 1113 Services implementation can race different security protocols, e.g., 1114 if the application explicitly specifies that it considers them 1115 equivalent. 1117 The application controls whether information from previous racing 1118 attempts, or other information about past communications that was 1119 cached by the Transport Services system is used during establishment. 1120 This allows applications to make tradeoffs between efficiency 1121 (through racing) and privacy (via information that might leak from 1122 the cache toward an on-path observer). Some applications have native 1123 concepts (e.g. "incognito mode") that align with this functionality. 1125 Applications need to ensure that they use security APIs 1126 appropriately. In cases where applications use an interface to 1127 provide sensitive keying material, e.g., access to private keys or 1128 copies of pre-shared keys (PSKs), key use needs to be validated. For 1129 example, applications ought not to use PSK material created for the 1130 Encapsulating Security Protocol (ESP, part of IPsec) [RFC4303] with 1131 QUIC, and applications ought not to use private keys intended for 1132 server authentication as keys for client authentication. 1134 A Transport Services system must not automatically fall back from 1135 secure protocols to insecure protocols, or to weaker versions of 1136 secure protocols (see Section 3.3). For example, if an application 1137 requests a specific version of TLS, but the desired version of TLS is 1138 not available, its connection will fail. Applications are thus 1139 responsible for implementing security protocol fallback or version 1140 fallback by creating multiple Connections, if so desired. 1141 Alternatively, the Transport Services API MAY allow applications to 1142 specify that fallback to a specific other version of a protocol is 1143 allowed by the Transport Services system. 1145 7. Acknowledgements 1147 This work has received funding from the European Union's Horizon 2020 1148 research and innovation programme under grant agreements No. 644334 1149 (NEAT), No. 688421 (MAMI) and No 815178 (5GENESIS). 1151 This work has been supported by Leibniz Prize project funds of DFG - 1152 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 1153 FE 570/4-1). 1155 This work has been supported by the UK Engineering and Physical 1156 Sciences Research Council under grant EP/R04144X/1. 1158 Thanks to Theresa Enghardt, Max Franke, Mirja Kuehlewind, Jonathan 1159 Lennox, and Michael Welzl for the discussions and feedback that 1160 helped shape the architecture described here. Particular thanks is 1161 also due to Philipp S. Tiesel and Christopher A. Wood, who were 1162 both co-authors of this architecture specification as it progressed 1163 through the TAPS working group. Thanks as well to Stuart Cheshire, 1164 Josh Graessley, David Schinazi, and Eric Kinnear for their 1165 implementation and design efforts, including Happy Eyeballs, that 1166 heavily influenced this work. 1168 8. References 1170 8.1. Normative References 1172 [I-D.ietf-taps-interface] 1173 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1174 Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., 1175 Pauly, T., and K. Rose, "An Abstract Application Layer 1176 Interface to Transport Services", Work in Progress, 1177 Internet-Draft, draft-ietf-taps-interface-14, 3 January 1178 2022, . 1181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1182 Requirement Levels", BCP 14, RFC 2119, 1183 DOI 10.17487/RFC2119, March 1997, 1184 . 1186 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1187 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1188 May 2017, . 1190 8.2. Informative References 1192 [I-D.ietf-taps-impl] 1193 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 1194 Jones, T., Tiesel, P. S., Perkins, C., and M. Welzl, 1195 "Implementing Interfaces to Transport Services", Work in 1196 Progress, Internet-Draft, draft-ietf-taps-impl-10, 12 July 1197 2021, . 1200 [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology 1201 -- Portable Operating System Interface (POSIX). Open 1202 group Technical Standard: Base Specifications, Issue 7", 1203 2008. 1205 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1206 RFC 793, DOI 10.17487/RFC0793, September 1981, 1207 . 1209 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1210 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1211 . 1213 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1214 DOI 10.17487/RFC6265, April 2011, 1215 . 1217 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1218 Protocol (HTTP/1.1): Message Syntax and Routing", 1219 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1220 . 1222 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1223 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1224 DOI 10.17487/RFC7540, May 2015, 1225 . 1227 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1228 Ed., "Services Provided by IETF Transport Protocols and 1229 Congestion Control Mechanisms", RFC 8095, 1230 DOI 10.17487/RFC8095, March 2017, 1231 . 1233 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1234 Better Connectivity Using Concurrency", RFC 8305, 1235 DOI 10.17487/RFC8305, December 2017, 1236 . 1238 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1239 Connectivity Establishment (ICE): A Protocol for Network 1240 Address Translator (NAT) Traversal", RFC 8445, 1241 DOI 10.17487/RFC8445, July 2018, 1242 . 1244 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1245 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1246 . 1248 [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. 1249 Wood, "A Survey of the Interaction between Security 1250 Protocols and Transport Services", RFC 8922, 1251 DOI 10.17487/RFC8922, October 2020, 1252 . 1254 [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport 1255 Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, 1256 October 2020, . 1258 Authors' Addresses 1260 Tommy Pauly (editor) 1261 Apple Inc. 1262 One Apple Park Way 1263 Cupertino, California 95014, 1264 United States of America 1266 Email: tpauly@apple.com 1268 Brian Trammell (editor) 1269 Google Switzerland GmbH 1270 Gustav-Gull-Platz 1 1271 CH- 8004 Zurich 1272 Switzerland 1274 Email: ietf@trammell.ch 1276 Anna Brunstrom 1277 Karlstad University 1278 Universitetsgatan 2 1279 651 88 Karlstad 1280 Sweden 1282 Email: anna.brunstrom@kau.se 1283 Godred Fairhurst 1284 University of Aberdeen 1285 Fraser Noble Building 1286 Aberdeen, AB24 3UE 1288 Email: gorry@erg.abdn.ac.uk 1289 URI: http://www.erg.abdn.ac.uk/ 1291 Colin Perkins 1292 University of Glasgow 1293 School of Computing Science 1294 Glasgow G12 8QQ 1295 United Kingdom 1297 Email: csp@csperkins.org