idnits 2.17.00 (12 Aug 2021) /tmp/idnits52039/draft-pauly-taps-arch-00.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 (February 26, 2018) is 1538 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-taps-minset has been published as RFC 8923 == Outdated reference: A later version (-02) exists of draft-pauly-taps-transport-security-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: August 30, 2018 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 February 26, 2018 18 An Architecture for Transport Services 19 draft-pauly-taps-arch-00 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 August 30, 2018. 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 . . . . . . . . . . . . . . . . . 12 79 4.2. Transport System Implementation Concepts . . . . . . . . 13 80 4.2.1. Gathering . . . . . . . . . . . . . . . . . . . . . . 14 81 4.2.2. Racing . . . . . . . . . . . . . . . . . . . . . . . 14 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 8. Informative References . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 Many APIs to perform transport networking have been deployed, perhaps 91 the most widely known and imitated being the BSD socket() interface. 92 The names and functions between these APIs are not consistent, and 93 vary depending on the protocol being used. For example, sending and 94 receiving on a stream of data is conceptually the same between 95 operating on an unencrypted TCP stream and operating on an encrypted 96 TLS stream over TCP, but applications cannot use the same socket 97 send() and recv() calls on top of both kinds of connections. 98 Similarly, terminology for the implementation of protocols offering 99 transport services vary based on the context of the protocols 100 themselves. This variety can lead to confusion when trying to 101 understand the similarities and differences between protocols, and 102 how applications can use them effectively. 104 The goal of the Transport Services architecture is to provide a 105 common, flexible, and reusable interface for transport protocols. As 106 applications adopt this interface, they will benefit from a wide set 107 of transport features that can evolve over time, and ensure that the 108 system providing the interface can optimize its behavior based on the 109 application requirements and network conditions. 111 This document is developed in parallel with the specification of the 112 Transport Services API [draft-trammell-taps-interface] and 113 Implementation [draft-brunstrom-taps-impl] documents. 115 2. Background 117 The Transport Services architecture is based on the survey of 118 Services Provided by IETF Transport Protocols and Congestion Control 119 Mechanisms [RFC8095], and the distilled minimal set of the features 120 offered by transport protocols [I-D.ietf-taps-minset]. This work has 121 identified common features and patterns across all transport 122 protocols developed thus far in the IETF. 124 Since transport security is an increasingly relevant aspect of using 125 transport protocols on the Internet, this architecture also considers 126 the impact of transport security protocols on the feature set exposed 127 by transport services [I-D.pauly-taps-transport-security]. 129 One of the key insights to come from identifying the minimal set of 130 features provided by transport protocols [I-D.ietf-taps-minset] was 131 that features either require application interaction and guidance 132 (referred to as Functional Features), or else can be handled 133 automatically by a system implementing Transport Services (referred 134 to as Automatable Features). Among the Functional Features, some 135 were common across all or nearly all transport protocols, while 136 others could be seen as features that, if specified, would only be 137 useful with a subset of protocols, or perhaps even a single transport 138 protocol, but would not harm the functionality of other protocols. 139 For example, some protocols can deliver messages faster for 140 applications that do not require them to arrive in the order in which 141 they were sent. However, this functionality must be explicitly 142 allowed by the application, since reordering messages would be 143 undesirable in many cases. 145 3. Design Principles 147 The goal of the Transport Services architecture is to redefine the 148 interface between applications and transports in a way that allows 149 the transport layer to evolve and improve without fundamentally 150 changing the contract with the application. This requires a careful 151 consideration of how to expose the capabilities of protocols. 153 There are several degrees in which a Transport Services system can 154 offer flexibility to an application: it can provide access to 155 multiple sets of protocols and protocol features, it can use these 156 protocols across multiple paths that may have different performance 157 and functional characteristics, and it can communicate with different 158 Remote Endpoints to optimize performance. Beyond these, if the API 159 for the system remains the same over time, new protocols and features 160 may be added to the system's implementation without requiring 161 significant changes in applications for adoption. 163 The following considerations were used in the design of this 164 architecture. 166 3.1. Common APIs for Common Features 168 Functionality that is common across multiple transport protocols 169 should be accessible through a unified set of API calls. An 170 application should be able to implement logic for its basic use of 171 transport networking (establishing the transport, and sending and 172 receiving data) once, and expect that implementation to continue to 173 function as the transports change. 175 Any Transport Services API must allow access to the distilled minimal 176 set of features offered by transport protocols 177 [I-D.ietf-taps-minset]. 179 3.2. Access to Specialized Features 181 Since applications will often need to control fine-grained details of 182 transport protocols to optimize their behavior and ensure 183 compatibility with remote peers, a Transport Services system also 184 needs to allow more specialized protocol features to be used. The 185 interface for these specialized options should be exposed differently 186 from the common options to ensure flexibility. 188 A specialized feature may be required by an application only when 189 using a specific protocol, and not when using others. For example, 190 if an application is using UDP, it may require control over the 191 checksum or fragmentation behavior for UDP; if it used a protocol to 192 frame its data over a byte stream like TCP, it would not need these 193 options. In such cases, the API should expose the features in such a 194 way that they take effect when a particular protocol is selected, but 195 do not imply that only that protocol may be used if there are 196 equivalent options. 198 Other specialized features, however, may be strictly required by an 199 application and thus constrain the set of protocols that can be used. 200 For example, if an application requires encryption of its transport 201 data, only protocol stacks that include some transport security 202 protocol are eligible to be used. A Transport Services API must 203 allow applications to define such requirements and constrain the 204 system's options. Since such options are not part of the core/common 205 features, it should be simple for an application to modify its set of 206 constraints and change the set of allowable protocol features without 207 changing the core implementation. 209 3.3. Scope for API and Implementation Definitions 211 The Transport Services API is envisioned as the abstract model for a 212 family of APIs that share a common way to expose transport features 213 and encourage flexibility. The abstract API definition 214 [draft-trammell-taps-interface] describes this interface and is aimed 215 at application developers. 217 Implementations that provide the Transport Services API 218 [draft-brunstrom-taps-impl] will vary due to system-specific support 219 and the needs of the deployment scenario. It is expected that all 220 implementations of Transport Services will offer the entire mandatory 221 API, but that some features will not be functional in certain 222 implementations. All implementations must offer sufficient APIs to 223 use the distilled minimal set of features offered by transport 224 protocols [I-D.ietf-taps-minset], including API support for TCP and 225 UDP transport, but it is possible that some very constrained devices 226 might not have, for example, a full TCP implementation. 228 In order to preserve flexibility and compatibility with future 229 protocols, top-level features in the Transport Services API should 230 avoid referencing particular transport protocols. Mappings of these 231 API features in the Implementation document, on the other hand, must 232 explain the ramifications of each feature on existing protocols. It 233 is expected that the Implementation document will be updated and 234 supplemented as new protocols and protocol features are developed. 236 It is important to note that neither the Transport Services API nor 237 the Implementation document defines new protocols that require any 238 changes on remote hosts. The Transport Services system must be 239 deployable on one side only, as a way to allow an application to make 240 better use of available capabilities on a system and protocol 241 features that may be supported by peers across the network. 243 4. Transport Services Architecture and Concepts 245 The concepts defined in this document are intended primarily for use 246 in the documents and specifications that describe the Transport 247 Services architecture and API. While the specific terminology may be 248 used in some implementations, it is expected that there will remain a 249 variety of terms used by running code. 251 The architecture divides the concepts for Transport Services into two 252 categories: 254 1. API concepts, which are meant to be exposed to applications; and 256 2. System-implementation concepts, which are meant to be internally 257 used when building systems that implement Transport Services. 259 The following diagram summarizes the top-level concepts in the 260 architecture and how they relate to one another. 262 +------------------------------------------------------+ 263 | Application | 264 +-+----------------+------^-------+--------^-----------+ 265 | | | | | 266 pre- | data | events 267 establishment | transfer | | 268 | establishment | termination | 269 | | | | | 270 | +--v------v-------v+ | 271 +-v-------------+ Basic Objects +-------+----------+ 272 | Transport +--------+---------+ | 273 | Services | | 274 | API | | 275 +------------------------|----------------------------+ 276 | 277 +------------------------|----------------------------+ 278 | Transport | | 279 | System | +-----------------+ | 280 | Implementation | | Cached | | 281 | | | State | | 282 | (Candidate Gathering) | +-----------------+ | 283 | | | 284 | (Candidate Racing) | +-----------------+ | 285 | | | System | | 286 | | | Policy | | 287 | +----------v-----+ +-----------------+ | 288 | | Protocol | | 289 +-------------+ Stack(s) +----------------------+ 290 +-------+--------+ 291 V 292 Network Layer Interface 294 Figure 1: Concepts and Relationships in the Transport Services 295 Architecture 297 4.1. Transport Services API Concepts 299 Fundamentally, a Transport Services API needs to provide basic 300 objects (Section 4.1.1) that allow applications to establish 301 communication and send and receive data. These may be exposed as 302 handles or referenced objects, depending on the language. 304 Beyond the basic objects, there are several high-level groups of 305 actions that any Transport Services API must provide: 307 o Pre-Establishment (Section 4.1.2) encompasses the properties that 308 an application can pass to describe its intent, requirements, 309 prohibitions, and preferences for its networking operations. For 310 any system that provides generic Transport Services, these 311 properties should primarily offer knobs that are applicable to 312 multiple transports. Properties may have a large impact on the 313 rest of the aspects of the interface: they can modify how 314 establishment occurs, they can influence the expectations around 315 data transfer, and they determine the set of events that will be 316 supported. 318 o Establishment (Section 4.1.3) focuses on the actions that an 319 application takes on the basic objects to prepare for data 320 transfer. 322 o Data Transfer (Section 4.1.4) consists of how an application 323 represents data to be sent and received, the functions required to 324 send and receive that data, and how the application is notified of 325 the status of its data transfer. 327 o Event Handling (Section 4.1.5) defines the set of properties about 328 which an application can receive notifications during the lifetime 329 of transport objects. Events can also provide opportunities for 330 the application to interact with the underlying transport by 331 querying state or updating maintenance options. 333 o Termination (Section 4.1.6) focuses on the methods by which data 334 transmission is ceased, and state is torn down in the transport. 336 The diagram below provides a high-level view of the actions taken 337 during the lifetime of a connection. 339 Pre-Establishment : Established : Termination 340 ----------------- : ----------- : ----------- 341 : Close() : 342 +---------------+ Initiate() +------------+ Abort() : 343 +-->| Preconnection |----------->| Connection |---------------> Closed 344 | +---------------+ : +------------+ Connection: 345 | : ^ ^ | Finished : 346 +-- Local Endpoint : | | | : 347 | : | | +---------+ : 348 +-- Remote Endpoint : | | | : 349 | : | |Send() | : 350 +-- Path Selection : | +---------+ v : 351 | Properties : | | Message | Message : 352 | : | | to send | Received : 353 +-- Protocol Selection : | +---------+ : 354 | Properties : | : 355 | : | : 356 +-- Specific Protocol : | : 357 | Properties : | : 358 | : | : 359 | +----------+ : | : 360 +-->| Listener |-----------------+ : 361 +----------+ Connection Received : 362 ^ : : 363 | : : 364 Listen() : : 366 Figure 2: The lifetime of a connection 368 4.1.1. Basic Objects 370 o Preconnection: A Preconnection object is a representation of a 371 potential connection. It has state that describes parameters of a 372 Connection that might exist in the future: the Local Endpoint from 373 which that Connection will be established, the Remote Endpoint to 374 which it will connect, and Path Selection Properties, Protocol 375 Selection Properties, and Specific Protocol Properties that 376 influence the choice of transport that a Connection will use. A 377 Preconnection can be fully specified and represent a single 378 possible Connection, or it can be partially specified such that it 379 represents a family of possible Connections. The Local Endpoint 380 must be specified if the Preconnection is used to Listen for 381 incoming connections, but is optional if it is used to Initiate 382 connections. The Remote Endpoint must be specified in the 383 Preconnection is used to Initiate connections, but is optional if 384 it is used to Listen for incoming connections. 386 o Connection: A Connection object represents an active transport 387 protocol instance that can send and/or receive Messages between a 388 Local Endpoint and a Remote Endpoint. It holds state pertaining 389 to the underlying transport protocol instance and any ongoing data 390 transfer. This represents, for example, an active connection in a 391 connection-oriented protocol such as TCP, or a fully-specified 392 5-tuple for a connectionless protocol such as UDP. 394 o Listener: A Listener object accepts incoming transport protocol 395 connections from Remote Endpoints and generates corresponding 396 Connection objects. It is created from a Preconnection object 397 that specifies the type of incoming connections it will accept. 399 4.1.2. Pre-Establishment 401 o Endpoint: An Endpoint represents one side of a transport 402 connection. Endpoints can be Local Endpoints or Remote Endpoints, 403 and respectively represent an identity that the application uses 404 for the source or destination of a connection. Endpoint can vary 405 in levels of specificity, and can be resolved to more concrete 406 identities. 408 o Remote Endpoint: The Remote Endpoint represents the application's 409 name for a peer that can participate in a transport connection. 410 For example, the combination of a DNS name for the peer and a 411 service name/port. 413 o Local Endpoint: The Local Endpoint represents the application's 414 name for itself that it wants to use for transport connections. 415 For example, a local IP address and port. 417 o Path Selection Properties: The Path Selection Properties consist 418 of the options that an application may set to influence the 419 selection of paths between itself and the Remote Endpoint. These 420 options can come in the form of requirements, prohibitions, or 421 preferences. Examples of options which may influence path 422 selection include the interface type (such as a Wi-Fi Ethernet 423 connection, or a Cellular LTE connection), characteristics of the 424 path that are locally known like Maximum Transmission Unit (MTU) 425 or discovered like Path MTU (PMTU), or predicted based on cached 426 information like expected throughput or latency. 428 o Protocol Selection Properties: The Protocol Selection Properties 429 consist of the options that an application may set to influence 430 the selection of transport protocol, or to configure the behavior 431 of generic transport protocol features. These options come in the 432 form of requirements, prohibitions, and preferences. Examples 433 include reliability, service class, multipath support, and fast 434 open support. 436 o Specific Protocol Properties: The Specific Protocol Properties 437 refer to the subset of Protocol Properties options that apply to a 438 single protocol (transport protocol, IP, or security protocol). 439 The presence of such Properties does not necessarily require that 440 a specific protocol must be used when a Connection is established, 441 but that if this protocol is employed, a particular set of options 442 should be used. 444 4.1.3. Establishment Actions 446 o Initiate is the primary action that an application can take to 447 create a Connection to a remote endpoint, and prepare any required 448 local or remote state to be able to send and/or receive Messages. 449 For some protocols, this may initiate a server-to-client style 450 handshake; for other protocols, this may just establish local 451 state; and for peer-to-peer protocols, this may begin the process 452 of a simultaneous open. The process of identifying options for 453 connecting, such as resolution of the Remote Endpoint, occurs in 454 response the Initiate call. 456 o Listen is the action of marking a Listener as willing to accept 457 incoming Connections. The Listener will then create Connection 458 objects as incoming connections are accepted (Section 4.1.5). 460 4.1.4. Data Transfer Objects and Actions 462 o Message: A Message object is a unit of data that can be 463 represented as bytes that can be transferred between two endpoints 464 over a transport connection. The bytes within a Message are 465 assumed to be ordered within the Message. If an application does 466 not care about the order in which a peer receives two distinct 467 spans of bytes, those spans of bytes are considered independent 468 Messages. Messages may or may not be usable if incomplete or 469 corrupted. Boundaries of a Message may or may not be understood 470 or transmitted by transport protocols. Specifically, what one 471 application considers to be two Messages sent on a stream-based 472 transport may be treated as a single Message by the application on 473 the other side. 475 o Send is the action to transmit a Message or partial Message over a 476 Connection to a Remote Endpoint. The interface to Send may 477 include options specific to how the Message's content is to be 478 sent. Status of the Send operation may be delivered back to the 479 application in an event (Section 4.1.5). 481 o Receive is an action that indicates that the application is ready 482 to asynchronously accept a Message over a Connection from a Remote 483 Endpoint, while the Message content itself will be delivered in an 484 event (Section 4.1.5). The interface to Receive may include 485 options specific to the Message that is to be delivered to the 486 application. 488 4.1.5. Event Handling 490 This list of events that can be delivered to an application is not 491 exhaustive, but gives the top-level categories of events. The API 492 may expand this list. 494 o Connection Ready: Signals to an application that a given 495 Connection is ready to send and/or receive Messages. If the 496 Connection relies on handshakes to establish state between peers, 497 then it is assumed that these steps have been taken. 499 o Connection Finished: Signals to an application that a given 500 Connection is no longer usable for sending or receiving Messages. 501 This should deliver an error to the application that describes the 502 nature of the termination. 504 o Connection Received: Signals to an application that a given 505 Listener has passively received a Connection. 507 o Message Received: Delivers received Message content to the 508 application, based on a Receive action. This may include an error 509 if the Receive action cannot be satisfied due to the Connection 510 being closed. 512 o Message Sent: Notifies the application of the status of its Send 513 action. This may be an error if the Message cannot be sent, or an 514 indication that Message has been processed by the protocol stack. 516 o Path Properties Changed: Notifies the application that some 517 property of the Connection has changed that may influence how and 518 where data is sent and/or received. 520 4.1.6. Termination Actions 522 o Close is the action an application may take on a Connection to 523 indicate that it no longer intends to send data, is no longer 524 willing to receive data, and that the protocol should signal this 525 state to the remote endpoint if applicable. 527 o Abort is an action the application may take on a Connection to 528 indicate a Close, but with the additional indication that the 529 transport system should not attempt to deliver any outstanding 530 data. 532 4.2. Transport System Implementation Concepts 534 The Transport System Implementation Concepts define the set of 535 objects used internally to a system or library to provide the 536 functionality of transport networking, as required by the abstract 537 interface. 539 o Connection Group: A Connections Group is a set of Connections that 540 share properties. For multiplexing transport protocols, the 541 Connection Group defines the set of Connections that can be 542 multiplexed together. 544 o Path: A Path represents an available set of properties of a 545 network route on which packets may be sent or received. 547 o Protocol Instance: A Protocol Instance is a single instance of one 548 protocol, including any state it has necessary to establish 549 connectivity or send and receive Messages. 551 o Protocol Stack: A Protocol Stack is a set of Protocol Instances 552 (including relevant application, security, transport, or Internet 553 protocols) that are used together to establish connectivity or 554 send and receive Messages. A single stack may be simple (a single 555 transport protocol instance over IP), or complex (multiple 556 application protocol streams going through a single security and 557 transport protocol, over IP; or, a multi-path transport protocol 558 over multiple transport sub-flows). 560 o System Policy: System Policy represents the input from an 561 operating system or other global preferences that can constrain or 562 influence how an implementation will gather candidate paths and 563 protocols (Section 4.2.1) and race the candidates during 564 establishment (Section 4.2.2). Specific aspects of the System 565 Policy may apply to all Connections, or only certain ones 566 depending on the runtime context and properties of the Connection. 568 o Cached State: Cached State is the state and history that the 569 implementation keeps for each set of associated endpoints that 570 have been used previously. This can include DNS results, TLS 571 session state, previous success and quality of transport protocols 572 over certain paths. 574 4.2.1. Gathering 576 o Path Selection: Path Selection represents the act of choosing one 577 or more paths that are available to use based on the Path 578 Selection Properties provided by the application, and a Transport 579 Services system's policies and heuristics. 581 o Protocol Selection: Protocol Selection represents the act of 582 choosing one or more sets of protocol options that are available 583 to use based on the Protocol Properties provided by the 584 application, and a Transport Services system's policies and 585 heuristics. 587 4.2.2. Racing 589 o Protocol Option Racing: Protocol Racing is the act of attempting 590 to establish, or scheduling attempts to establish, multiple 591 Protocol Stacks that differ based on the composition of protocols 592 or the options used for protocols. 594 o Path Racing: Path Racing is the act of attempting to establish, or 595 scheduling attempts to establish, multiple Protocol Stacks that 596 differ based on a selection from the available Paths. 598 o Endpoint Racing: Endpoint Racing is the act of attempting to 599 establish, or scheduling attempts to establish, multiple Protocol 600 Stacks that differ based on the specific representation of the 601 Remote Endpoint and the Local Endpoint, such as IP addresses 602 resolved from a DNS hostname. 604 5. IANA Considerations 606 RFC-EDITOR: Please remove this section before publication. 608 This document has no actions for IANA. 610 6. Security Considerations 612 The Transport Services architecture does not recommend use of 613 specific security protocols or algorithms. Its goal is to offer ease 614 of use for existing protocols by providing a generic security-related 615 interface. Each provided interface mimics an existing protocol- 616 specific interface provided by supported security protocols. For 617 example, trust verification callbacks are common parts of TLS APIs. 618 Transport Services APIs will expose similar functionality. Clients 619 must take care to use security APIs appropriately. In cases where 620 clients use said interface to provide sensitive keying material, 621 e.g., access to private keys or copies of pre-shared keys (PSKs), key 622 use must be validated. For example, clients should not use PSK 623 material created for ESP with IETF-QUIC, and clients must not use 624 private keys intended for server authentication as a key for client 625 authentication. Moreover, unlike certain transport features such as 626 TFO or ECN which can fall back to standard configurations, Transport 627 Services systems must not permit fallback for security protocols. 628 For example, if a client requests TLS, yet TLS or the desired version 629 are not available, its connection must fail. Clients are responsible 630 for implementing protocol or version fallback using a Transport 631 Services API if so desired. 633 7. Acknowledgements 635 This work has received funding from the European Union's Horizon 2020 636 research and innovation programme under grant agreement No. 644334 637 (NEAT). 639 This work has been supported by Leibniz Prize project funds of DFG - 640 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 641 FE 570/4-1). 643 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 644 Kinnear for their implementation and design efforts, including Happy 645 Eyeballs, that heavily influenced this work. 647 8. Informative References 649 [draft-brunstrom-taps-impl] 650 "Implementing Interfaces to Transport Services", n.d.. 652 [draft-trammell-taps-interface] 653 "An Abstract Application Layer Interface to Transport 654 Services", n.d.. 656 [I-D.ietf-taps-minset] 657 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 658 Services for TAPS Systems", draft-ietf-taps-minset-01 659 (work in progress), February 2018. 661 [I-D.pauly-taps-transport-security] 662 Pauly, T., Rose, K., and C. Wood, "A Survey of Transport 663 Security Protocols", draft-pauly-taps-transport- 664 security-01 (work in progress), January 2018. 666 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 667 Ed., "Services Provided by IETF Transport Protocols and 668 Congestion Control Mechanisms", RFC 8095, 669 DOI 10.17487/RFC8095, March 2017, 670 . 672 Authors' Addresses 674 Tommy Pauly (editor) 675 Apple Inc. 676 One Apple Park Way 677 Cupertino, California 95014 678 United States of America 680 Email: tpauly@apple.com 682 Brian Trammell (editor) 683 ETH Zurich 684 Gloriastrasse 35 685 8092 Zurich 686 Switzerland 688 Email: ietf@trammell.ch 690 Anna Brunstrom 691 Karlstad University 693 Email: anna.brunstrom@kau.se 695 Godred Fairhurst 696 University of Aberdeen 697 Fraser Noble Building 698 Aberdeen, AB24 3UE 699 Scotland 701 Email: gorry@erg.abdn.ac.uk 702 URI: http://www.erg.abdn.ac.uk/ 703 Colin Perkins 704 University of Glasgow 705 School of Computing Science 706 Glasgow G12 8QQ 707 United Kingdom 709 Email: csp@csperkins.org 711 Philipp S. Tiesel 712 TU Berlin 713 Marchstrasse 23 714 10587 Berlin 715 Germany 717 Email: philipp@inet.tu-berlin.de 719 Chris Wood 720 Apple Inc. 721 One Apple Park Way 722 Cupertino, California 95014 723 United States of America 725 Email: cawood@apple.com