idnits 2.17.1 draft-trammell-spud-req-02.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 an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2016) is 2960 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7510' is defined on line 825, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-01) exists of draft-kuehlewind-spud-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Trammell, Ed. 3 Internet-Draft M. Kuehlewind, Ed. 4 Intended status: Informational ETH Zurich 5 Expires: September 12, 2016 March 11, 2016 7 Requirements for the design of a Substrate Protocol for User Datagrams 8 (SPUD) 9 draft-trammell-spud-req-02 11 Abstract 13 The Substrate Protocol for User Datagrams (SPUD) BoF session at the 14 IETF 92 meeting in Dallas in March 2015 identified the potential need 15 for a UDP-based encapsulation protocol to allow explicit cooperation 16 with middleboxes while using new, encrypted transport protocols. 17 This document proposes an initial set of requirements for such a 18 protocol, and discusses tradeoffs to be made in further refining 19 these requirements. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 12, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Functional Requirements . . . . . . . . . . . . . . . . . . . 6 60 5.1. Grouping of Packets (into "tubes") . . . . . . . . . . . 6 61 5.2. Endpoint to Path Signaling . . . . . . . . . . . . . . . 7 62 5.3. Path to Endpoint Signaling . . . . . . . . . . . . . . . 8 63 5.4. Tube Start and End Signaling . . . . . . . . . . . . . . 8 64 5.5. Declarative signaling . . . . . . . . . . . . . . . . . . 8 65 5.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 9 69 6.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.4. Encrypted Feedback . . . . . . . . . . . . . . . . . . . 9 71 6.5. Preservation of Security Properties . . . . . . . . . . . 10 72 6.6. Proof a device is on-path . . . . . . . . . . . . . . . . 10 73 6.7. Protection against trivial abuse . . . . . . . . . . . . 10 74 7. Technical Requirements . . . . . . . . . . . . . . . . . . . 11 75 7.1. Middlebox Traversal . . . . . . . . . . . . . . . . . . . 11 76 7.2. Low Overhead in Network Processing . . . . . . . . . . . 11 77 7.3. Implementability in User-Space . . . . . . . . . . . . . 11 78 7.4. Incremental Deployability in an Untrusted, Unreliable 79 Environment . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.5. No unnecessary restrictions on the superstrate . . . . . 12 81 7.6. Minimal additional start-up latency . . . . . . . . . . . 12 82 7.7. Minimal header overhead . . . . . . . . . . . . . . . . . 12 83 7.8. Minimal non-productive traffic . . . . . . . . . . . . . 12 84 7.9. Endpoint control over reverse-path middlebox signaling . 13 85 7.10. Reliability, Fragmentation, MTU, and Duplication . . . . 13 86 7.11. Interoperability with non-encapsulated superstrates . . . 13 87 8. Open questions and discussion . . . . . . . . . . . . . . . . 14 88 8.1. Property binding . . . . . . . . . . . . . . . . . . . . 14 89 8.2. Tradeoffs in integrity protection . . . . . . . . . . . . 14 90 8.3. Piggybacked, interleaved, and reflected signaling . . . . 15 91 8.4. Continuum of trust among endpoints and middleboxes . . . 15 92 8.5. Discovery and capability exposure . . . . . . . . . . . . 15 93 8.6. Hard state vs. soft state . . . . . . . . . . . . . . . . 16 94 8.7. Tube vs. superstrate association lifetime . . . . . . . . 16 95 8.8. SPUD Support Discovery . . . . . . . . . . . . . . . . . 16 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 99 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 100 13. Informative References . . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Motivation 105 A number of efforts to create new transport protocols or experiment 106 with new network behaviors in the Internet have been built on top of 107 UDP, as it traverses firewalls and other middleboxes more readily 108 than new protocols do. Each such effort must, however, either manage 109 its flows within common middlebox assumptions for UDP or train the 110 middleboxes on the new protocol (thus losing the benefit of using 111 UDP). A common Substrate Protocol for User Datagrams (SPUD) would 112 allow each effort to re-use a set of shared methods for notifying 113 middleboxes of the flows' semantics, thus avoiding both the 114 limitations of current flow semantics and the need to re-invent the 115 mechanism for notifying the middlebox of the new semantics. 117 As a concrete example, it is common for some middleboxes to tear down 118 required state (such as NAT bindings) very rapidly for UDP flows. By 119 notifying the path that a particular transport using UDP maintains 120 session state and explicitly signals session start and stop using the 121 substrate, the using protocol may reduce or avoid the need for 122 heartbeat traffic. 124 This document defines a specific set of requirements for a SPUD 125 facility, based on analysis on a target set of applications to be 126 developed on SPUD developing experience with a prototype described in 127 [I-D.hildebrand-spud-prototype]. It is intended as the basis for 128 determining the next steps to make progress in this space, including 129 possibly chartering a working group for specific protocol engineering 130 work. 132 Within this document, requirements are presented as for a facility 133 implementable as an encapsulation protocol, atop which new transports 134 ("superstrates") can be built. Alternately, these could be viewed as 135 a set of requirements for future transport protocol development 136 without a layer separation between the transport and the superstrate. 138 The final intention of this work is to make it possible to define and 139 deploy new transport protocols that use encryption to protect their 140 own operation as well as the confidentiality, authenticity, 141 integrity, and linkability resistance of their payloads. The 142 accelerating deployment of encryption will render obsolete network 143 operations techniques that rely on packet inspection and modification 144 based upon assumptions about the protocols in use. This work will 145 allow the replacement the current regime of middlebox inspection and 146 modification of transport and application- layer headers and payload 147 with one that allows inspection only of information explicitly 148 exposed by the endpoints, and modification of such information only 149 under endpoint control. 151 2. History 153 An outcome of the IAB workshop on Stack Evolution in a Middlebox 154 Internet (SEMI) [RFC7663], held in Zurich in January 2015, was a 155 discussion on the creation of a substrate protocol to support the 156 deployment of new transport protocols in the Internet. Assuming that 157 a way forward for transport evolution in user space would involve 158 encapsulation in UDP datagrams, the workshop noted that it may be 159 useful to have a facility built atop UDP to provide minimal signaling 160 of the semantics of a flow that would otherwise be available in TCP. 161 At the very least, indications of first and last packets in a flow 162 may assist firewalls and NATs in policy decision and state 163 maintenance. This facility could also provide minimal application- 164 to- path and path-to-application signaling, though there was less 165 agreement about what should or could be signaled here. Further 166 transport semantics would be used by the protocol running atop this 167 facility, but would only be visible to the endpoints, as the 168 transport protocol headers themselves would be encrypted, along with 169 the payload, to prevent inspection or modification. This encryption 170 might be accomplished by using DTLS [RFC6347] as a subtransport 171 [I-D.huitema-tls-dtls-as-subtransport] or by other suitable methods. 173 The Substrate Protocol for User Datagrams (SPUD) BoF was held at IETF 174 92 in Dallas in March 2015 to develop this concept further. It is 175 clear from discussion before and during the SPUD BoF that any 176 selective exposure of traffic metadata outside a relatively 177 restricted trust domain must be advisory, non-negotiated, and 178 declarative rather than imperative. This conclusion matches 179 experience with previous endpoint-to-middle and middle-to-endpoint 180 signaling approaches. As with other metadata systems, exposure of 181 specific elements must be carefully assessed for privacy risks and 182 the total of exposed elements must be so assessed. Each exposed 183 parameter should also be independently verifiable, so that each 184 entity can assign its own trust to other entities. Basic transport 185 over the substrate must continue working even if signaling is ignored 186 or stripped, to support incremental deployment. These restrictions 187 on vocabulary are discussed further in 188 [I-D.trammell-stackevo-explicit-coop]. This discussion includes 189 privacy and trust concerns as well as the need for strong incentives 190 for middlebox cooperation based on the information that are exposed. 192 3. Terminology 194 This document uses the following terms: 196 o Superstrate: : The transport protocol or protocol stack "above" 197 SPUD, that uses SPUD for explicit path cooperation and path 198 traversal. The superstrate usually consists of a security layer 199 (e.g. TLS, DTLS) and a transport protocol, or a transport 200 protocol with integrated security features, to protect headers and 201 payload above SPUD. 203 o Endpoint: : One end of a communication session, located on a 204 single node that is a source or destination of packets in that 205 session. In this document, this term may refer to either the SPUD 206 implementation at the endpoint, the superstrate implementation 207 running over SPUD, or the applications running over that 208 superstrate. 210 o Path: : The sequence of Internet Protocol nodes and links that a 211 given packet traverses from endpoint to endpoint. 213 o Middlebox: : As defined in [RFC3234], a middlebox is any 214 intermediary device performing functions other than the normal, 215 standard functions of an IP router on the datagram path between a 216 source host and destination host; e.g. making decisions about 217 forwarding behavior based on other than addressing information, 218 and/or modifying a packet before forwarding. 220 4. Use Cases 222 The primary use case for endpoint to path signaling in the Internet, 223 making use of packet grouping, is the binding of limited related 224 semantics (start, ack, and stop) to a flow or a group of packets 225 within a flow which are semantically related in terms of the 226 application or superstrate. By explicitly signaling start and stop 227 semantics, a flow allows middleboxes to use those signals for setting 228 up and tearing down their relevant state (NAT bindings, firewall 229 pinholes), rather than requiring the middlebox to infer this state 230 from continued traffic. At best, this would allow the application to 231 refrain from sending heartbeat traffic, which might result in reduced 232 radio utilization and thus greater battery life on mobile platforms. 234 SPUD could also be used to provide information relevant for network 235 treatment for middleboxes as a replacement for deep packet inspection 236 for traffic classification purposes, rendered ineffective by 237 superstrate encryption. In this application, properties would be 238 expressed in terms of network-relevant parameters (intended 239 bandwidth, latency and loss sensitivity, etc.) as opposed to 240 application-relevant semantics. See 241 [I-D.trammell-stackevo-explicit-coop] for discussion on limitations 242 in signaling in untrusted environments. 244 SPUD may also provide some facility for SPUD-aware nodes on the path 245 to signal some property of the path relative to a tube to the 246 endpoints and other SPUD- aware nodes on the path. The primary use 247 case for path to application signaling is parallel to the use of ICMP 248 [RFC0792], in that it describes a set of conditions (including 249 errors) that applies to the datagrams as they traverse the path. 250 This usage is, however, not a pure replacement for ICMP but a 251 "5-tuple ICMP" for error messages which should be application- 252 visible; these would traverse NATs in the same way as the traffic 253 related to it, and be deliverable to the application with appropriate 254 tube information. 256 Link-layer characteristics of use to the transport layer (e.g., 257 whether a high-transient-delay, highly-buffered link such as LTE is 258 present on the path) could also be signaled using this path-to- 259 endpoint facility. 261 Further use cases are outlined in more detail in 262 [I-D.kuehlewind-spud-use-cases]. 264 5. Functional Requirements 266 The following requirements detail the services that SPUD must provide 267 to superstrates, endpoints, and middleboxes using SPUD. 269 5.1. Grouping of Packets (into "tubes") 271 Transport semantics and many properties of communication that 272 endpoints may want to expose to middleboxes are bound to flows or 273 groups of flows (five- tuples). SPUD must therefore provide a basic 274 facility for associating packets together (into what we call a 275 "tube", for lack of a better term) and associate information to these 276 groups of packets. Each packet in a SPUD "flow" (determined by 277 5-tuple) belongs to exactly one tube. Notionally, a tube consists of 278 a set of packets with a set of common properties, that should 279 therefore receive equivalent treatment from the network; these tubes 280 may or may not be related to separate semantic entities in the 281 superstrate (e.g. SCTP streams). 283 The simplest mechanisms for association involve the addition of an 284 identifier to each packet in a tube. Other mechanisms that don't 285 directly encode the identifier in a packet header, but instead 286 provide it in a way that it is simple to derive from other 287 information available in the packet at the endpoints and along the 288 path, are also possible. In any cases, for the purposes of this 289 requirement we treat this identifier as a simple vector of N bits. 290 The properties of the tube identifier are subject to tradeoffs on the 291 requirements for privacy, security, ease of implementation, and 292 header overhead efficiency. 294 In determining the optimal size and scope for this tube identifier, 295 we first assume that the 5-tuple of source and destination IP 296 address, UDP port, and IP protocol identifier (17 for UDP) is used in 297 the Internet as an existing flow identifier, due to the widespread 298 deployment of network address and port translation. We conclude that 299 SPUD tube IDs should be scoped to this 5-tuple. 301 While a globally-unique identifier would allow easier state 302 comparison and migration for mobility use cases, it would have two 303 serious disadvantages. First, N would need to be sufficiently large 304 to minimize the probability of collision among multiple tubes having 305 the same identifier along the same path during some period of time. 306 A 128-bit UUID [RFC4122] or an identifier of equivalent size 307 generated using an equivalent algorithm would probably be sufficient, 308 at the cost of 128 bits of header space in every packet. Second, 309 globally unique tube identifiers would also introduce new 310 possibilities for user and node tracking, with a serious negative 311 impact on privacy. We note that global identifiers for mobility, 312 when necessary to expose to the path, can be supported separately 313 from the tube identification mechanism, by using a generic tube- 314 grouping application-to-path signaling bound to the tube. 316 Even when tube IDs are scoped to 5-tuples, N must still be 317 sufficiently large, and the bits in the identifier sufficiently 318 random, that possession of a valid tube ID implies that a node can 319 observe packets belonging to the tube (see Section 6.6). This 320 reduces the chances of success of blind packet injection attacks of 321 packets with guessed valid tube IDs. 323 When scoped to 5-tuples, the forward and backward directions of a 324 bidirectional connection will have different tube IDs, since these 325 will necessarily take different paths and may interact with a 326 different set of middleboxes due to asymmetric routing. SPUD will 327 therefore require some facility to note that one tube is the 328 "reverse" direction of another, a general case of the tube grouping 329 signal above. 331 5.2. Endpoint to Path Signaling 333 SPUD must be able to provide information scoped to a tube from the 334 end- point(s) to all SPUD-aware nodes on the path about the packets 335 in that tube. We note that in-band signaling would meet this 336 requirement. 338 5.3. Path to Endpoint Signaling 340 SPUD must be able to provide information from a SPUD-aware middlebox 341 to the endpoint. This information is associated with a tube, in 342 terms of "the properties of the path(s) the packets in this tube will 343 traverse". Path-to- endpoint signaling must be made available to the 344 superstrate and/or the application at the endpoint. We note that in- 345 band signaling would meet this requirement. 347 5.4. Tube Start and End Signaling 349 SPUD must provide a facility for endpoints to signal that a tube has 350 started, that the start of the tube has been acknowledged and 351 accepted by the remote endpoint(s), and that a tube has ended and its 352 state can be forgotten by the path. Given unreliable signaling (see 353 Section 7.10) both endpoints and devices on the path must be 354 resilient to the loss of any of these signals. Specifically, 355 timeouts are still necessary to clean up stale state. See 356 Section 8.6 and Section 8.7 for more discussion on tube start and end 357 signaling. 359 5.5. Declarative signaling 361 All information signaled via SPUD is defined to be declarative (as 362 opposed to imperative). A SPUD endpoint must function correctly if 363 no middlebox along the path understands the signals it sends, or if 364 sent signals from middleboxes it does not understand. Likewise, a 365 SPUD-aware middlebox must function correctly if sent signals from 366 endpoints it does not understand, or in the absence of expected 367 signals from endpoints. 369 5.6. Extensibility 371 SPUD must enable multiple new transport semantics and application/ 372 path declarations without requiring updates to SPUD implementations 373 in middleboxes. 375 The use of SPUD for experimental signaling must be possible either 376 without the registration of codepoints or namespaces with IANA, or 377 with trivially easy (First Come, First Served [RFC5226] registration 378 of such codepoints. 380 6. Security Requirements 382 6.1. Privacy 384 SPUD must allow endpoints to control the amount of information 385 exposed to middleboxes, with the default being the minimum necessary 386 for correct functioning. This includes the cryptographic protection 387 of transport layer headers from inspection by devices on path, in 388 order to prevent ossification of these headers. 390 6.2. Authentication 392 The basic SPUD protocol must not require any authentication or a 393 priori trust relationship between endpoints and middleboxes to 394 function. However, SPUD should interoperate with the presentation/ 395 exchange of authentication information in environments where a trust 396 relationship already exists, or can be easily established, either in- 397 band or out-of-band, and use this information where possible and 398 appropriate. 400 Given the advisory nature of the signaling it supports, SPUD may also 401 support eventual authentication: authentication of a signal after the 402 reception of a packet after that containing the signal. 404 6.3. Integrity 406 SPUD must provide integrity protection of exposed information in 407 SPUD- encapsulated packets, though the details of this integrity 408 protection are still open; see Section 8.2. 410 Endpoints should be able to detect changes to headers SPUD uses for 411 its own signaling (whether due to error, accidental modification, or 412 malicious modification), as well as the injection of packets into a 413 SPUD flow (defined by 5-tuple) or tube by nodes other than the remote 414 endpoints. Errors and accidental modifications can be detected using 415 a simple checksum over the SPUD header, while detecting malicious 416 modifications requires cryptographic integrity protection. Similar 417 to Section 6.2, cryptographic integrity protection may also be 418 eventual. 420 Integrity protection of the superstrate is left up to the 421 superstrate. 423 6.4. Encrypted Feedback 425 Some use cases involve collecting information along a forward path 426 from a sending endpoint to a receiving endpoint. In cases where this 427 information is also useful to the sending endpoint, SPUD must provide 428 a feedback channel to communicate this information back to the 429 sender. As this information does not need to be exposed to the path, 430 this feedback channel should be encrypted for confidentiality and 431 authenticity, when available (see Section 6.2). 433 6.5. Preservation of Security Properties 435 The use of SPUD must not weaken the essential security properties of 436 the superstrate: confidentiality, integrity, authenticity, and 437 defense against linkability. If the superstrate includes payload 438 encryption for confidentiality, for example, the use of SPUD must not 439 allow deep packet inspection systems to have access to the plaintext. 440 Likewise, the use of SPUD must not create additional opportunities 441 for linkability not already existing in the superstrate. 443 With respect to access control, SPUD itself must not be used to 444 negotiate the means to lift administrative prohibition of certain 445 traffic, although it could be used to provide more useful information 446 why it is prohibited. 448 6.6. Proof a device is on-path 450 Devices may make assertions of network characteristics relevant to a 451 flow. One way these assertions can be assessed is by a demonstration 452 that the device making it is on-path to the flow and so could adjust 453 the characteristics to match the assertion. SPUD must therefore 454 allow endpoints to distinguish on- path devices from devices not on 455 the path. Network elements may also need to confirm that 456 application-to-path assertions are made by the source indicated in 457 the flow. In both cases, return routability (as in Section 6.7) may 458 offer one incrementally deployable method of testing the topology to 459 make this confirmation. 461 6.7. Protection against trivial abuse 463 Malicious background traffic is a serious problem for UDP-based 464 protocols due to the ease of forging source addresses in UDP together 465 with only limited deployment of network egress filtering [RFC2827]. 466 Trivial abuse includes flooding and state exhaustion attacks, as well 467 as reflection and amplification attacks. SPUD must provide minimal 468 protection against this trivial abuse. This probably implies that 469 SPUD should provide: 471 o a proof of return routability, that the endpoint identified by a 472 packet's source address receives packets sent to that address; 474 o a feedback channel between endpoints; 475 o a method to probabilistically discriminiate legitimate SPUD 476 traffic from reflected malicious traffic; and 478 o mechanisms to protect against state exhaustion and other denial- 479 of-service attacks. 481 We note that using a "magic number" or other pattern of bits in an 482 encapsulation-layer header not used in any widely deployed protocol 483 has the nice property that no existing node in the Internet can be 484 induced to reflect traffic containing it. This allows the magic 485 number to provide probabilistic assurance that a given packet is not 486 reflected, assisting in meeting this requirement. 488 7. Technical Requirements 490 The following requirements detail the constraints on how the SPUD 491 facility must meet its functional requirements. 493 7.1. Middlebox Traversal 495 SPUD, including all path-to-endpoint and endpoint-to-path signaling 496 as well as superstrate and superstrate payload, must be able to 497 traverse middleboxes and firewalls, including those that are not 498 SPUD-aware. Therefore SPUD must be encapsulated in a transport 499 protocol that is known to be accepted on a large fraction of paths in 500 the Internet, or implement some form of probing to determine in 501 advance which transport protocols will be accepted on a certain path. 502 This encapsulation will require port numbers to support endpoints 503 connected via network address and port translation (NAPT). We note 504 that UDP encapsulation would meet these requirements. 506 7.2. Low Overhead in Network Processing 508 SPUD must be low-overhead, specifically requiring very little effort 509 to recognize that a packet is a SPUD packet and to determine the tube 510 it is associated with. We note that a magic number as in Section 6.7 511 would also have a low probability of colliding with any non- SPUD 512 traffic, therefore meeting the recognition requirement. Tube 513 identifiers appearing directly in the encapsulation-layer header 514 would meet the tube association requirement. 516 7.3. Implementability in User-Space 518 To enable fast deployment SPUD and superstrates must be implementable 519 without requiring kernel replacements or modules on the endpoints, 520 and without having special privilege (such as is required for raw 521 packet transmission, i.e. root or "jailbreak") on the endpoints. We 522 note here that UDP would meet this requirement, as nearly all 523 operating systems and application development platforms allow a 524 userspace application to open UDP sockets. 526 7.4. Incremental Deployability in an Untrusted, Unreliable Environment 528 SPUD must operate in the present Internet. In order to maximize 529 deployment, it should also be useful between endpoints even before 530 the deployment of middleboxes that understand it. The information 531 exposed over SPUD must provide incentives for adoption by both 532 endpoints and middleboxes, and must maximize privacy (by minimizing 533 information exposed). Further, SPUD must be robust to packet loss, 534 duplication and reordering by the underlying network service. SPUD 535 must work in multipath, multicast, and endpoint multi- homing 536 environments. 538 Incremental deployability likely requires limitations of the 539 vocabulary used in signaling, to ensure that each actor in a non- 540 trusted environment has incentives to participate in the signaling 541 protocol honestly; see [I-D.trammell-stackevo-explicit-coop] for 542 more. 544 7.5. No unnecessary restrictions on the superstrate 546 Beyond those restrictions deemed necessary as common features of any 547 secure, responsible transport protocol (see Section 6.7), SPUD must 548 impose only minimal restrictions on the transport protocols it 549 encapsulates. However, to serve as a substrate, it is necessary to 550 factor out the information that middleboxes commonly rely on and 551 endpoints are commonly willing to expose. This information should be 552 included in SPUD, and might itself impose additional restrictions to 553 the superstrate. 555 7.6. Minimal additional start-up latency 557 SPUD should not introduce additional start-up latency for 558 superstrates. 560 7.7. Minimal header overhead 562 To avoid reducing network performance, the information and coding 563 used in SPUD should be designed to use the minimum necessary amount 564 of additional space in encapsulation headers. 566 7.8. Minimal non-productive traffic 568 SPUD should minimize additional non-productive traffic (e.g. 569 keepalives), and should provide mechanisms to allow its superstrates 570 to minimize their reliance on non-productive traffic. 572 7.9. Endpoint control over reverse-path middlebox signaling 574 In some cases, a middlebox may need to send a packet directly in 575 response to a sending endpoint, e.g. to signal an error condition. 576 In this case, the direct return packet generated by the middlebox 577 uses the reversed end-to-end 5-tuple in order to receive equivalent 578 NAT treatment, though the reverse path might not be the same as the 579 forward path. Endpoints have control over this feature: A SPUD-aware 580 middlebox must not emit a direct return packet unless it is in direct 581 response to a packet from a receiving endpoint, and must not forward 582 a packet for which it has sent a direct return packet. 584 7.10. Reliability, Fragmentation, MTU, and Duplication 586 As any information provided by SPUD is anyway opportunistic, SPUD 587 need not provide reliable signaling for the information associated 588 with a tube. Signals must be idempotent; all middleboxes and 589 endpoints must gracefully handle receiving duplicate signal 590 information. SPUD must continue working in the presence of IPv4 591 fragmentation on path, but in order to reduce the impact of requiring 592 fragments reassembly at middleboxes for signals to be intelligible, 593 endpoints using SPUD should attempt to fit all signals into single 594 MTU-sized packets. 596 Given the importance of good path MTU information to SPUD's own 597 signaling, SPUD should implement packetization layer path MTU 598 discovery [RFC4821]. 600 Any facilities requiring more than an MTU's worth of data in a single 601 signal should use an out-of-band method which does provide 602 reliability - this method may be an existing transport or 603 superstrate/SPUD combination, or a "minimal transport" defined by 604 SPUD for its own use. 606 7.11. Interoperability with non-encapsulated superstrates 608 It is presumed that "superstrate X with SPUD" is a distinct entity on 609 the wire from "superstrate X". The APIs the superstrate presents to 610 the application should be equivalent, and the two wire protocols 611 should be freely transcodeable between each other, with the caveat 612 that the variant without SPUD would not necessarily support features 613 enabling communication with the path. However, there is no 614 requirement that the headers the superstrate uses be the same in the 615 SPUD and non-SPUD variants. Headers that the superstrate chooses 616 always to expose to the path can therefore be encoded in the SPUD 617 layer but not appear in an upper-layer header. 619 8. Open questions and discussion 621 The preceding requirements reflect the present best understanding of 622 the authors of the functional and technical requirements on an 623 encapsulation-based protocol for common middlebox-endpoint 624 cooperation for superstrates. There remain a few large open 625 questions and points for discussion, detailed in the subsections 626 below. 628 8.1. Property binding 630 Related to identifier scope is the scope of properties bound to SPUD 631 packets by endpoints. SPUD may support both per-tube properties as 632 well as per-packet properties. Properties signaled per packet reduce 633 state requirements at middleboxes, but also increase per-packet 634 overhead. Small signal size (in bits of entropy) and encoding 635 efficiency (in bits on the wire) is therefore more important for per- 636 packet signaling that per-tube signaling. 638 It is likely that both types of property binding are useful, but the 639 selection of which properties to bind how must be undertaken 640 carefully. It is also possible that SPUD will provide a very limited 641 set of per-packet signals (such as ECN) using flags in the SPUD 642 header, and require all more complicated properties to be bound per- 643 tube. 645 8.2. Tradeoffs in integrity protection 647 In order to protect the integrity of information carried by SPUD 648 against forging by malicious devices along the path, it would be 649 necessary to be able to authenticate the originator of that 650 information. We presume that the authentication of endpoints is a 651 generally desirable property, and to be handled by the superstrate; 652 in this case, SPUD may be able borrow that authentication to protect 653 the integrity of endpoint-originated information. 655 However, in the Internet, it is not in the general case possible for 656 the endpoint to authenticate every middlebox that might see packets 657 it sends and receives. In this case information produced by 658 middleboxes may enjoy less integrity protection than that produced by 659 endpoints. In addition, endpoint authentication of middleboxes and 660 vice-versa may be better conducted out-of- band (treating the 661 middlebox as an endpoint for the authentication protocol) than in- 662 band (treating the middlebox as a participant in a 3+ party 663 communication). 665 8.3. Piggybacked, interleaved, and reflected signaling 667 The requirements in Section 5.2 and Section 5.3 are best met by in- 668 band signaling: packets carrying the same 6-tuple as packets 669 containing superstrate headers and payload. 671 Path-to-endpoint signaling can be piggybacked and/or interleaved 672 (where SPUD and the superstrate each have their own packets). 674 In-band signaling has the advantage that it does not require 675 foreknowledge of the identity and addresses of devices along the path 676 by endpoints and vice versa, but does add complexity to the signaling 677 protocol. Piggybacked signaling uses some number of bits in each 678 packet generated by the overlying transport. It requires either 679 reducing the MTU available to the encapsulated transport and/or 680 opportunistically using "headroom" as it is available: bits between 681 the network-layer MTU and the bits actually used by the transport. 682 For use cases that accumulate information from devices on path in the 683 SPUD header, piggybacked signaling also requires a mechanism for 684 endpoints to create "scratch space" for potential use of the on-path 685 devices. In contrast, interleaved signaling uses signaling packets 686 on the same 5-tuple and tube ID, which don't carry any superstrate 687 data. These interleaved packets can also contain scratch space for 688 on-path device use. This reduces complexity and sidesteps MTU 689 problems, at the cost of sending more packets per flow. 691 8.4. Continuum of trust among endpoints and middleboxes 693 There are different security considerations for different security 694 contexts. The end-to-end context is one; anything that only needs to 695 be seen by the path shouldn't be exposed in SPUD, but rather by the 696 superstrate. There are multiple different types of end-to-middle 697 context based on levels of trust between end and middle - is the 698 middlebox on the same network as the endpoint, under control of the 699 same owner? Is there some contract between the application user and 700 the middlebox operator? SPUD should support different levels of 701 trust than the default ("untrusted, but presumed honest due to 702 limitations on the signaling vocabulary") and fully-authenticated; 703 how these points along the continuum are to be implemented and how 704 they relate to each other needs to be explored further. 706 8.5. Discovery and capability exposure 708 There are two open issues in discovery and capability exposure. 709 First, endpoints might want to be able to discover SPUD-aware 710 middleboxes along the path, and to discover which parts of the 711 vocabulary that can be spoken by the endpoints are supported by those 712 middleboxes as well as the other communication endpoint, and vice 713 versa. Second, SPUD coult assist endpoints in discovering and 714 negotiate which superstrates are available for a given interaction, 715 though it is explicitly not a goal of SPUD to expose information 716 about the details of the superstrate to middleboxes. 718 8.6. Hard state vs. soft state 720 The initial thinking on signaling envisions "hard state" in 721 middleboxes that is established when the middlebox observes the start 722 of a SPUD tube and is torn down when the middlebox observes the end 723 (stop) of a SPUD tube. Such state can be abandoned as a result of 724 network topology changes (e.g., routing update in response to link or 725 node failure). An alternative is a "soft state" approach that 726 requires periodic refresh of state in middleboxes, but cleanly times 727 out and discards abandoned state. SPUD has the opportunity to use 728 different timeouts than the defaults that are required for current 729 NAT and firewall pinhole maintenance. Of course, applications will 730 still have to detect non-SPUD middleboxes that use shorter timers. 732 8.7. Tube vs. superstrate association lifetime 734 The requirements as presently defined use tube start and stop 735 signaling for two things: (1) setting up and tearing down state along 736 the path, and (2) signaling superstrate such as association startup, 737 acceptance, and teardown, which may have security implications. 738 These may require separate signaling. Specifically, if tube start 739 acknowledgment is to be used to provide explicit guarantees to the 740 path about the acceptability of a tube to a remote endpoint, it 741 cannot be a completely unreliable signal. Second, the lifetime of a 742 tube may be much shorter than the lifetime of a superstrate 743 association, and the creation of a new tube over an existing 744 association may need to be treated differently by endpoints and path 745 devices than a tube creation coincident with an association creation. 747 8.8. SPUD Support Discovery 749 If SPUD is not usable on a path to an endpoint, a SPUD sender needs 750 to be able to fall back to some other approach to achieve the goals 751 of the superstrate; a SPUD endpoint must be able to easily determine 752 whether a remote endpoint with which it wants to communicate using 753 SPUD as a substrate can support SPUD, and whether path to the remote 754 endpoint as well as the return path from the remote endpoint will 755 pass SPUD packets. 757 It is not clear whether this is a requirement of SPUD, or a 758 requirement of the superstrate / application over SPUD. 760 9. Security Considerations 762 The security-relevant requirements for SPUD are outlined in 763 Section 6. In addition, security-relevant open issues are discussed 764 in Section 8.2 and Section 8.4. These will be further addressed in 765 protocol definition work following from these requirements. 767 10. IANA Considerations 769 This document has no actions for IANA. 771 11. Contributors 773 In addition to the editors, this document is the work of David Black, 774 Ken Calvert, Ted Hardie, Joe Hildebrand, Jana Iyengar, and Eric 775 Rescorla. 777 12. Acknowledgments 779 Thanks to Ozgu Alay, Roland Bless, Cameron Byrne, Toerless Eckert, 780 Gorry Fairhurst, Daniel Kahn Gillmor, Tom Herbert, Christian Huitema, 781 Iain Learmonth, Diego Lopez, and Matteo Varvelli for feedback and 782 comments on these requirements, as well as to the participants at the 783 SPUD BoF at IETF 92 meeting in Dallas and the IAB SEMI workshop in 784 Zurich for the discussions leading to this work. 786 This work is supported by the European Commission under Horizon 2020 787 grant agreement no. 688421 Measurement and Architecture for a 788 Middleboxed Internet (MAMI), and by the Swiss State Secretariat for 789 Education, Research, and Innovation under contract no. 15.0268. This 790 support does not imply endorsement. 792 13. Informative References 794 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 795 RFC 792, DOI 10.17487/RFC0792, September 1981, 796 . 798 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 799 Defeating Denial of Service Attacks which employ IP Source 800 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 801 May 2000, . 803 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 804 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 805 . 807 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 808 Unique IDentifier (UUID) URN Namespace", RFC 4122, 809 DOI 10.17487/RFC4122, July 2005, 810 . 812 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 813 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 814 . 816 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 817 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 818 DOI 10.17487/RFC5226, May 2008, 819 . 821 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 822 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 823 January 2012, . 825 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 826 "Encapsulating MPLS in UDP", RFC 7510, 827 DOI 10.17487/RFC7510, April 2015, 828 . 830 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 831 IAB Workshop on Stack Evolution in a Middlebox Internet 832 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 833 . 835 [I-D.hildebrand-spud-prototype] 836 Hildebrand, J. and B. Trammell, "Substrate Protocol for 837 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 838 prototype-03 (work in progress), March 2015. 840 [I-D.kuehlewind-spud-use-cases] 841 Kuehlewind, M. and B. Trammell, "SPUD Use Cases", draft- 842 kuehlewind-spud-use-cases-00 (work in progress), July 843 2015. 845 [I-D.huitema-tls-dtls-as-subtransport] 846 Huitema, C., Rescorla, E., and J. Jana, "DTLS as 847 Subtransport protocol", draft-huitema-tls-dtls-as- 848 subtransport-00 (work in progress), March 2015. 850 [I-D.trammell-stackevo-explicit-coop] 851 Trammell, B., "Architectural Considerations for Transport 852 Evolution with Explicit Path Cooperation", draft-trammell- 853 stackevo-explicit-coop-00 (work in progress), September 854 2015. 856 Authors' Addresses 858 Brian Trammell (editor) 859 ETH Zurich 860 Gloriastrasse 35 861 8092 Zurich 862 Switzerland 864 Email: ietf@trammell.ch 866 Mirja Kuehlewind (editor) 867 ETH Zurich 868 Gloriastrasse 35 869 8092 Zurich 870 Switzerland 872 Email: mirja.kuehlewind@tik.ee.ethz.ch