idnits 2.17.1 draft-trammell-spud-req-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 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 (October 19, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: April 21, 2016 October 19, 2015 7 Requirements for the design of a Substrate Protocol for User Datagrams 8 (SPUD) 9 draft-trammell-spud-req-01 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 April 21, 2016. 38 Copyright Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Functional Requirements . . . . . . . . . . . . . . . . . . . 5 60 5.1. Grouping of Packets (into "tubes") . . . . . . . . . . . 5 61 5.2. Endpoint to Path Signaling . . . . . . . . . . . . . . . 6 62 5.3. Path to Endpoint Signaling . . . . . . . . . . . . . . . 6 63 5.4. Tube Start and End Signaling . . . . . . . . . . . . . . 6 64 5.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 65 5.6. Authentication . . . . . . . . . . . . . . . . . . . . . 7 66 5.7. Proof a device is on-path . . . . . . . . . . . . . . . . 7 67 5.8. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.9. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Technical Requirements . . . . . . . . . . . . . . . . . . . 7 70 6.1. Middlebox Traversal . . . . . . . . . . . . . . . . . . . 8 71 6.2. Low Overhead in Network Processing . . . . . . . . . . . 8 72 6.3. Implementability in User-Space . . . . . . . . . . . . . 8 73 6.4. Incremental Deployability in an Untrusted, Unreliable 74 Environment . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.5. Protection against trivial abuse . . . . . . . . . . . . 8 76 6.6. No unnecessary restrictions on the superstrate . . . . . 9 77 6.7. Minimal additional start-up latency . . . . . . . . . . . 9 78 6.8. Minimal Header Overhead . . . . . . . . . . . . . . . . . 9 79 6.9. Minimal non-productive traffic . . . . . . . . . . . . . 9 80 6.10. Preservation of Security Properties . . . . . . . . . . . 10 81 6.11. Reliability, Fragmentation, and Duplication . . . . . . . 10 82 6.12. Interoperability with non-encapsulated superstrates . . . 10 83 7. Open questions and discussion . . . . . . . . . . . . . . . . 10 84 7.1. Tradeoffs in tube identifiers . . . . . . . . . . . . . . 11 85 7.2. Property binding . . . . . . . . . . . . . . . . . . . . 12 86 7.3. Tradeoffs in integrity protection . . . . . . . . . . . . 12 87 7.4. In-band, out-of-band, piggybacked, and interleaved 88 signaling . . . . . . . . . . . . . . . . . . . . . . . . 12 89 7.5. Continuum of trust among endpoints and middleboxes . . . 13 90 7.6. Discovery and capability exposure . . . . . . . . . . . . 13 91 7.7. Hard state vs. soft state . . . . . . . . . . . . . . . . 14 92 7.8. Tube vs. superstrate association lifetime . . . . . . . . 14 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 97 12. Informative References . . . . . . . . . . . . . . . . . . . 15 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 100 1. Motivation 102 A number of efforts to create new transport protocols or experiment 103 with new network behaviors have been built on top of UDP, as it 104 traverses firewalls and other middleboxes more readily than new 105 protocols do. Each such effort must, however, either manage its 106 flows within common middlebox assumptions for UDP or train the 107 middleboxes on the new protocol (thus losing the benefit of using 108 UDP). A common Substrate Protocol for User Datagrams (SPUD) would 109 allow each effort to re-use a set of shared methods for notifying 110 middleboxes of the flows' semantics, thus avoiding both the 111 limitations of current flow semantics and the need to re-invent the 112 mechanism for notifying the middlebox of the new semantics. 114 As a concrete example, it is common for some middleboxes to tear down 115 required state (such as NAT bindings) very rapidly for UDP flows. By 116 notifying the path that a particular transport using UDP maintains 117 session state and explicitly signals session start and stop using the 118 substrate, the using protocol may reduce or avoid the need for 119 heartbeat traffic. 121 This document defines a specific set of requirements for a SPUD 122 facility, based on analysis on a target set of applications to be 123 developed on SPUD developing experience with a prototype described in 124 [I-D.hildebrand-spud-prototype]. It is intended as the basis for 125 determining the next steps to make progress in this space, including 126 possibly chartering a working group for specific protocol engineering 127 work. 129 2. History 131 An outcome of the IAB workshop on Stack Evolution in a Middlebox 132 Internet (SEMI) [I-D.iab-semi-report], held in Zurich in January 133 2015, was a discussion on the creation of a substrate protocol to 134 support the deployment of new transport protocols in the Internet. 135 Assuming that a way forward for transport evolution in user space 136 would involve encapsulation in UDP datagrams, the workshop noted that 137 it may be useful to have a facility built atop UDP to provide minimal 138 signaling of the semantics of a flow that would otherwise be 139 available in TCP. At the very least, indications of first and last 140 packets in a flow may assist firewalls and NATs in policy decision 141 and state maintenance. This facility could also provide minimal 142 application-to- path and path-to-application signaling, though there 143 was less agreement about what should or could be signaled here. 144 Further transport semantics would be used by the protocol running 145 atop this facility, but would only be visible to the endpoints, as 146 the transport protocol headers themselves would be encrypted, along 147 with the payload, to prevent inspection or modification. This 148 encryption might be accomplished by using DTLS [RFC6347] as a 149 subtransport [I-D.huitema-tls-dtls-as-subtransport] or by other 150 suitable methods. 152 The Substrate Protocol for User Datagrams (SPUD) BoF was held at IETF 153 92 in Dallas in March 2015 to develop this concept further. It is 154 clear from discussion before and during the SPUD BoF that any 155 selective exposure of traffic metadata outside a relatively 156 restricted trust domain must be advisory, non-negotiated, and 157 declarative rather than imperative. This conclusion matches 158 experience with previous endpoint-to-middle and middle-to-endpoint 159 signaling approaches. As with other metadata systems, exposure of 160 specific elements must be carefully assessed for privacy risks and 161 the total of exposed elements must be so assessed. Each exposed 162 parameter should also be independently verifiable, so that each 163 entity can assign its own trust to other entities. Basic transport 164 over the substrate must continue working even if signaling is ignored 165 or stripped, to support incremental deployment. These restrictions 166 on vocabulary are discussed further in [stackevo-explicit-coop]. 167 This discussion includes privacy and trust concerns as well as the 168 need for strong incentives for middlebox cooperation based on the 169 information that are exposed. 171 3. Terminology 173 This document uses the following terms: 175 o Superstrate: : The transport protocol or protocol stack "above" 176 SPUD, that uses SPUD for explicit path cooperation and path 177 traversal. The superstrate usually consists of a security layer 178 (e.g. TLS, DTLS) and a transport protocol, or a transport 179 protocol with integrated security features, to protect headers and 180 payload above SPUD. 182 o Endpoint: : One end of a communication session, located on a 183 single node that is a source or destination of packets in that 184 session. In this document, this term may refer to either the SPUD 185 implementation at the endpoint, the superstrate implementation 186 running over SPUD, or the applications running over that 187 superstrate. 189 o Path: : The sequence of Internet Protocol nodes and links that a 190 given packet traverses from endpoint to endpoint. 192 o Middlebox: : As defined in [RFC3234], a middlebox is any 193 intermediary device performing functions other than the normal, 194 standard functions of an IP router on the datagram path between a 195 source host and destination host; e.g. making decisions about 196 forwarding behavior based on other than addressing information, 197 and/or modifying a packet before forwarding. 199 4. Use Cases 201 The primary use case for endpoint to path signaling, making use of 202 packet grouping, is the binding of limited related semantics (start, 203 ack, and stop) to a flow or a group of packets within a flow which 204 are semantically related in terms of the application or superstrate. 205 By explicitly signaling start and stop semantics, a flow allows 206 middleboxes to use those signals for setting up and tearing down 207 their relevant state (NAT bindings, firewall pinholes), rather than 208 requiring the middlebox to infer this state from continued traffic. 209 At best, this would allow the application to refrain from sending 210 heartbeat traffic, which might result in reduced radio utilization 211 and thus greater battery life on mobile platforms. 213 SPUD may also provide some facility for SPUD-aware nodes on the path 214 to signal some property of the path relative to a tube to the 215 endpoints and other SPUD- aware nodes on the path. The primary use 216 case for path to application signaling is parallel to the use of ICMP 217 [RFC0792], in that it describes a set of conditions (including 218 errors) that applies to the datagrams as they traverse the path. 219 This usage is, however, not a pure replacement for ICMP but a 220 "5-tuple ICMP" for error messages which should be application- 221 visible; these would traverse NATs in the same way as the traffic 222 related to it, and be deliverable to the application with appropriate 223 tube information. 225 5. Functional Requirements 227 The following requirements detail the services that SPUD must provide 228 to superstrates, endpoints, and middleboxes using SPUD. 230 5.1. Grouping of Packets (into "tubes") 232 Transport semantics and many properties of communication that 233 endpoints may want to expose to middleboxes are bound to flows or 234 groups of flows (five- tuples). SPUD must therefore provide a basic 235 facility for associating packets together (into what we call a 236 "tube", for lack of a better term) and associate information to these 237 groups of packets. Each packet in a SPUD "flow" (determined by 238 5-tuple) belongs to exactly one tube. Notionally, a tube consists of 239 a set of packets with a set of common properties, that should 240 therefore receive equivalent treatment from the network; these tubes 241 may or may not be related to separate semantic entities in the 242 superstrate (e.g. SCTP streams). 244 The simplest mechanisms for association involve the addition of an 245 identifier to each packet in a tube. Current thoughts on the 246 tradeoffs on requirements and constraints on this identifier space 247 are given in {{tradeoffs-in-tube- identifiers}}. 249 5.2. Endpoint to Path Signaling 251 SPUD must be able to provide information scoped to a tube from the 252 end- point(s) to all SPUD-aware nodes on the path about the packets 253 in that tube. Since it is implausible that an endpoint has pre- 254 existing trust relationships to all SPUD-aware middleboxes on a 255 certain path in the context of the Internet, SPUD must provide in- 256 band signaling. SPUD may in addition also offer mechanisms for out- 257 of-band signaling when appropriate. See {{in-band-out-of- band- 258 piggybacked-and-interleaved-signaling}} for more discussion. 260 5.3. Path to Endpoint Signaling 262 SPUD must be able to provide information from a SPUD-aware middlebox 263 to the endpoint. Though this information is not scoped to a tube in 264 the same way that endpoint to path signaling is, as the middleboxes 265 do not originate the packets in a tube, it is still associated with a 266 tube, in terms of "the properties of the path(s) this tube will 267 traverse". Path to endpoint signaling need not be in-band; see 268 Section 7.4 for more discussion. 270 5.4. Tube Start and End Signaling 272 SPUD must provide a facility for endpoints to signal that a tube has 273 started, that the start of the tube has been acknowledged and 274 accepted by the remote endpoint(s), and that a tube has ended and its 275 state can be forgotten by the path. Given unreliable signaling (see 276 Section 6.11) both endpoints and devices on the path must be 277 resilient to the loss of any of these signals. Specifically, 278 timeouts are still necessary to clean up stale state. See 279 Section 7.7 and Section 7.8 for more discussion on tube start and end 280 signaling. 282 5.5. Extensibility 284 SPUD must enable multiple new transport semantics and application/ 285 path declarations without requiring updates to SPUD implementations 286 in middleboxes. 288 5.6. Authentication 290 The basic SPUD protocol must not require any authentication or a 291 priori trust relationship between endpoints and middleboxes to 292 function. However, SPUD should interoperate with the presentation/ 293 exchange of authentication information in environments where a trust 294 relationship already exists, or can be easily established, either in- 295 band or out-of-band, and use this information where possible and 296 appropriate. 298 5.7. Proof a device is on-path 300 Devices may make assertions of network characteristics relevant to a 301 flow. One way these assertions can be assessed is by a demonstration 302 that the device making it is on-path to the flow and so could adjust 303 the characteristics to match the assertion. SPUD must therefore 304 allow endpoints to distinguish on- path devices from devices not on 305 the path. Network elements may also need to confirm that 306 application-to-path assertions are made by the source indicated in 307 the flow. In both cases, return routability (as in {{protection- 308 against- trivial-abuse}}) may offer one incrementally deployable 309 method of testing the topology to make this confirmation. 311 5.8. Integrity 313 SPUD must provide integrity protection of SPUD-encapsulated packets, 314 though the details of this integrity protection are still open; see 315 {{tradeoffs-in- integrity-protection}}. Endpoints should be able to 316 detect changes to headers SPUD uses for its own signaling (whether 317 due to error, accidental modification, or malicious modification), as 318 well as the injection of packets into a SPUD flow (defined by 319 5-tuple) or tube by nodes other than the remote endpoint. Integrity 320 protection of the superstrate is left up to the superstrate. 322 5.9. Privacy 324 SPUD must allow endpoints to control the amount of information 325 exposed to middleboxes, with the default being the minimum necessary 326 for correct functioning. 328 6. Technical Requirements 330 The following requirements detail the constraints on how the SPUD 331 facility must meet its functional requirements. 333 6.1. Middlebox Traversal 335 SPUD must be able to traverse middleboxes that are not SPUD-aware. 336 Therefore SPUD must be encapsulated in a transport protocol that is 337 known to be accepted on a large fraction of paths in the Internet, or 338 implement some form of probing to determine in advance which 339 transport protocols will be accepted on a certain path. This 340 encapsulation will require port numbers to support NAPT- connected 341 endpoints. UDP encapsulation is the only mechanism that meets these 342 requirements. 344 6.2. Low Overhead in Network Processing 346 SPUD must be low-overhead, specifically requiring very little effort 347 to recognize that a packet is a SPUD packet and to determine the tube 348 it is associated with. 350 6.3. Implementability in User-Space 352 To enable fast deployment SPUD and superstrates must be implementable 353 without requiring kernel replacements or modules on the endpoints, 354 and without having special privilege (root or "jailbreak") on the 355 endpoints. Usually all operating systems will allow a user to open a 356 UDP socket. This indicates UDP- based encapsulation, either 357 exclusively or as a mandatory-to-implement feature. 359 6.4. Incremental Deployability in an Untrusted, Unreliable Environment 361 SPUD must operate in the present Internet. In order to maximize 362 deployment, it should also be useful between endpoints even before 363 the deployment of middleboxes that understand it. The information 364 exposed over SPUD must provide incentives for adoption by both 365 endpoints and middleboxes, and must maximize privacy (by minimizing 366 information exposed). Further, SPUD must be robust to packet loss, 367 duplication and reordering by the underlying network service. SPUD 368 must work in multipath, multicast, and endpoint multi- homing 369 environments. 371 Incremental deployability likely requires limitations of the 372 vocabulary used in signaling, to ensure that each actor in a 373 nontrusted environment has incentives to participate in the signaling 374 protocol honestly; see {{stackevo- explicit-coop}} for more. 376 6.5. Protection against trivial abuse 378 Malicious background traffic is a serious problem for UDP- based 379 protocols due to the ease of forging source addresses in UDP together 380 with the only limited deployment of network egress filtering 382 [RFC2827]. Trivial abuse includes flooding and state exhaustion 383 attacks, as well as reflection and amplification attacks. SPUD must 384 provide minimal protection against this trivial abuse. This probably 385 implies that SPUD should provide: 387 o a proof of return routability, 389 o a feedback channel between endpoints, 391 o a method to probabilistically discriminiate legitimate SPUD 392 traffic from reflected malicious traffic, and 394 o mechanisms to protect against state exhaustion and other denial- 395 of-service attacks. 397 We note that return routability excludes use of a UDP source port 398 that does not accept traffic (i.e., for one-way communication, as is 399 commonly done for unidirectional UDP tunnels, e.g., MPLS in UDP 400 [RFC7510] as an entropy input.) 402 6.6. No unnecessary restrictions on the superstrate 404 Beyond those restrictions deemed necessary as common features of any 405 secure, responsible transport protocol (see Section 6.5), SPUD must 406 impose only minimal restrictions on the transport protocols it 407 encapsulates. However, to serve as a substrate, it is necessary to 408 factor out the information that middleboxes commonly rely on and 409 endpoints are commonly willing to expose. This information should be 410 included in SPUD, and might itself impose additional restrictions to 411 the superstrate. 413 6.7. Minimal additional start-up latency 415 SPUD should not introduce additional start-up latency for 416 superstrates. 418 6.8. Minimal Header Overhead 420 To avoid reducing network performance, the information and coding 421 used in SPUD should be designed to use the minimum necessary amount 422 of additional space in encapsulation headers. 424 6.9. Minimal non-productive traffic 426 SPUD should minimize additional non-productive traffic (e.g. 427 keepalives), and should provide mechanisms to allow its superstrates 428 to minimize their reliance on non-productive traffic. 430 6.10. Preservation of Security Properties 432 The use of SPUD must not weaken the security properties of the 433 superstrate. If the superstrate includes payload encryption for 434 confidentiality, for example, the use of SPUD must not allow deep 435 packet inspection systems to have access to the plaintext. While a 436 box along the path may indicate a particular flow is adminstratively 437 prohibited or why it is prohibited, SPUD itself must not be used to 438 negotiate the means to lift the prohibition. 440 6.11. Reliability, Fragmentation, and Duplication 442 As any information provided by SPUD is anyway opportunistic, SPUD 443 need not provide reliable signaling for the information associated 444 with a tube. Signals must be idempotent; all middleboxes and 445 endpoints must gracefully handle receiving duplicate signal 446 information. To avoid issues with fragment reassembly, all in-band 447 SPUD signaling information must fit within a single packet. Any 448 facilities requiring more than an MTU's worth of data in a single 449 signal should use an out-of-band method which does provide 450 reliability - this method may be an existing transport or 451 superstrate/SPUD combination, or a "minimal transport" defined by 452 SPUD for its own use. 454 6.12. Interoperability with non-encapsulated superstrates 456 It is presumed that "superstrate X with SPUD" is a distinct entity on 457 the wire from "superstrate X". The APIs the superstrate presents to 458 the application should be equivalent, and the two wire protocols 459 should be freely transcodeable between each other, with the caveat 460 that the variant without SPUD would not necessarily support features 461 enabling communication with the path. However, there is no 462 requirement that the headers the superstrate uses be the same in the 463 SPUD and non-SPUD variants. Headers that the superstrate chooses 464 always to expose to the path can therefore be encoded in the SPUD 465 layer but not appear in an upper-layer header. 467 7. Open questions and discussion 469 The preceding requirements reflect the present best understanding of 470 the authors of the functional and technical requirements on an 471 encapsulation-based protocol for common middlebox-endpoint 472 cooperation for superstrates. There remain a few large open 473 questions and points for discussion, detailed in the subsections 474 below. 476 7.1. Tradeoffs in tube identifiers 478 Grouping packets into tubes requires some sort of notional tube 479 identifier; for purposes of this discussion we will assume this 480 identifier to be a simple vector of N bits. The properties of the 481 tube identifier are subject to tradeoffs on the requirements for 482 privacy, security, ease of implementation, and header overhead 483 efficiency. 485 We first assume that the 5-tuple of source and destination IP 486 address, UDP (or other transport protocol) port, and IP protocol 487 identifier (17 for UDP) is used in the Internet as an existing flow 488 identifier, due to the widespread deployment of network address and 489 port translation. The question then arises whether tube identifiers 490 should be scoped to 5-tuples (i.e., a tube is identified by a 6-tuple 491 including the tube identifier) or should be separate, and presumed to 492 be globally unique. 494 If globally unique, N must be sufficiently large to minimize the 495 probability of collision among multiple tubes having the same 496 identifier along the same path during some period of time. A 128-bit 497 UUID [RFC4122] or an identifier generated using an equivalent 498 algorithm would be useful as such a globally- unique tube identifier. 499 An advantage of globally unique tube identifiers would be migration 500 of per-tube state across multiple five-tuples for mobility support in 501 multipath protocols. However, globally unique tube identifiers would 502 also introduce new possibilities for user and node tracking, with a 503 serious negative impact on privacy. This alone probably speaks 504 against using globally unique identifiers for SPUD. 506 In the case of 5-tuple-scoped identifiers, mobility must be supported 507 separately from the tube identification mechanism. This could be 508 specific to each superstrate (i.e., hidden from the path), or SPUD 509 could provide a general endpoint-to-path tube grouping signal to 510 allow an endpoint to explicitly expose the fact that one tube is 511 related to another to the path. Even in this case, N must still be 512 sufficiently large, and the bits in the identifier sufficiently 513 random, that possession of a valid tube ID implies that a node can 514 observe packets belonging to the tube. This reduces the chances of 515 success of blind packet injection attacks of packets with guessed 516 valid tube IDs. 518 When scoped to 5-tuples, the forward and backward directions of a 519 bidirectional flow probably have different tube IDs, since these will 520 necessarily take different paths and may interact with a different 521 set of middleboxes due to asymmetric routing. SPUD will therefore 522 require some facility to note that one tube is the "reverse" 523 direction of another, a general case of the tube grouping signal 524 above. 526 7.2. Property binding 528 Related to identifier scope is the scope of properties bound to SPUD 529 packets by endpoints. SPUD may support both per-tube properties as 530 well as per-packet properties. Properties signaled per packet reduce 531 state requirements at middleboxes, but also increase per-packet 532 overhead. It is likely that both types of property binding are 533 necessary, but the selection of which properties to bind how must be 534 undertaken carefully. It is also possible that SPUD will provide a 535 very limited set of per-packet signals (such as ECN) using flags in 536 the SPUD header, and require all more complicated properties to be 537 bound per- tube. 539 7.3. Tradeoffs in integrity protection 541 In order to protect the integrity of information carried by SPUD 542 against forging by malicious devices along the path, it would be 543 necessary to be able to authenticate the originator of that 544 information. We presume that the authentication of endpoints is a 545 generally desirable property, and to be handled by the superstrate; 546 in this case, SPUD may be able borrow that authentication to protect 547 the integrity of endpoint-originated information. 549 However, in the Internet, it is not in the general case possible for 550 the endpoint to authenticate every middlebox that might see packets 551 it sends and receives. In this case information produced by 552 middleboxes may enjoy less integrity protection than that produced by 553 endpoints. In addition, endpoint authentication of middleboxes and 554 vice-versa may be better conducted out-of- band (treating the 555 middlebox as an endpoint for the authentication protocol) than in- 556 band (treating the middlebox as a participant in a 3+ party 557 communication). 559 7.4. In-band, out-of-band, piggybacked, and interleaved signaling 561 Discussions about SPUD to date have focused on the possibility of in- 562 band signaling from endpoints to middleboxes and back - the signaling 563 channel happens on the same 5-tuple as the data carried by the 564 superstrate. However, there are a wide variety of potential 565 signaling arrangements: in-band signaling can be piggybacked (where 566 signaling happens on packets sent by the superstrate) and/or 567 interleaved (where SPUD and the superstrate each have their own 568 packets). Signaling can also be out-of-band (on a different five 569 tuple, or even over a completely different protocol). Out of band 570 signaling for path-to-endpoint information can use direct return, 571 allowing a device on the path to communicate directly with an 572 endpoint (i.e., as with ICMP). More discussion on the tradeoffs here 573 is given in [stackevo-explicit-coop]. 575 The tradeoffs here must be carefully weighed, and the final approach 576 may use a mix of all these communication patterns where SPUD provides 577 different signaling patterns for different situations. E.g., a 578 middlebox might need to generate out-of-band signals for error 579 messages or can provide requested information in-band and feedback 580 over the receiver if a minimum or maximum value from all SPUD-aware 581 middleboxes on path should be discovered. 583 7.5. Continuum of trust among endpoints and middleboxes 585 There are different security considerations for different security 586 contexts. The end-to-end context is one; anything that only needs to 587 be seen by the path shouldn't be exposed in SPUD, but rather by the 588 superstrate. There are multiple different types of end-to-middle 589 context based on levels of trust between end and middle - is the 590 middlebox on the same network as the endpoint, under control of the 591 same owner? Is there some contract between the application user and 592 the middlebox operator? SPUD should support different levels of 593 trust than the default ("untrusted, but presumed honest due to 594 limitations on the signaling vocabulary") and fully-authenticated; 595 how these points along the continuum are to be implemented and how 596 they relate to each other needs to be explored further. 598 7.6. Discovery and capability exposure 600 There are three open issues in discovery and capability exposure. 601 First, an endpoint needs to discover if the other communication 602 endpoint understands SPUD. Second, endpoints need to test whether 603 SPUD is potentially not usable along a path because of middleboxes 604 that block SPUD packets or strip the SPUD header. If such 605 impairments exist in the path, a SPUD sender needs to fall back to 606 some other approach to achieve the goals of the superstrate. Third, 607 endpoints might want to be able to discover SPUD-aware middleboxes 608 along the path, and to discover which parts of the vocabulary that 609 can be spoken by the endpoints are supported by those middleboxes as 610 well as the other communication endpoint, and vice versa. 612 In addition, endpoints may need to discover and negotiate which 613 superstrates are available for a given interaction. SPUD could 614 assist here. However, it is explicitly not a goal of SPUD to expose 615 information about the details of the superstrate to middleboxes. 617 7.7. Hard state vs. soft state 619 The initial thinking on signaling envisions "hard state" in 620 middleboxes that is established when the middlebox observes the start 621 of a SPUD tube and is torn down when the middlebox observes the end 622 (stop) of a SPUD tube. Such state can be abandoned as a result of 623 network topology changes (e.g., routing update in response to link or 624 node failure). An alternative is a "soft state" approach that 625 requires periodic refresh of state in middleboxes, but cleanly times 626 out and discards abandoned state. SPUD has the opportunity to use 627 different timeouts than the defaults that are required for current 628 NAT and firewall pinhole maintenance. Of course, applications will 629 still have to detect non-SPUD middleboxes that use shorter timers. 631 7.8. Tube vs. superstrate association lifetime 633 The requirements as presently defined use tube start and stop 634 signaling for two things: (1) setting up and tearing down state along 635 the path, and (2) signaling superstrate such as association startup, 636 acceptance, and teardown, which may have security implications. 637 These may require separate signaling. Specifically, if tube start 638 acknowledgement is to be used to provide explicit guarantees to the 639 path about the acceptability of a tube to a remote endpoint, it 640 cannot be a completely unreliable signal. Second, the lifetime of a 641 tube may be much shorter than the lifetime of a superstrate 642 association, and the creation of a new tube over an existing 643 association may need to be treated differently by endpoints and path 644 devices than a tube creation coincident with an association creation. 646 8. Security Considerations 648 The security-relevant requirements for SPUD deal mainly with endpoint 649 authentication and the integrity of exposed information (Section 5.6, 650 Section 5.8, Section 5.9, and Section 7.3); protection against 651 attacks (Section 5.7, Section 6.5, and Section 7.1 and); and the 652 trust relationships among endpoints and middleboxes Section 7.5. 653 These will be further addressed in protocol definition work following 654 from these requirements. 656 9. IANA Considerations 658 This document has no actions for IANA. 660 10. Contributors 662 In addition to the editors, this document is the work of David Black, 663 Ken Calvert, Ted Hardie, Joe Hildebrand, Jana Iyengar, and Eric 664 Rescorla. 666 11. Acknowledgments 668 Thanks to Roland Bless, Cameron Byrne, Toerless Eckert, Daniel Kahn 669 Gillmor, Tom Herbert, and Christian Huitema for feedback and comments 670 on these requirements, as well as to the participants at the SPUD BoF 671 at IETF 92 meeting in Dallas inand the IAB SEMI workshop in Zurich 672 for the discussions leading to this work. 674 12. Informative References 676 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 677 RFC 792, DOI 10.17487/RFC0792, September 1981, 678 . 680 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 681 Defeating Denial of Service Attacks which employ IP Source 682 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 683 May 2000, . 685 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 686 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 687 . 689 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 690 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 691 10.17487/RFC4122, July 2005, 692 . 694 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 695 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 696 January 2012, . 698 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 699 "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/ 700 RFC7510, April 2015, 701 . 703 [I-D.hildebrand-spud-prototype] 704 Hildebrand, J. and B. Trammell, "Substrate Protocol for 705 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 706 prototype-03 (work in progress), March 2015. 708 [I-D.huitema-tls-dtls-as-subtransport] 709 Huitema, C., Rescorla, E., and J. Jana, "DTLS as 710 Subtransport protocol", draft-huitema-tls-dtls-as- 711 subtransport-00 (work in progress), March 2015. 713 [stackevo-explicit-coop] 714 Trammell, B., "Architectural Considerations for Transport 715 Evolution with Explicit Path Cooperation", September 2015. 717 [I-D.iab-semi-report] 718 Trammell, B. and M. Kuehlewind, "IAB Workshop on Stack 719 Evolution in a Middlebox Internet (SEMI) Report", draft- 720 iab-semi-report-01 (work in progress), July 2015. 722 Authors' Addresses 724 Brian Trammell (editor) 725 ETH Zurich 726 Gloriastrasse 35 727 8092 Zurich 728 Switzerland 730 Email: ietf@trammell.ch 732 Mirja Kuehlewind (editor) 733 ETH Zurich 734 Gloriastrasse 35 735 8092 Zurich 736 Switzerland 738 Email: mirja.kuehlewind@tik.ee.ethz.ch