idnits 2.17.1 draft-trammell-taps-post-sockets-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 43 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 08, 2017) is 2415 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.trammell-plus-abstract-mech' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: 'I-D.trammell-plus-statefulness' is defined on line 1154, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-05 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 == Outdated reference: A later version (-03) exists of draft-kuehlewind-taps-crypto-sep-00 == Outdated reference: A later version (-02) exists of draft-pauly-taps-transport-security-00 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-03 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational C. Perkins 5 Expires: March 12, 2018 University of Glasgow 6 T. Pauly 7 Apple Inc. 8 M. Kuehlewind 9 ETH Zurich 10 C. Wood 11 Apple Inc. 12 September 08, 2017 14 Post Sockets, An Abstract Programming Interface for the Transport Layer 15 draft-trammell-taps-post-sockets-01 17 Abstract 19 This document describes Post Sockets, an asynchronous abstract 20 programming interface for the atomic transmission of messages in an 21 inherently multipath environment. Post replaces connections with 22 long-lived associations between endpoints, with the possibility to 23 cache cryptographic state in order to reduce amortized connection 24 latency. We present this abstract interface as an illustration of 25 what is possible with present developments in transport protocols 26 when freed from the strictures of the current sockets API. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 12, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Abstractions and Terminology . . . . . . . . . . . . . . . . 5 64 2.1. Message Carrier . . . . . . . . . . . . . . . . . . . . . 6 65 2.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.3. Association . . . . . . . . . . . . . . . . . . . . . . . 11 67 2.4. Remote . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 2.5. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 2.6. Policy Context . . . . . . . . . . . . . . . . . . . . . 12 70 2.7. Transient . . . . . . . . . . . . . . . . . . . . . . . . 13 71 2.8. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 3. Abstract Programming Interface . . . . . . . . . . . . . . . 14 73 3.1. Example Connection Patterns . . . . . . . . . . . . . . . 15 74 3.1.1. Client-Server . . . . . . . . . . . . . . . . . . . . 16 75 3.1.2. Client-Server with Happy Eyeballs and 0-RTT 76 establishment . . . . . . . . . . . . . . . . . . . . 17 77 3.1.3. Peer to Peer with Network Address Translation . . . . 17 78 3.1.4. Multicast Receiver . . . . . . . . . . . . . . . . . 17 79 3.2. Association Bootstrapping . . . . . . . . . . . . . . . . 18 80 4. Implementation Considerations . . . . . . . . . . . . . . . . 19 81 4.1. Protocol Stack Instance (PSI) . . . . . . . . . . . . . . 19 82 4.2. Message Framing, Parsing, and Serialization . . . . . . . 20 83 4.3. Message Size Limitations . . . . . . . . . . . . . . . . 22 84 4.4. Back-pressure . . . . . . . . . . . . . . . . . . . . . . 22 85 4.5. Associations, Transients, Racing, and Rendezvous . . . . 22 86 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 6.1. Normative References . . . . . . . . . . . . . . . . . . 25 89 6.2. Informative References . . . . . . . . . . . . . . . . . 25 90 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing 96 network sockets into the UNIX programming model, allowing anyone who 97 knew how to write programs that dealt with sequential-access files to 98 also write network applications, was a revolution in simplicity. It 99 would not be an overstatement to say that this simple API is the 100 reason the Internet won the protocol wars of the 1980s. SOCK_STREAM 101 is tied to the Transmission Control Protocol (TCP), specified in 1981 102 [RFC0793]. TCP has scaled remarkably well over the past three and a 103 half decades, but its total ubiquity has hidden an uncomfortable 104 fact: the network is not really a file, and stream abstractions are 105 too simplistic for many modern application programming models. 107 In the meantime, the nature of Internet access, and the variety of 108 Internet transport protocols, is evolving. The challenges that new 109 protocols and access paradigms present to the sockets API and to 110 programming models based on them inspire the design elements of a new 111 approach. 113 Many end-user devices are connected to the Internet via multiple 114 interfaces, which suggests it is time to promote the paths by which 115 two endpoints are connected to each other to a first-order object. 116 While implicit multipath communication is available for these 117 multihomed nodes in the present Internet architecture with the 118 Multipath TCP extension (MPTCP) [RFC6824], MPTCP was specifically 119 designed to hide multipath communication from the application for 120 purposes of compatibility. Since many multihomed nodes are connected 121 to the Internet through access paths with widely different properties 122 with respect to bandwidth, latency and cost, adding explicit path 123 control to MPTCP's API would be useful in many situations. 125 Another trend straining the traditional layering of the transport 126 stack associated with the SOCK_STREAM interface is the widespread 127 interest in ubiquitous deployment of encryption to guarantee 128 confidentiality, authenticity, and integrity, in the face of 129 pervasive surveillance [RFC7258]. Layering the most widely deployed 130 encryption technology, Transport Layer Security (TLS), strictly atop 131 TCP (i.e., via a TLS library such as OpenSSL that uses the sockets 132 API) requires the encryption-layer handshake to happen after the 133 transport-layer handshake, which increases connection setup latency 134 on the order of one or two round-trip times, an unacceptable delay 135 for many applications. Integrating cryptographic state setup and 136 maintenance into the path abstraction naturally complements efforts 137 in new protocols (e.g. QUIC [I-D.ietf-quic-transport]) to mitigate 138 this strict layering. 140 To meet these challenges, we present the Post-Sockets Application 141 Programming Interface (API), described in detail in this work. Post 142 is designed to be language, transport protocol, and architecture 143 independent, allowing applications to be written to a common abstract 144 interface, easily ported among different platforms, and used even in 145 environments where transport protocol selection may be done 146 dynamically, as proposed in the IETF's Transport Services working 147 group. 149 Post replaces the traditional SOCK_STREAM abstraction with a Message 150 abstraction, which can be seen as a generalization of the Stream 151 Control Transmission Protocol's [RFC4960] SOCK_SEQPACKET service. 152 Messages are sent and received on Carriers, which logically group 153 Messages for transmission and reception. For backward compatibility, 154 bidirectional byte stream protocols are represented as a pair of 155 Messages, one in each direction, that can only be marked complete 156 when the sending peer has finished transmitting data. 158 Post replaces the notions of a socket address and connected socket 159 with an Association with a remote endpoint via set of Paths. 160 Implementation and wire format for transport protocol(s) implementing 161 the Post API are explicitly out of scope for this work; these 162 abstractions need not map directly to implementation-level concepts, 163 and indeed with various amounts of shimming and glue could be 164 implemented with varying success atop any sufficiently flexible 165 transport protocol. 167 The key features of Post as compared with the existing sockets API 168 are: 170 o Explicit Message orientation, with framing and atomicity 171 guarantees for Message transmission. 173 o Asynchronous reception, allowing all receiver-side interactions to 174 be event-driven. 176 o Explicit support for multistreaming and multipath transport 177 protocols and network architectures. 179 o Long-lived Associations, whose lifetimes may not be bound to 180 underlying transport connections. This allows associations to 181 cache state and cryptographic key material to enable fast 182 resumption of communication, and for the implementation of the API 183 to explicitly take care of connection establishment mechanics such 184 as connection racing [RFC6555] and peer-to-peer rendezvous 185 [RFC5245]. 187 o Transport protocol stack independence, allowing applications to be 188 written in terms of the semantics best for the application's own 189 design, separate from the protocol(s) used on the wire to achieve 190 them. This enables applications written to a single API to make 191 use of transport protocols in terms of the features they provide, 192 as in [I-D.ietf-taps-transports]. 194 This work is the synthesis of many years of Internet transport 195 protocol research and development. It is inspired by concepts from 196 the Stream Control Transmission Protocol (SCTP) [RFC4960], TCP Minion 197 [I-D.iyengar-minion-protocol], and MinimaLT [MinimaLT], among other 198 transport protocol modernization efforts. We present Post as an 199 illustration of what is possible with present developments in 200 transport protocols when freed from the strictures of the current 201 sockets API. While much of the work for building parts of the 202 protocols needed to implement Post are already ongoing in other IETF 203 working groups (e.g. MPTCP, QUIC, TLS), we argue that an abstract 204 programming interface unifying access all these efforts is necessary 205 to fully exploit their potential. 207 2. Abstractions and Terminology 208 +===============+ 209 | Message | 210 +===============+ 211 | ^ | | 212 send()| |ready() |initiate() |listen() 213 V | V V 214 +=====================+ +============+ 215 | | accept() | | 216 | Carrier |<----------| Listener | 217 | | | | 218 +=====================+ +============+ 219 |1 | n| | +=========+ 220 | | |1 | +---| Local | 221 | +=========+ +=======================+ | +=========+ 222 | | Policy |n | |---+ 223 | | Context |---| Association | +=========+ 224 | | | 1| |-------| Remote | 225 | +=========+ +=======================+ +=========+ 226 | | 1| durable end-to-end 227 +-------+ | | state via many paths, 228 | | | policies, and prefs 229 n| | n| 230 +===========+ +==========+ 231 ephemeral | | | | 232 transport & | Transient |-------| Path | properties of 233 crypto state | |n 1| | address pair 234 +===========+ +==========+ 236 Figure 1: Abstractions and relationships in Post Sockets 238 Post is based on a small set of abstractions, centered around a 239 Message Carrier as the entry point for an application to the 240 networking API. The relationships among them are shown in 241 Figure Figure 1 and detailed in this section. 243 2.1. Message Carrier 245 A Message Carrier (or simply Carrier) is a transport protocol stack- 246 independent interface for sending and receiving messages between an 247 application and a remote endpoint; it is roughly analogous to a 248 socket in the present sockets API. 250 Sending a Message over a Carrier is driven by the application, while 251 receipt is driven by the arrival of the last packet that allows the 252 Message to be assembled, decrypted, and passed to the application. 253 Receipt is therefore asynchronous; given the different models for 254 asynchronous I/O and concurrency supported by different platforms, it 255 may be implemented in any number of ways. The abstract API provides 256 only for a way for the application to register how it wants to handle 257 incoming messages. 259 All the Messages sent to a Carrier will be received on the 260 corresponding Carrier at the remote endpoint, though not necessarily 261 reliably or in order, depending on Message properties and the 262 underlying transport protocol stack. 264 A Carrier that is backed by current transport protocol stack state 265 (such as a TCP connection; see Section 2.7) is said to be "active": 266 messages can be sent and received over it. A Carrier can also be 267 "dormant": there is long-term state associated with it (via the 268 underlying Association; see Section 2.3), and it may be able to 269 reactivated, but messages cannot be sent and received immediately. 271 If supported by the underlying transport protocol stack, a Carrier 272 may be forked: creating a new Carrier associated with a new Carrier 273 at the same remote endpoint. The semantics of the usage of multiple 274 Carriers based on the same Association are application-specific. 275 When a Carrier is forked, its corresponding Carrier at the remote 276 endpoint receives a fork request, which it must accept in order to 277 fully establish the new carrier. Multiple Carriers between endpoints 278 are implemented differently by different transport protocol stacks, 279 either using multiple separate transport-layer connections, or using 280 multiple streams of multistreaming transport protocols. 282 To exchange messages with a given remote endpoint, an application may 283 initiate a Carrier given its remote (see Section 2.4 and local (see 284 Section 2.5) identities; this is an equivalent to an active open. 285 There are four special cases of Carriers, as well, supporting 286 different initiation and interaction patterns, defined in the 287 subsections below. 289 o Listener: A Listener is a special case of Message Carrier which 290 only responds to requests to create a new Carrier from a remote 291 endpoint, analogous to a server or listening socket in the present 292 sockets API. Instead of being bound to a specific remote 293 endpoint, it is bound only to a local identity; however, its 294 interface for accepting fork requests is identical to that for 295 fully fledged Carriers. 297 o Source: A Source is a special case of Message Carrier over which 298 messages can only be sent, intended for unidirectional 299 applications such as multicast transmitters. Sources cannot be 300 forked, and need not accept forks. 302 o Sink: A Sink is a special case of Message Carrier over which 303 messages can only be received, intended for unidirectional 304 applications such as multicast receivers. Sinks cannot be forked, 305 and need not accept forks. 307 o Responder: A Responder is a special case of Message Carrier which 308 may receive messages from many remote sources, for cases in which 309 an application will only ever send Messages in reply back to the 310 source from which a Message was received. This is a common 311 implementation pattern for servers in client-server applications. 312 A Responder's receiver gets a Message, as well as a Source to send 313 replies to. Responders cannot be forked, and need not accept 314 forks. 316 2.2. Message 318 A Message is the unit of communication between applications. 319 Messages can represent relatively small structures, such as requests 320 in a request/response protocol such as HTTP; relatively large 321 structures, such as files of arbitrary size in a filesystem; and 322 structures of indeterminate length, such as a stream of bytes in a 323 protocol like TCP. 325 In the general case, there is no mapping between a Message and 326 packets sent by the underlying protocol stack on the wire: the 327 transport protocol may freely segment messages and/or combine 328 messages into packets. However, a message may be marked as 329 immediate, which will cause it to be sent in a single packet when 330 possible. 332 Content may be sent and received either as Complete or Partial 333 Messages. Dealing with Complete Messages should be preferred for 334 simplicity whenever possible based on the underlying protocol. It is 335 always possible to send Complete Messages, but only protocols that 336 have a fixed maximum message length may allow clients to receive 337 Messages using an API that guarantees Complete Messages. Sending and 338 receiving Partial Messages (that is, a Message whose content spans 339 multiple calls or callbacks) is always possible. 341 To send a Message, either Complete or Partial, the Message content is 342 passed into the Carrier, and client provides a set of callbacks to 343 know when the Message was delivered or acknowledged. The client of 344 the API may use the callbacks to pace the sending of Messages. 346 To receive a Message, the client of the API schedules a completion to 347 be called when a Complete or Partial Message is available. If the 348 client is willing to accept Partial Messages, it can specify the 349 minimum incomplete Message length it is willing to receive at once, 350 and the maximum number of bytes it is willing to receive at once. If 351 the client wants Complete Messages, there are no values to tune. The 352 scheduling of the receive completion indicates to the Carrier that 353 there is a desire to receive bytes, effectively creating a "pull 354 model" in which backpressure may be applied if the client is not 355 receiving Messages or Partial Messages quickly enough to match the 356 peer's sending rate. The Carrier may have some minimal buffer of 357 incoming Messages ready for the client to read to reduce latency. 359 When receiving a Complete Message, the entire content of the Message 360 must be delivered at once, and the Message is not delivered at all if 361 the full Message is not received. This implies that both the sending 362 and receiving endpoint, whether in the application or the carrier, 363 must guarantee storage for the full size of a Message. 365 Partial Messages may be sent or received in several stages, with a 366 handle representing the total Message being associated with each 367 portion of the content. Each call to send or receive also indicates 368 whether or not the Message is now complete. This approach is 369 necessary whenever the size of the Message does not have a known 370 bound, or the size is too large to process and hold in memory. 371 Protocols that only present a concept of byte streams represent their 372 data as single Messages with unknown bounds. In the case of TCP, the 373 client will receive a single Message in pieces using the Partial 374 Message API, and that Message will only be marked as complete when 375 the peer has sent a FIN. 377 Messages are sent over and received from Message Carriers (see 378 Section 2.1). 380 On sending, Messages have properties that allow the application to 381 specify its requirements with respect to reliability, ordering, 382 priority, idempotence, and immediacy; these are described in detail 383 below. Messages may also have arbitrary properties which provide 384 additional information to the underlying transport protocol stack on 385 how they should be handled, in a protocol-specific way. These stacks 386 may also deliver or set properties on received messages, but in the 387 general case a received messages contains only a sequence of ordered 388 bytes. Message properties include: 390 o Lifetime and Partial Reliability: A Message may have a "lifetime" 391 - a wall clock duration before which the Message must be available 392 to the application layer at the remote end. If a lifetime cannot 393 be met, the Message is discarded as soon as possible. Messages 394 without lifetimes are sent reliably if supported by the transport 395 protocol stack. Lifetimes are also used to prioritize Message 396 delivery. 398 There is no guarantee that a Message will not be delivered after 399 the end of its lifetime; for example, a Message delivered over a 400 strictly reliable transport will be delivered regardless of its 401 lifetime. Depending on the transport protocol stack used to 402 transmit the message, these lifetimes may also be signalled to 403 path elements by the underlying transport, so that path elements 404 that realize a lifetime cannot be met can discard frames 405 containing the Messages instead of forwarding them. 407 o Priority: Messages have a "niceness" - a priority among other 408 messages sent over the same Carrier in an unbounded hierarchy most 409 naturally represented as a non-negative integer. By default, 410 Messages are in niceness class 0, or highest priority. Niceness 411 class 1 Messages will yield to niceness class 0 Messages sent over 412 the same Carrier, class 2 to class 1, and so on. Niceness may be 413 translated to a priority signal for exposure to path elements 414 (e.g. DSCP code point) to allow prioritization along the path as 415 well as at the sender and receiver. This inversion of normal 416 schemes for expressing priority has a convenient property: 417 priority increases as both niceness and lifetime decrease. A 418 Message may have both a niceness and a lifetime - Messages with 419 higher niceness classes will yield to lower classes if resource 420 constraints mean only one can meet the lifetime. 422 o Dependence: A Message may have "antecedents" - other Messages on 423 which it depends, which must be delivered before it (the 424 "successor") is delivered. The sending transport uses deadlines, 425 niceness, and antecedents, along with information about the 426 properties of the Paths available, to determine when to send which 427 Message down which Path. 429 o Idempotence: A sending application may mark a Message as 430 "idempotent" to signal to the underlying transport protocol stack 431 that its application semantics make it safe to send in situations 432 that may cause it to be received more than once (i.e., for 0-RTT 433 session resumption as in TCP Fast Open, TLS 1.3, and QUIC). 435 o Immediacy: A sending application may mark a Message as "immediate" 436 to signal to the underlying transport protocol stack that its 437 application semantics require it to be placed in a single packet, 438 on its own, instead of waiting to be combined with other messages 439 or parts thereof (i.e., for media transports and interactive 440 sessions with small messages). 442 Senders may also be asynchronously notified of three events on 443 Messages they have sent: that the Message has been transmitted, that 444 the Message has been acknowledged by the receiver, or that the 445 Message has expired before transmission/acknowledgement. Not all 446 transport protocol stacks will support all of these events. 448 2.3. Association 450 An Association contains the long-term state necessary to support 451 communications between a Local (see Section 2.5) and a Remote (see 452 Section 2.4) endpoint, such as trust model information, including 453 pinned public keys or anchor certificates, cryptographic session 454 resumption parameters, or rendezvous information. It uses 455 information from the Policy Context (see Section 2.6) to constrain 456 the selection of transport protocols and local interfaces to create 457 Transients (see Section 2.7) to carry Messages; and information about 458 the paths through the network available available between them (see 459 Section 2.8). 461 All Carriers are bound to an Association. New Carriers will reuse an 462 Association if they can be carried from the same Local to the same 463 Remote over the same Paths; this re-use of an Association may implies 464 the creation of a new Transient. 466 Associations may exist and be created without a Carrier. This may be 467 done if peer cryptographic state such as a pre-shared key is 468 established out-of-band. Thus, Associations may be created without 469 the need to send application data to a peer, that is, without a 470 Carrier. Associations are mutable. Association state may expire 471 over time, after which it is removed from the Association, and 472 Transients may export cryptographic state to store in an Association 473 as needed. Moreover, this state may be exported directly into the 474 Association or modified before insertion. This may be needed to 475 diversify ephemeral Transient keying material from the longer-term 476 Association keying material. 478 A primary use of Association state is to allow new Associations and 479 their derived Carriers to be quickly created without performing in- 480 band cryptographic handshakes. See [I-D.kuehlewind-taps-crypto-sep] 481 for more details about this separation. 483 2.4. Remote 485 A Remote represents information required to establish and maintain a 486 connection with the far end of an Association: name(s), address(es), 487 and transport protocol parameters that can be used to establish a 488 Transient; transport protocols to use; trust model information, 489 inherited from the relevant Association, used to identify the remote 490 on connection establishment; and so on. Each Association is 491 associated with a single Remote, either explicitly by the application 492 (when created by the initiation of a Carrier) or a Listener (when 493 created by forking a Carrier on passive open). 495 A Remote may be resolved, which results in zero or more Remotes with 496 more specific information. For example, an application may want to 497 establish a connection to a website identified by a URL 498 https://www.example.com. This URL would be wrapped in a Remote and 499 passed to a call to initiate a Carrier. The first pass resolution 500 might parse the URL, decomposing it into a name, a transport port, 501 and a transport protocol to try connecting with. A second pass 502 resolution would then look up network-layer addresses associated with 503 that name through DNS, and store any certificates available from 504 DANE. Once a Remote has been resolved to the point that a transport 505 protocol stack can use it to create a Transient, it is considered 506 fully resolved. 508 2.5. Local 510 A Local represents all the information about the local endpoint 511 necessary to establish an Association or a Listener: interface, port, 512 and transport protocol stack information, and, per 513 [I-D.pauly-taps-transport-security], cryptographic identities 514 (certificates and associated private keys) bound to this endpoint. 516 2.6. Policy Context 518 The Policy Context describes preferences for, and restrictions on, 519 how to configure Transients to support communication between a Local 520 and a Remote over one or more Paths between endpoints. For instance, 521 an application may require, or prefer to use, certain features (see 522 [I-D.ietf-taps-transports]) of the transport protocol stacks used by 523 the Transients underlying the Carrier. Alternatively, it might also 524 prefer Paths over one interface to those over another (e.g., WiFi 525 access over LTE when roaming on a foreign LTE network, due to cost). 527 These policies are expressed in the Policy Context(s) that are bound 528 to the Association. Multiple policy contexts can be active at once. 529 For example, a system Policy Context can express the administrative 530 preferences around network interface and protocol selection, while an 531 application Policy Context expresses preferences for use of different 532 transport services. Expression of policy contexts and the resolution 533 of conflicts among Policy Contexts is currently implementation- 534 specific (the Policy API in the NEAT architecture [NEAT] provides an 535 example of how this can be done). 537 2.7. Transient 539 A Transient represents a binding between a Carrier and the instance 540 of the transport protocol stack that implements it. As an 541 Association contains long-term state for communications between two 542 endpoints, a Transient contains ephemeral state for a single 543 transport protocol over a single Path at a given point in time. 545 A Carrier may be served by multiple Transients at once, e.g. when 546 implementing multipath communication such that the separate paths are 547 exposed to the API by the underlying transport protocol stack. Each 548 Transient serves only one Carrier, although multiple Transients may 549 share the same underlying protocol stack; e.g. when multiplexing 550 Carriers over streams in a multistreaming protocol. 552 Transients are generally not exposed by the API to the application, 553 though they may be accessible for debugging and logging purposes. 555 2.8. Path 557 A Path represents information about a single path through the network 558 used by an Association, in terms of source and destination network 559 and transport layer addresses within an addressing context, and the 560 provisioning domain [RFC7556] of the local interface. This 561 information may be learned through a resolution, discovery, or 562 rendezvous process (e.g. DNS, ICE), by measurements taken by the 563 transport protocol stack, or by some other path information discovery 564 mechanism. It is used by the transport protocol stack to maintain 565 and/or (re-)establish communications for the Association. 567 The set of available properties is a function of the transport 568 protocol stacks in use by an association. However, the following 569 core properties are generally useful for applications and transport 570 layer protocols to choose among paths for specific Messages: 572 o Maximum Transmission Unit (MTU): the maximum size of an Message's 573 payload (subtracting transport, network, and link layer overhead) 574 which will likely fit into a single frame. Derived from signals 575 sent by path elements, where available, and/or path MTU discovery 576 processes run by the transport layer. 578 o Latency Expectation: expected one-way delay along the Path. 579 Generally provided by inline measurements performed by the 580 transport layer, as opposed to signaled by path elements. 582 o Loss Probability Expectation: expected probability of a loss of 583 any given single frame along the Path. Generally provided by 584 inline measurements performed by the transport layer, as opposed 585 to signaled by path elements. 587 o Available Data Rate Expectation: expected maximum data rate along 588 the Path. May be derived from passive measurements by the 589 transport layer, or from signals from path elements. 591 o Reserved Data Rate: Committed, reserved data rate for the given 592 Association along the Path. Requires a bandwidth reservation 593 service in the underlying transport protocol stack. 595 o Path Element Membership: Identifiers for some or all nodes along 596 the path, depending on the capabilities of the underlying network 597 layer protocol to provide this. 599 Path properties are generally read-only. MTU is a property of the 600 underlying link-layer technology on each link in the path; latency, 601 loss, and rate expectations are dynamic properties of the network 602 configuration and network traffic conditions; path element membership 603 is a function of network topology. In an explicitly multipath 604 architecture, application and transport layer requirements can be met 605 by having multiple paths with different properties to select from. 606 Transport protocol stacks can also provide signaling to devices along 607 the path, but this signaling is derived from information provided to 608 the Message abstraction. 610 3. Abstract Programming Interface 612 We now turn to the design of an abstract programming interface to 613 provide a simple interface to Post's abstractions, constrained by the 614 following design principles: 616 o Flexibility is paramount. So is simplicity. Applications must be 617 given as many controls and as much information as they may need, 618 but they must be able to ignore controls and information 619 irrelevant to their operation. This implies that the "default" 620 interface must be no more complicated than BSD sockets, and must 621 do something reasonable. 623 o Reception is an inherently asynchronous activity. While the API 624 is designed to be as platform-independent as possible, one key 625 insight it is based on is that an Message receiver's behavior in a 626 packet-switched network is inherently asynchronous, driven by the 627 receipt of packets, and that this asynchronicity must be reflected 628 in the API. The actual implementation of receive and event 629 handling will need to be aligned to the method a given platform 630 provides for asynchronous I/O. 632 o A new API cannot be bound to a single transport protocol and 633 expect wide deployment. As the API is transport-independent and 634 may support runtime transport selection, it must impose the 635 minimum possible set of constraints on its underlying transports, 636 though some API features may require underlying transport features 637 to work optimally. It must be possible to implement Post over 638 vanilla TCP in the present Internet architecture. 640 The API we design from these principles is centered around a Carrier, 641 which can be created actively via initiate() or passively via a 642 listen(); the latter creates a Listener from which new Carriers can 643 be accept()ed. Messages may be created explicitly and passed to this 644 Carrier, or implicitly through a simplified interface which uses 645 default message properties (reliable transport without priority or 646 deadline, which guarantees ordered delivery over a single Carrier 647 when the underlying transport protocol stack supports it). 649 For each connection between a Local and a Remote a new Carrier is 650 created and destroyed when the connection is closed. However, a new 651 Carrier may use an existing Association if present for the requested 652 Local-Remote pair and permitted by the PolicyContext that can be 653 provided at Carrier initiation. Further the system-wide 654 PolicyContext can contain more information that determine when to 655 create or destroy Associations other than at Carrier initiation. 656 E.g. an Association can be created at system start, based on the 657 configured PolicyContext or also by a manual action of an single 658 application, for Local-Remote pairs that are known to be likely used 659 soon, and to pre-establish, e.g., cryptographic context as well as 660 potentially collect current information about path capabilities. 661 Every time an actual connection with a specific PSI is established 662 between the Local and Remote, the Association learns new Path 663 information and stores them. This information can be used when a new 664 transient is created, e.g. to decide which PSI to use (to provide the 665 highest probably for a successful connection attempt) or which PSIs 666 to probe for (first). A Transient is created when an application 667 actually sends a Message over a Carrier. As further explained below 668 this step can actually create multiple transients for probing or 669 assign a new transient to an already active PSI, e.g. if multi- 670 streaming is provided and supported for these kind of use on both 671 sides. 673 3.1. Example Connection Patterns 675 Here, we illustrate the usage of the API for common connection 676 patterns. Note that error handling is ignored in these illustrations 677 for ease of reading. 679 3.1.1. Client-Server 681 Here's an example client-server application. The server echoes 682 messages. The client sends a message and prints what it receives. 684 The client in Figure 2 connects, sends a message, and sets up a 685 receiver to print messages received in response. The carrier is 686 inactive after the Initiate() call; the Send() call blocks until the 687 carrier can be activated. 689 // connect to a server given a remote 690 func sayHello() { 692 carrier := Initiate(local, remote) 694 carrier.Send([]byte("Hello!")) 695 carrier.Ready(func (msg InMessage) { 696 fmt.Println(string([]byte(msg)) 697 return false 698 }) 699 carrier.Close() 700 } 702 Figure 2: Example client 704 The server in Figure 3 creates a Listener, which accepts Carriers and 705 passes them to a server. The server echos the content of each 706 message it receives. 708 // run a server for a specific carrier, echo all its messages 709 func runMyServerOn(carrier Carrier) { 710 carrier.Ready(func (msg InMessage) { 711 carrier.Send(msg) 712 }) 713 } 715 // accept connections forever, spawn servers for them 716 func acceptConnections() { 717 listener := Listen(local) 718 listener.Accept(func(carrier Carrier) bool { 719 go runMyServerOn(carrier) 720 return true 721 }) 722 } 724 Figure 3: Example server 726 The Responder allows the server to be significantly simplified, as 727 shown in Figure 4. 729 func echo(msg InMessage, reply Sink) { 730 reply.Send(msg) 731 } 733 Respond(local, echo) 735 Figure 4: Example responder 737 3.1.2. Client-Server with Happy Eyeballs and 0-RTT establishment 739 The fundamental design of a client need not change at all for happy 740 eyeballs [RFC6555] (selection of multiple potential protocol stacks 741 through connection racing); this is handled by the Post Sockets 742 implementation automatically. If this connection racing is to use 743 0-RTT data (i.e., as provided by TCP Fast Open [RFC7413], the client 744 must mark the outgoing message as idempotent. 746 // connect to a server given a remote and send some 0-RTT data 747 func sayHelloQuickly() { 749 carrier := Initiate(local, remote) 751 carrier.SendMsg(OutMessage{Content: []byte("Hello!"), Idempotent: true}, nil, nil, nil) 752 carrier.Ready(func (msg InMessage) { 753 fmt.Println(string([]byte(msg))) 754 return false 755 }) 756 carrier.Close() 757 } 759 3.1.3. Peer to Peer with Network Address Translation 761 In the client-server examples shown above, the Remote given to the 762 Initiate call refers to the name and port of the server to connect 763 to. This need not be the case, however; a Remote may also refer to 764 an identity and a rendezvous point for rendezvous as in ICE 765 [RFC5245]. Here, each peer does its own Initiate call 766 simultaneously, and the result on each side is a Carrier attached to 767 an appropriate Association. 769 3.1.4. Multicast Receiver 771 A multicast receiver is implemented using a Sink attached to a Local 772 encapsulating a multicast address on which to receive multicast 773 datagrams. The following example prints messages received on the 774 multicast address forever. 776 func receiveMulticast() { 777 sink = NewSink(local) 778 sink.Ready(func (msg InMessage) { 779 fmt.Println(string([]byte(msg))) 780 return true 781 }) 782 } 784 3.2. Association Bootstrapping 786 Here, we show how Association state may be initialized without a 787 carrier. The goal is to create a long-term Association from which 788 Carriers may be derived and, if possible, used immediately. Per 789 [I-D.pauly-taps-transport-security], a first step is to specify trust 790 model constraints, such as pinned public keys and anchor 791 certificates, which are needed to create Remote connections. 793 We begin by creating shared security parameters that will be used 794 later for creating a remote connection. 796 // create security parameters with a set of trusted certificates 797 func createParameters(trustedCerts []Certificate) Parameters { 798 parameters := Parameters() 799 parameters = parameters.SetTrustedCerts(trustedCerts) 800 return parameters 801 } 803 Using these statically configured parameters, we now show how to 804 create an Association between a Local and Remote using these 805 parameters. 807 // create an Association using shared parameters 808 func createAssociation(local Local, remote Remote, parameters Parameters) Association { 809 association := AssociationWithParameters(local, remote, parameters) 810 return association 811 } 813 We may also create an Association with a pre-shared key configured 814 out-of-band. 816 // create an Association using a pre-shared key 817 func createAssociationWithPSK(local Local, remote Remote, parameters Parameters, preSharedKey []byte) Association { 818 association := AssociationWithParameters(local, remote, parameters) 819 association = association.SetPreSharedKey(preSharedKey) 820 return association 821 } 823 We now show how to create a Carrier from an existing, pre-configured 824 Association. This Association may or may not contain shared 825 cryptographic static between the Local and Remote, depending on how 826 it was configured. 828 // open a connection to a server using an existing Association and send some data, 829 // which will be sent early if possible. 830 func sayHelloWithAssociation(association Association) { 831 carrier := InitiateWithAssociation(association) 833 carrier.SendMsg(OutMessage{Content: []byte("Hello!"), Idempotent: true}, nil, nil, nil) 834 carrier.Ready(func (msg InMessage) { 835 fmt.Println(string([]byte(msg))) 836 return false 837 }) 838 carrier.Close() 839 } 841 4. Implementation Considerations 843 Here we discuss an incomplete list of API implementation 844 considerations that have arisen with experimentation with prototype 845 implementations of Post. 847 4.1. Protocol Stack Instance (PSI) 849 A PSI encapsulates an arbitrary stack of protocols (e.g., TCP over 850 IPv6, SCTP over DTLS over UDP over IPv4). PSIs provide the bridge 851 between the interface (Carrier) plus the current state (Transients) 852 and the implementation of a given set of transport services 853 [I-D.ietf-taps-transports]. 855 A given implementation makes one or more possible protocol stacks 856 available to its applications. Selection and configuration among 857 multiple PSIs is based on system-level or application policies, as 858 well as on network conditions in the provisioning domain in which a 859 connection is made. 861 +=========+ +=========+ +==========+ +==========+ 862 | Carrier | | Carrier | | Carrier | | Carrier | 863 +=========+ +=========+ +==========+ +==========+ 864 | | | | 865 +=========+ +=========+ +==========+ +==========+ 866 |Transient| |Transient| |Transient | |Transient | 867 +=========+ +=========+ +==========+ +==========+ 868 | \ / / \ 869 +=========+ +=========+ +=========+ +=========+ 870 | PSI | | PSI | | PSI | | PSI | 871 +===+-----++ +===+-----++ +===+-----++ ++-----+===+ 872 |TLS | |SCTP | |TLS | | TLS| 873 |TCP | |DTLS | |TCP | | TCP| 874 |IPv6 | |UDP | |IPv6 | | IPv4| 875 |802.3 | |IPv6 | |802.11| |802.11| 876 +------+ |802.3 | +------+ +------+ 877 +------+ 878 (a) Transient (b) Carrier multiplexing (c) Multiple candidates 879 bound to PSI over a multi-streaming racing during session 880 transport protocol establishment 882 Figure 5: Example Protocol Stack Instances 884 For example, Figure 5(a) shows a TLS over TCP stack, usable on most 885 network connections. Protocols are layered to ensure that the PSI 886 provides all the transport services required by the application. A 887 single PSI may be bound to multiple Carriers, as shown in 888 Figure 5(b): a multi-streaming transport protocol like QUIC or SCTP 889 can support one carrier per stream. Where multi-streaming transport 890 is not available, these carriers could be serviced by different PSIs 891 on different flows. On the other hand, multiple PSIs are bound to a 892 single transient during establishment, as shown in Figure 5(c). 893 Here, the losing PSI in a happy-eyeballs race will be terminated, and 894 the carrier will continue using the winning PSI. 896 4.2. Message Framing, Parsing, and Serialization 898 While some transports expose a byte stream abstraction, most higher 899 level protocols impose some structure onto that byte stream. That 900 is, the higher level protocol operates in terms of messages, protocol 901 data units (PDUs), rather than using unstructured sequences of bytes, 902 with each message being processed in turn. Protocols are specified 903 in terms of state machines acting on semantic messages, with parsing 904 the byte stream into messages being a necessary annoyance, rather 905 than a semantic concern. Accordingly, Post Sockets exposes a 906 message-based API to applications as the primary abstraction. 907 Protocols that deal only in byte streams, such as TCP, represent 908 their data in each direction as a single, long message. When framing 909 protocols are placed on top of byte streams, the messages used in the 910 API represent the framed messages within the stream. 912 There are other benefits of providing a message-oriented API beyond 913 framing PDUs that Post Sockets should provide when supported by the 914 underlying transport. These include: 916 o the ability to associate deadlines with messages, for transports 917 that care about timing; 919 o the ability to provide control of reliability, choosing what 920 messages to retransmit in the event of packet loss, and how best 921 to make use of the data that arrived; 923 o the ability to manage dependencies between messages, when some 924 messages may not be delivered due to either packet loss or missing 925 a deadline, in particular the ability to avoid (re-)sending data 926 that relies on a previous transmission that was never received. 928 All require explicit message boundaries, and application-level 929 framing of messages, to be effective. Once a message is passed to 930 Post Sockets, it can not be cancelled or paused, but prioritization 931 as well as lifetime and retransmission management will provide the 932 protocol stack with all needed information to send the messages as 933 quickly as possible without blocking transmission unnecessarily. 934 Post Sockets provides this by handling message, with known identity 935 (sequence numbers, in the simple case), lifetimes, niceness, and 936 antecedents. 938 Transport protocols such as SCTP provide a message-oriented API that 939 has similar features to those we describe. Other transports, such as 940 TCP, do not. To support a message oriented API, while still being 941 compatible with stream-based transport protocols, Post Sockets must 942 provide APIs for parsing and serialising messages that understand the 943 protocol data. That is, we push message parsing and serialisation 944 down into the Post Sockets stack, allowing applications to send and 945 receive strongly typed data objects (e.g., a receive call on an HTTP 946 Message Carrier should return an object representing the HTTP 947 response, with pre-parsed status code, headers, and any message body, 948 rather than returning a byte array that the application has to parse 949 itself). This is backwards compatible with existing protocols and 950 APIs, since the wire format of messages does not change, but gives a 951 Post Sockets stack additional information to allow it to make better 952 use of modern transport services. 954 The Post Sockets approach is therefore to raise the semantic level of 955 the transport API: applications should send and receive messages in 956 the form of meaningful, strongly typed, protocol data. Parsing and 957 serialising such messages should be a re-usable function of the 958 protocol stack instance not the application. This is well-suited to 959 implementation in modern systems languages, such as Swift, Go, Rust, 960 or C++, but can also be implemented with some loss of type safety in 961 C. 963 4.3. Message Size Limitations 965 Ideally, Messages can be of infinite size. However, protocol stacks 966 and protocol stack implementations may impose their own limits on 967 message sizing; For example, SCTP [RFC4960] and TLS 968 [I-D.ietf-tls-tls13] impose record size limitations of 64kB and 16kB, 969 respectively. Message sizes may also be limited by the available 970 buffer at the receiver, since a Message must be fully assembled by 971 the transport layer before it can be passed on to the application 972 layer. Since not every transport protocol stack implements the 973 signaling necessary to negotiate or expose message size limitations, 974 these are currently configured out of band, and are probably best 975 exposed through the policy context. 977 A truly infinite message service - e.g. large file transfer where 978 both endpoints have committed persistent storage to the message - is 979 probably best realized as a layer above Post Sockets, and may be 980 added as a new type of Message Carrier to a future revision of this 981 document. 983 4.4. Back-pressure 985 Regardless of how asynchronous reception is implemented, it is 986 important for an application to be able to apply receiver back- 987 pressure, to allow the protocol stack to perform receiver flow 988 control. Depending on how asynchronous I/O works in the platform, 989 this could be implemented by having a maximum number of concurrent 990 receive callbacks, or by bounding the maximum number of outstanding, 991 unread bytes at any given time, for example. 993 4.5. Associations, Transients, Racing, and Rendezvous 995 As the network has evolved, even the simple act of establishing a 996 connection has become increasingly complex. Clients now regularly 997 race multiple connections, for example over IPv4 and IPv6, to 998 determine which protocol to use. The choice of outgoing interface 999 has also become more important, with differential reachability and 1000 performance from multiple interfaces. Name resolution can also give 1001 different outcomes depending on the interface the query was issued 1002 from. Finally, but often most significantly, NAT traversal, relay 1003 discovery, and path state maintenance messages are an essential part 1004 of connection establishment, especially for peer-to-peer 1005 applications. 1007 Post Sockets accordingly breaks communication establishment down into 1008 multiple phases: 1010 o Gathering Locals 1012 The set of possible Locals is gathered. In the simple case, this 1013 merely enumerates the local interfaces and protocols, and 1014 allocates ephemeral source ports for transients. For example, a 1015 system that has WiFi and Ethernet and supports IPv4 and IPv6 might 1016 gather four candidate locals (IPv4 on Ethernet, IPv6 on Ethernet, 1017 IPv4 on WiFi, and IPv6 on WiFi) that can form the source for a 1018 transient. 1020 If NAT traversal is required, the process of gathering locals 1021 becomes broadly equivalent to the ICE candidate gathering phase 1022 [RFC5245]. The endpoint determines its server reflexive locals 1023 (i.e., the translated address of a local, on the other side of a 1024 NAT) and relayed locals (e.g., via a TURN server or other relay), 1025 for each interface and network protocol. These are added to the 1026 set of candidate locals for this association. 1028 Gathering locals is primarily an endpoint local operation, 1029 although it might involve exchanges with a STUN server to derive 1030 server reflexive locals, or with a TURN server or other relay to 1031 derive relayed locals. It does not involve communication with the 1032 remote. 1034 o Resolving the Remote 1036 The remote is typically a name that needs to be resolved into a 1037 set of possible addresses that can be used for communication. 1038 Resolving the remote is the process of recursively performing such 1039 name lookups, until fully resolved, to return the set of 1040 candidates for the remote of this association. 1042 How this is done will depend on the type of the Remote, and can 1043 also be specific to each local. A common case is when the Remote 1044 is a DNS name, in which case it is resolved to give a set of IPv4 1045 and IPv6 addresses representing that name. Some types of remote 1046 might require more complex resolution. Resolving the remote for a 1047 peer-to-peer connection might involve communication with a 1048 rendezvous server, which in turn contacts the peer to gain consent 1049 to communicate and retrieve its set of candidate locals, which are 1050 returned and form the candidate remote addresses for contacting 1051 that peer. 1053 Resolving the remote is _not_ a local operation. It will involve 1054 a directory service, and can require communication with the remote 1055 to rendezvous and exchange peer addresses. This can expose some 1056 or all of the candidate locals to the remote. 1058 o Establishing Transients 1060 The set of candidate locals and the set of candidate remotes are 1061 paired, to derive a priority ordered set of Candidate Paths that 1062 can potentially be used to establish a connection. 1064 Then, communication is attempted over each candidate path, in 1065 priority order. If there are multiple candidates with the same 1066 priority, then transient establishment proceeds simultaneously and 1067 uses the transient that wins the race to be established. 1068 Otherwise, transients establishment is sequential, paced at a rate 1069 that should not congest the network. Depending on the chosen 1070 transport, this phase might involve racing TCP connections to a 1071 server over IPv4 and IPv6 [RFC6555], or it could involve a STUN 1072 exchange to establish peer-to-peer UDP connectivity [RFC5245], or 1073 some other means. 1075 o Confirming and Maintaining Transients 1077 Once connectivity has been established, unused resources can be 1078 released and the chosen path can be confirmed. This is primarily 1079 required when establishing peer-to-peer connectivity, where 1080 connections supporting relayed locals that were not required can 1081 be closed, and where an associated signalling operation might be 1082 needed to inform middleboxes and proxies of the chosen path. 1083 Keep-alive messages may also be sent, as appropriate, to ensure 1084 NAT and firewall state is maintained, so the transient remains 1085 operational. 1087 By encapsulating these four phases of communication establishment 1088 into the PSI, Post Sockets aims to simplify application development. 1089 It can provide reusable implementations of connection racing for TCP, 1090 to enable happy eyeballs, that will be automatically used by all TCP 1091 clients, for example. With appropriate callbacks to drive the 1092 rendezvous signalling as part of resolving the remote, we believe a 1093 generic ICE implementation ought also to be possible. This procedure 1094 can even be repeated fully or partially during a connection to enable 1095 seamless hand-over and mobility within the network stack. 1097 5. Acknowledgments 1099 Many thanks to Laurent Chuat and Jason Lee at the Network Security 1100 Group at ETH Zurich for contributions to the initial design of Post 1101 Sockets. Thanks to Joe Hildebrand, Martin Thomson, and Michael Welzl 1102 for their feedback, as well as the attendees of the Post Sockets 1103 workshop in February 2017 in Zurich for the discussions, which have 1104 improved the design described herein. 1106 This work is partially supported by the European Commission under 1107 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 1108 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 1109 for Education, Research, and Innovation under contract no. 15.0268. 1110 This support does not imply endorsement. 1112 6. References 1114 6.1. Normative References 1116 [I-D.ietf-taps-transports] 1117 Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 1118 provided by IETF transport protocols and congestion 1119 control mechanisms", draft-ietf-taps-transports-14 (work 1120 in progress), December 2016. 1122 6.2. Informative References 1124 [I-D.ietf-quic-transport] 1125 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1126 and Secure Transport", draft-ietf-quic-transport-05 (work 1127 in progress), August 2017. 1129 [I-D.ietf-tls-tls13] 1130 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1131 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1132 July 2017. 1134 [I-D.iyengar-minion-protocol] 1135 Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire 1136 Protocol", draft-iyengar-minion-protocol-02 (work in 1137 progress), October 2013. 1139 [I-D.kuehlewind-taps-crypto-sep] 1140 Kuehlewind, M., Pauly, T., and C. Wood, "Separating Crypto 1141 Negotiation and Communication", draft-kuehlewind-taps- 1142 crypto-sep-00 (work in progress), July 2017. 1144 [I-D.pauly-taps-transport-security] 1145 Pauly, T. and C. Wood, "A Survey of Transport Security 1146 Protocols", draft-pauly-taps-transport-security-00 (work 1147 in progress), July 2017. 1149 [I-D.trammell-plus-abstract-mech] 1150 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1151 Layer under Endpoint Control", draft-trammell-plus- 1152 abstract-mech-00 (work in progress), September 2016. 1154 [I-D.trammell-plus-statefulness] 1155 Kuehlewind, M., Trammell, B., and J. Hildebrand, 1156 "Transport-Independent Path Layer State Management", 1157 draft-trammell-plus-statefulness-03 (work in progress), 1158 March 2017. 1160 [MinimaLT] 1161 Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and 1162 T. Lange, "MinimaLT, Minimal-latency Networking Through 1163 Better Security", May 2013. 1165 [NEAT] Grinnemo, K-J., Tom Jones, ., Gorry Fairhurst, ., David 1166 Ros, ., Anna Brunstrom, ., and . Per Hurtig, "Towards a 1167 Flexible Internet Transport Layer Architecture", June 1168 2016. 1170 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1171 RFC 793, DOI 10.17487/RFC0793, September 1981, 1172 . 1174 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1175 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1176 . 1178 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1179 (ICE): A Protocol for Network Address Translator (NAT) 1180 Traversal for Offer/Answer Protocols", RFC 5245, 1181 DOI 10.17487/RFC5245, April 2010, 1182 . 1184 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1185 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 1186 2012, . 1188 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1189 "TCP Extensions for Multipath Operation with Multiple 1190 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1191 . 1193 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1194 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1195 2014, . 1197 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1198 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1199 . 1201 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 1202 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 1203 . 1205 Appendix A. Open Issues 1207 This document is under active development; a list of current open 1208 issues is available at https://github.com/mami-project/draft- 1209 trammell-post-sockets/issues 1211 Authors' Addresses 1213 Brian Trammell 1214 ETH Zurich 1215 Gloriastrasse 35 1216 8092 Zurich 1217 Switzerland 1219 Email: ietf@trammell.ch 1221 Colin Perkins 1222 University of Glasgow 1223 School of Computing Science 1224 Glasgow G12 8QQ 1225 United Kingdom 1227 Email: csp@csperkins.org 1229 Tommy Pauly 1230 Apple Inc. 1231 1 Infinite Loop 1232 Cupertino, California 95014 1233 United States of America 1235 Email: tpauly@apple.com 1236 Mirja Kuehlewind 1237 ETH Zurich 1238 Gloriastrasse 35 1239 8092 Zurich 1240 Switzerland 1242 Email: mirja.kuehlewind@tik.ee.ethz.ch 1244 Chris Wood 1245 Apple Inc. 1246 1 Infinite Loop 1247 Cupertino, California 95014 1248 United States of America 1250 Email: cawood@apple.com