idnits 2.17.1 draft-trammell-spud-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (July 06, 2015) is 3216 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) == Outdated reference: A later version (-01) exists of draft-iab-semi-report-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: January 7, 2016 July 06, 2015 7 Requirements for the design of a Substrate Protocol for User Datagrams 8 (SPUD) 9 draft-trammell-spud-req-00 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 January 7, 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 1. Motivation 55 A number of efforts to create new transport protocols or experiment 56 with new network behaviors have been built on top of UDP, as it 57 traverses firewalls and other middleboxes more readily than new 58 protocols do. Each such effort must, however, either manage its 59 flows within common middlebox assumptions for UDP or train the 60 middleboxes on the new protocol (thus losing the benefit of using 61 UDP). A common Substrate Protocol for User Datagrams (SPUD) would 62 allow each effort to re-use a set of shared methods for notifying 63 middleboxes of the flows' semantics, thus avoiding both the 64 limitations of current flow semantics and the need to re-invent the 65 mechanism for notifying the middlebox of the new semantics. 67 As a concrete example, it is common for some middleboxes to tear down 68 required state (such as NAT bindings) very rapidly for UDP flows. By 69 notifying the path that a particular transport using UDP maintains 70 session state and explicitly signals session start and stop using the 71 substrate, the using protocol may reduce or avoid the need for 72 heartbeat traffic. 74 This document defines a specific set of requirements for a SPUD 75 facility, based on analysis on a target set of applications to be 76 developed on SPUD developing experience with a prototype described in 77 [I-D.hildebrand-spud-prototype]. It is intended as the basis for 78 determining the next steps to make progress in this space, including 79 eventually chartering an working group for specific protocol 80 engineering work. 82 2. History 84 An outcome of the IAB workshop on Stack Evolution in a Middlebox 85 Internet (SEMI) [I-D.iab-semi-report], held in Zurich in January 86 2015, was a discussion on the creation of a substrate protocol to 87 support the deployment of new transport protocols in the Internet. 88 Assuming that a way forward for transport evolution in user space 89 would involve encapsulation in UDP datagrams, the workshop noted that 90 it may be useful to have a facility built atop UDP to provide minimal 91 signaling of the semantics of a flow that would otherwise be 92 available in TCP. At the very least, indications of first and last 93 packets in a flow may assist firewalls and NATs in policy decision 94 and state maintenance. Further transport semantics would be used by 95 the protocol running atop this facility, but would only be visible to 96 the endpoints, as the transport protocol headers themselves would be 97 encrypted, along with the payload, to prevent inspection or 98 modification. This encryption might be accomplished by using DTLS 99 [RFC6347] as a subtransport [I-D.huitema-tls-dtls-as-subtransport] or 100 by other suitable methods. This facility could also provide minimal 101 application-to-path and path-to-application signaling, though there 102 was less agreement about what should or could be signaled here. 104 The Substrate Protocol for User Datagrams (SPUD) BoF was held at IETF 105 92 in Dallas in March 2015 to develop this concept further. It is 106 clear from discussion before and during the SPUD BoF that any 107 selective exposure of traffic metadata outside a relatively 108 restricted trust domain must be advisory, non-negotiated, and 109 declarative rather than imperative. This conclusion matches 110 experience with previous endpoint-to-middle and middle-to-endpoint 111 signaling approaches. As with other metadata systems, exposure of 112 specific elements must be carefully assessed for privacy risks and 113 the total of exposed elements must be so assessed. Each exposed 114 parameter should also be independently verifiable, so that each 115 entity can assign its own trust to other entities. Basic transport 116 over the substrate must continue working even if signaling is ignored 117 or stripped, to support incremental deployment. These restrictions 118 on vocabulary are discussed further in 119 [I-D.trammell-stackevo-newtea]. This discussion includes privacy and 120 trust concerns as well as the need for strong incentives for 121 middlebox cooperation based on the information that are exposed. 123 3. Terminology 125 This document uses the following terms 127 o Overlying transport: : A transport protocol that uses SPUD for 128 middlebox signaling and traversal. 130 o Endpoint: : A node that sends or receives a packet. In this 131 document, this term may refer to either the SPUD implementation on 132 this node, the overlying transport implementation on this node, or 133 the applications running over that overlying transport. 135 o Path: : The set of Internet Protocol nodes and links that a given 136 packet traverses from endpoint to endpoint. 138 o Middlebox: : A device on the path that makes decisions about 139 forwarding behavior based on other than IP or sub-IP addressing 140 information, and/or that modifies the packet before forwarding. 142 4. Use Cases 144 The primary use case for endpoint to path signaling, making use of 145 packet grouping, is the binding of limited related semantics (start- 146 tube and stop-tube) to a group of packets which are semantically 147 related in terms of the application or overlying transport. By 148 explicitly signaling start and stop semantics, a flow allows 149 middleboxes to use those signals for setting up and tearing down 150 their relevant state (NAT bindings, firewall pinholes), rather than 151 requiring the middlebox to infer this state from continued traffic. 152 At best, this would allow the application to refrain from sending 153 heartbeat traffic, which might result in reduced radio utilization 154 (and thus greater battery life) on mobile platforms. 156 SPUD may also provide some facility for SPUD-aware nodes on the path 157 to signal some property of the path relative to a tube to the 158 endpoints and other SPUD-aware nodes on the path. The primary use 159 case for path to application signaling is parallel to the use of ICMP 160 [RFC0792], in that it describes a set of conditions (including 161 errors) that applies to the datagrams as they traverse the path. 162 This usage is, however, not a pure replacement for ICMP but a 163 "5-tuple ICMP" which would traverse NATs in the same way as the 164 traffic related to it, and be deliverable to the application with 165 appropriate tube information. 167 [EDITOR'S NOTE: specific applications we think need this go here? 168 reference draft-kuehlewind-spud-use-cases.] 170 5. Functional Requirements 172 The following requirements detail the services that SPUD must provide 173 to overlying transports, endpoints, and middleboxes using SPUD. 175 5.1. Grouping of Packets 177 Transport semantics and many properties of communication that 178 endpoints may want to expose to middleboxes are bound to flows or 179 groups of flows (five-tuples). SPUD must therefore provide a basic 180 facility for associating packets together (into what we call a "tube" 181 ,for lack of a better term) and associate information to these groups 182 of packets. The simplest mechanisms for association would involve 183 the addition of an identifier to each packet in a tube. The tube ID 184 must be bi-directional to support state establishment and is scoped 185 to the forward and backward five-tuple due to privacy concern. 186 Current thoughts on the tradeoffs on requirements and constraints on 187 this identifier space are given in Section 7.1. 189 5.2. Endpoint to Path Signaling 191 SPUD must be able to provide information from the end-point(s) to all 192 SPUD-aware nodes on the path. To be able to potentially communicate 193 with all SPUD-aware middleboxes on the path SPUD must either be 194 designed as an in-band signaling protocol, or there must be a pre- 195 existing relationship between the endpoint and the SPUD-aware 196 middleboxes along the path. Since it is implausible that an endpoint 197 has these relationships to all SPUD-aware middleboxes on a certain 198 path in the context of the Internet, SPUD must provide in-band 199 signaling. SPUD may in addition also offer mechanisms for out-of- 200 band signaling when it is appropriate to use. See Section 7.5 for 201 more discussion. 203 5.3. Path to Endpoint Signaling 205 SPUD must be able to provide information from a SPUD-aware middlebox 206 to the endpoint. See Section 7.5 for more discussion on tradeoffs 207 here. 209 5.4. Extensibility 211 SPUD must enable multiple new transport semantics and application/ 212 path declarations without requiring updates to SPUD implementations 213 in middleboxes. 215 5.5. Authentication 217 The basic SPUD protocol must not require any authentication or a 218 priori trust relationship between endpoints and middleboxes to 219 function. However, SPUD should support the presentation/exchange of 220 authentication information in environments where a trust relationship 221 already exists, or can be easily established, either in-band or out- 222 of-band. 224 5.6. Integrity 226 SPUD must provide integrity protection of SPUD-encapsulated packets, 227 though the details of this integrity protection are still open; see 228 Section 7.3. At the very least, endpoints should be able to: 230 1. detect simple transmission errors over at least whatever headers 231 SPUD uses its own signaling. 233 2. detect packet modifications by non-SPUD-aware middleboxes along 234 the path 236 3. detect the injection of packets into a SPUD flow (defined by 237 5-tuple) or tube by nodes other than the remote endpoint. 239 The decision of how to handle integrity check failures other than 240 case (1) may be left up to the overlying transport. 242 5.7. Privacy 244 SPUD must allow endpoints to control the amount of information 245 exposed to middleboxes, with the default being the minimum necessary 246 for correct functioning. 248 6. Non-Functional Requirements 250 The following requirements detail the constraints on how the SPUD 251 facility must meet its functional requirements. 253 6.1. Middlebox Traversal 255 SPUD must be able to traverse middleboxes that are not SPUD-aware. 256 Therefore SPUD must be encapsulated in a transport protocol that is 257 known to be accepted on a large fraction of paths in the Internet, or 258 implement some form of probing to determine in advance which 259 transport protocols will be accepted on a certain path. 261 6.2. Low Overhead in Network Processing 263 SPUD must be low-overhead, specifically requiring very little effort 264 to recognize that a packet is a SPUD packet and to determine the tube 265 it is associated with. 267 6.3. Implementability in User-Space 269 To enable fast deployment SPUD and transports above SPUD must be 270 implementable without requiring kernel replacements or modules on the 271 endpoints, and without having special privilege (root or "jailbreak") 272 on the endpoints. Usually all operating systems will allow a user to 273 open a UDP socket. Therefore SPUD must provide an UDP-based 274 encapsulation, either exclusively or as a mandatory-to-implement 275 feature. 277 6.4. Incremental Deployability in an Untrusted, Unreliable Environment 279 SPUD must operate in the present Internet. In order to maximize 280 deployment, it should also be useful as an encapsulation between 281 endpoints even before the deployment of middleboxes that understand 282 it. The information exposed over SPUD must provide incentives for 283 adoption by both endpoints and middleboxes, and must maximize privacy 284 (by minimizing information exposed). Further, SPUD must be robust to 285 packet loss, duplication and reordering by the underlying network 286 service. SPUD must work in multipath, multicast, and endpoint multi- 287 homing environments. 289 Incremental deployability likely requires limitations of the 290 vocabulary used in signaling, to ensure that each actor in a 291 nontrusted environment has incentives to participate in the signaling 292 protocol honestly; see [I-D.trammell-stackevo-newtea] for more. 294 6.5. Minimum restriction on the overlying transport 296 SPUD must impose minimal restrictions on the transport protocols it 297 encapsulates. However, to serve as a substrate, it is necessary to 298 factor out the information that middleboxes commonly rely on and 299 endpoints are commonly willing to expose. This information should be 300 included in SPUD, and might itself impose additional restrictions to 301 the overlying transport. One example is that SPUD is likely to 302 impose at least return routability and the presence of a feedback 303 channel between endpoints, this being necessary for protection 304 against reflection, amplification, and trivial state exhaustion 305 attacks; see Section 7.4 for more. 307 6.6. Minimum Header Overhead 309 To avoid reducing network performance, the information and coding 310 used in SPUD should be designed to use the minimum necessary amount 311 of additional space in encapsulation headers. 313 6.7. No additional start-up latency 315 SPUD should not introduce additional start-up latency for overlying 316 transports. 318 6.8. Reliability and Duplication 320 As any information provided by SPUD is anyway opportunistic, we 321 assume for now that SPUD does not have to provide reliability and any 322 SPUD mechanism using SPUD information must handle duplication of 323 information. However, this decision also depends on the signal type 324 used by SPUD, as further discussed in Section 7.5, and currently 325 assumes that there are no SPUD information that would need to be 326 split over multiple packets. 328 7. Open questions and discussion 330 The preceding requirements reflect the present best understanding of 331 the authors of the functional and technical requirements on an 332 encapsulation-based protocol for common middlebox-endpoint 333 cooperation for overlying transports. There remain a few large open 334 questions and points for discussion, detailed in the subsections 335 below. 337 7.1. Tradeoffs in tube identifiers 339 Grouping packets into tubes requires some sort of notional tube 340 identifier; for purposes of this discussion we will assume this 341 identifier to be a simple vector of N bits. The properties of the 342 tube identifier are subject to tradeoffs on the requirements for 343 privacy, security, ease of implementation, and header overhead 344 efficiency. 346 We first assume that the 5-tuple of source and destination IP 347 address, UDP (or other transport protocol) port, and IP protocol 348 identifier (17 for UDP) is used in the Internet as an existing flow 349 identifier, due to the widespread deployment of network address and 350 port translation. The question then arises whether tube identifiers 351 should be scoped to 5-tuples (i.e., a tube is identified by a 6-tuple 352 including the tube identifier) or should be separate, and presumed to 353 be globally unique. 355 If globally unique, N must be sufficiently large to reduce to 356 negligibility the probability of collision among multiple tubes 357 having the same identifier along the same path during some period of 358 time. An advantage of globally unique tube identifiers is they allow 359 migration of per-tube state across multiple five-tuples for mobility 360 support in multipath protocols. However, globally unique tube 361 identifiers would also introduce new possibilities for user and node 362 tracking, with a serious negative impact on privacy. 364 In the case of 5-tuple-scoped identifiers, mobility must be supported 365 separately by each overlying transport. N must still be sufficiently 366 large, and the bits in the identifier sufficiently random, that 367 possession of a valid tube ID implies that a node can observe packets 368 belonging to the tube. This reduces the chances of success of blind 369 packet injection attacks of packets with guessed valid tube IDs. 371 Further using multiple tube identifiers within one 5-tuple also 372 raises some protocol design questions: Can one packet belong to 373 multiple tubes? Do all packets in a five-tuple flow have to belong 374 to one tube? Can/Must the backward flow have the same tube ID or a 375 different one? Especially at connection start-up, depending on the 376 semantics of the overlying transport protocol, there likely might be 377 only one packet to start multiple streams/tubes. Can this start 378 message signal multiple tube IDs at once or do we need an own start 379 message for each tube? Or is it in this case not possible to have 380 multiple tubes within one five-tuple? These questions have to be 381 further investigated based on the semantic of existing transport 382 protocols. The discussion in [I-D.ietf-dart-dscp-rtp] concerning use 383 of different QoS treatments within a single 5-tuple is related, e.g., 384 WebRTC multiplexing of multiple application layer flows onto a single 385 transport layer (5-tuple) flow. 387 7.2. Property binding 389 Related to identifier scope is the scope of properties bound to SPUD 390 packets by endpoints. SPUD may support both per-tube properties as 391 well as per-packet properties. Properties signaled per packet reduce 392 state requirements at middleboxes, but also increase per-packet 393 overhead. It is likely that both types of property binding are 394 necessary, but the selection of which properties to bind how must be 395 undertaken carefully. 397 7.3. Tradeoffs in integrity protection 399 In order to protect the integrity of information carried by SPUD 400 against trivial forging by malicious devices along the path, it is 401 necessary to be able to authenticate the originator of that 402 information. We presume that the authentication of endpoints is a 403 generally desirable property, and to be handled by the overlying 404 transport; in this case, SPUD can borrow that authentication to 405 protect the integrity of endpoint-originated information. 407 However, in the Internet, it is not in the general case possible for 408 the endpoint to authenticate every middlebox that might see packets 409 it sends and receives. In this case information produced by 410 middleboxes may enjoy less integrity protection than that produced by 411 endpoints. In addition, endpoint authentication of middleboxes and 412 vice-versa may be better conducted out-of- band (treating the 413 middlebox as an endpoint for the authentication protocol) than in- 414 band (treating the middlebox as a participant in a 3+ party 415 communication). 417 7.4. Return routability and feedback 419 We have identified a requirement to support as wide a range of 420 overlying transports as possible and feasible, in order to maximize 421 SPUD's potential for improving the evolvability of the transport 422 stack. 424 The ease of forging source addresses in UDP together with the only 425 limited deployment of network egress filtering [RFC2827] means that 426 UDP traffic presently lacks a return routability guarantee. This has 427 led in part to the present situation wherein UDP traffic may be 428 blocked by firewalls when not explicitly needed by an organization as 429 part of its Internet connectivity. In addition, to defend against 430 state exhaustion attacks on middleboxes, SPUD may need to see a first 431 packet in a reverse direction on a tube to consider that tube 432 acknowledged and valid. 434 Return routability is therefore a minimal property of any transport 435 that can be responsibly deployed at scale in the Internet. Therefore 436 SPUD should enforce bidirectional communication at start-up, whether 437 the overlying transport is bidirectional or not. This excludes use 438 of the UDP source port as an entropy input that does not accept 439 traffic (i.e., for one-way communication, as is commonly done for 440 unidirectional UDP tunnels, e.g., MPLS in UDP [RFC7510]). 442 7.5. In-band, out-of-band, piggybacked, and interleaved signaling 444 Discussions about SPUD to date have focused on the possibility of in- 445 band signaling from endpoints to middleboxes and back - the signaling 446 channel happens on the same 5-tuple as the data carried by the 447 overlying transport. This arrangement would have the advantage that 448 it does not require foreknowledge of the identity and addresses of 449 devices along the path by endpoints and vice versa, but does add 450 complexity to the signaling protocol. 452 In-band signaling can be either piggybacked on the overlying 453 transport or interleaved with it. Piggybacked signaling uses some 454 number of bits in each packet generated by the overlying transport to 455 achieve signaling. It requires either reducing the MTU available to 456 the overlying transport (and telling the overlying transport about 457 this MTU reduction, or relying on the overlying transport to use 458 PLPMTUD [RFC4821]), or opportunistically using bits between the 459 network-layer MTU and the bits actually used by the transport. 461 This is even more complicated in the case of middleboxes that wish to 462 add information to piggybacked-signaling packets, and may require the 463 endpoints to introduce "scratch space" in the packets for potential 464 middlebox signaling use, further increasing complexity and overhead. 465 In any case, a SPUD sender would effectively request SPUD information 466 from a middlebox that respectively the middlebox would be able to 467 insert the requested information into this place holder. 469 However, a SPUD using piggybacked signaling is at the mercy of the 470 overlying transport's transmission scheduler to actually decide when 471 to send packets. At the same time, piggybacked signaling has the 472 benefit that SPUD can use the overlying transport's reliability 473 mechanisms to meet any reliability requirements it has for its own 474 use (e.g. in key exchange). This would require SPUD to understand 475 the semantics of the overlying protocol but can reduce overhead. 476 Piggyback signaling is also the only way to achieve per-packet 477 signaling as in Section 7.2. 479 Interleaved signaling uses SPUD-only packets on the same 5-tuple with 480 the same tube identifier to achieve signaling. This reduces 481 complexity and sidesteps MTU problems, but is only applicable to per- 482 tube signaling. It also would require SPUD to provide its own 483 reliability mechanisms if per-tube signaling requires reliability, 484 and still needs to interact well with the overlying transport's 485 transmission scheduler. 487 Out-of-band signaling uses direct connections between endpoints and 488 middleboxes, separate from the overlying transport - connections that 489 are perhaps negotiated by in-band signaling. A key disadvantage here 490 is that out-of-band signaling packets may not take the same path as 491 the packets in the overlying transport and therefore connectivity 492 cannot be guaranteed. 494 Signaling of path-to-endpoint information, in the case that a 495 middlebox wants to signal something to the sender of the packet, 496 raises the added problem of either (1) requiring the middlebox to 497 send the information to the receiver for later reflection back to the 498 sender, which has the disadvantage of complexity, or (2) requiring 499 out-of-band direct signaling back to the sender, which in turn either 500 requires the middlebox to spoof the source address and port of the 501 receiver to ensure equivalent NAT treatment, or some other NAT- 502 traversal approach. 504 The tradeoffs here must be carefully weighed, and the final approach 505 may use a mix of all these communication patterns where SPUD provides 506 different signaling patterns for different use case. E.g., a 507 middlebox might need to generate out-of-band signals for error 508 messages or can provide requested information in-band and feedback 509 over the receiver if a minimum or maximum value from all SPUD-aware 510 middleboxes on path should be discovered. 512 7.6. Continuum of trust among endpoints and middleboxes 514 There are different security considerations for different security 515 contexts. The end-to-end context is one; anything that only needs to 516 be seen by the path shouldn't be exposed in SPUD, but rather by the 517 overlying transport. There are multiple different types of end-to- 518 middle context based on levels of trust between end and middle - is 519 the middlebox on the same network as the endpoint, under control of 520 the same owner? Is there some contract between the application user 521 and the middlebox operator? It may make sense for SPUD to support 522 different levels of trust than the default ("untrusted, but presumed 523 honest due to limitations on the signaling vocabulary") and fully- 524 authenticated; this needs to be explored further. 526 7.7. Discovery and capability exposure 528 There are three open issues in discovery and capability exposure. 529 First, an endpoint needs to discover if the other communication 530 endpoint understands SPUD. Second, endpoints need to test whether 531 SPUD is potentially not usable along a path because of middleboxes 532 that block SPUD packets or strip the SPUD header. If such 533 impairments exist in the path, a SPUD sender needs to fall back to 534 some other approach to achieve the goals of the overlying transport. 535 Third, endpoints might want to be able to discover SPUD-aware 536 middleboxes along the path, and to discover which parts of the 537 vocabulary that can be spoken by the endpoints are supported by those 538 middleboxes as well as the other communication endpoint, and vice 539 versa. 541 In addition, endpoints may need to discover and negotiate which 542 overlying transports are available for a given interaction. SPUD 543 could assist here. However, it is explicitly not a goal of SPUD to 544 expose information about the details of the overlying transport to 545 middleboxes. 547 7.8. Hard state vs. soft state 549 The initial thinking on signaling envisions "hard state" in 550 middleboxes that is established when the middlbox observes the start 551 of a SPUD tube and is torn down when the middlebox observes the end 552 (stop) of a SPUD tube. Such state can be abandoned as a result of 553 network topology changes (e.g., routing update in response to link or 554 node failure). An alternative is a "soft state" approach that 555 requires periodic refresh of state in middleboxes, but cleanly times 556 out and discards abandoned state. SPUD has the opportunity to use 557 different timeouts than the defaults that are required for current 558 NAT and firewall pinhole maintenance. Of course, applications will 559 still have to detect non-SPUD middleboxes that use shorter timers. 561 8. Security Considerations 563 The security-relevant requirements for SPUD deal mainly with endpoint 564 authentication and the integrity of exposed information (Section 5.5, 565 Section 5.6, Section 5.7, and Section 7.3); protection against 566 attacks (Section 7.1 and Section 7.4); and the trust relationships 567 among endpoints and middleboxes Section 7.6. These will be further 568 addressed in protocol definition work following from these 569 requirements. 571 9. IANA Considerations 573 This document has no actions for IANA. 575 10. Contributors 577 In addition to the editors, this document is the work of David Black, 578 Ken Calvert, Ted Hardie, Joe Hildebrand, Jana Iyengar, and Eric 579 Rescorla. 581 [EDITOR'S NOTE: make this a real contributor's section once we figure 582 out how to make kramdown do that...] 584 11. Informative References 586 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 587 RFC 792, September 1981. 589 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 590 Defeating Denial of Service Attacks which employ IP Source 591 Address Spoofing", BCP 38, RFC 2827, May 2000. 593 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 594 Discovery", RFC 4821, March 2007. 596 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 597 Security Version 1.2", RFC 6347, January 2012. 599 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 600 "Encapsulating MPLS in UDP", RFC 7510, April 2015. 602 [I-D.hildebrand-spud-prototype] 603 Hildebrand, J. and B. Trammell, "Substrate Protocol for 604 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 605 prototype-03 (work in progress), March 2015. 607 [I-D.huitema-tls-dtls-as-subtransport] 608 Huitema, C., Rescorla, E., and J. Jana, "DTLS as 609 Subtransport protocol", draft-huitema-tls-dtls-as- 610 subtransport-00 (work in progress), March 2015. 612 [I-D.trammell-stackevo-newtea] 613 Trammell, B., "Thoughts a New Transport Encapsulation 614 Architecture", draft-trammell-stackevo-newtea-01 (work in 615 progress), May 2015. 617 [I-D.iab-semi-report] 618 Trammell, B. and M. Kuehlewind, "IAB Workshop on Stack 619 Evolution in a Middlebox Internet (SEMI) Report", draft- 620 iab-semi-report-00 (work in progress), June 2015. 622 [I-D.ietf-dart-dscp-rtp] 623 Black, D. and P. Jones, "Differentiated Services 624 (DiffServ) and Real-time Communication", draft-ietf-dart- 625 dscp-rtp-10 (work in progress), November 2014. 627 Authors' Addresses 629 Brian Trammell (editor) 630 ETH Zurich 631 Gloriastrasse 35 632 8092 Zurich 633 Switzerland 635 Email: ietf@trammell.ch 637 Mirja Kuehlewind (editor) 638 ETH Zurich 639 Gloriastrasse 35 640 8092 Zurich 641 Switzerland 643 Email: mirja.kuehlewind@tik.ee.ethz.ch