idnits 2.17.1 draft-trammell-stackevo-explicit-coop-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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 92: '... devices on path MUST NOT use or modif...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2015) is 3138 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6347' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-taps-transports' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'I-D.hildebrand-spud-prototype' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'I-D.huitema-tls-dtls-as-subtransport' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC7510' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'I-D.trammell-stackevo-newtea' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'I-D.iab-semi-report' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dart-dscp-rtp' is defined on line 539, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-14 == Outdated reference: A later version (-14) exists of draft-ietf-taps-transports-06 == Outdated reference: A later version (-03) exists of draft-baker-6man-hbh-header-handling-02 == Outdated reference: A later version (-04) exists of draft-trammell-spud-req-00 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 4 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 ETH Zurich 4 Intended status: Informational September 23, 2015 5 Expires: March 26, 2016 7 Architectural Considerations for Transport Evolution with Explicit Path 8 Cooperation 9 draft-trammell-stackevo-explicit-coop-00 11 Abstract 13 The IAB Stack Evolution in a Middlebox Internet (SEMI) workshop in 14 Zurich in January 2015 and the follow-up Substrate Protocol for User 15 Datagrams (SPUD) BoF session at the IETF 92 meeting in Dallas in 16 March 2015 identified the potential need for a UDP-based 17 encapsulation to allow explicit cooperation with middleboxes while 18 using encryption at the transport layer and above to protect user 19 payload and metadata from inspection and interference. This document 20 proposes a set of architectural considerations for such approaches. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 26, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction and Motivation 56 The IAB IP Stack Evolution Program aims to support the evolution of 57 the Internet's transport layer and its interfaces to other layers in 58 the Internet Protocol stack. The need for this work is driven by two 59 trends. First is the development and increased deployment of 60 cryptography in Internet protocols to protect against pervasive 61 monitoring [RFC7258], which will break many middleboxes used in the 62 operation and management of Internet-connected networks and which 63 assume access to plaintext content. An additional encapsulation 64 layer to allow selective, explicit metadata exchange between the 65 endpoints and devices on path to replace ad-hoc packet inspection is 66 one approach to retain network manageability in an encrypted 67 Internet. 69 Second is the increased deployment of new applications (e.g. 70 interactive media as in RTCWEB [I-D.ietf-rtcweb-overview]) for which 71 the abstractions provided by today's transport protocols (i.e., 72 either a single reliable stream as in SOCK_STREAM over TCP, or an 73 unreliable, unordered packet sequence as in SOCK_DGRAM over UDP) are 74 inadequate. This evolution is constrained by the presence of 75 middleboxes which interfere with connectivity or packet invariability 76 in the presence of new transport protocols or transport protocol 77 extensions. 79 The core issue is one of layer violation. The boundary between the 80 network and transport layers was originally defined to be the 81 boundary between information used (and potentially modified) hop-by- 82 hop, and that only used end-to-end. The widespread deployment of 83 network address and port translation (NAPT) in the Internet has 84 eroded this boundary. The first four bytes after the IP header or 85 header chain - the source and destination ports - are now the de 86 facto boundary between the layers. This erosion has continued into 87 the transport and application layer headers and down into content, as 88 the capabilities of deployed middleboxes have increased over time. 89 Evolution above the network layer is only possible if this layer 90 boundary is reinforced. Asking on-path devices nicely not to muck 91 about in the transport layer and below - stating in an RFC that 92 devices on path MUST NOT use or modify some header field - has not 93 proven to be of much use here, so we need a new approach. 95 This boundary can be reinforced by encapsulating new transport 96 protocols in UDP and encrypting everything above the UDP header. 98 However, this brings with it other problems. First, middleboxes 99 which maintain state must use timers to expire that state for UDP 100 flows, since there is no exposure of flow lifetime and bidirectional 101 establishment as with TCP's SYN, ACK, FIN, and RST flags. These 102 timers are often set fast enough to require a relatively high rate of 103 heartbeat traffic to maintain this state. A limited facility to 104 expose basic semantics of the underlying transport protocol would 105 allow these devices to keep state as they do with TCP, with no worse 106 characteristics with respect to state management than those of TCP. 108 This is a specific case of a more general issue: some of the 109 inspection of traffic done by middleboxes above the network-transport 110 boundary is operationally useful. However, the use of transport 111 layer and higher layer headers is an implicit feature of the 112 architecture: middleboxes are exploiting the fact that these headers 113 are transmitted in cleartext. There is no explicit cooperation here: 114 the endpoints have no control over the information exposed to the 115 path, and the middleboxes no information about the intentions of the 116 endpoint application other than that inferred from the inspected 117 traffic. We propose a change to the architecture to remedy this 118 condition. 120 2. Explicit Cooperation as Architectural Principle 122 The principle behind this change is one of explicit cooperation. 124 The present Internet architecture is rife with implicit cooperation 125 between endpoints and devices on the path between them. It is this 126 implicit cooperation which has led to the ossification of the 127 transport layer in the Internet. Implicit cooperation requires 128 devices along the path to make assumptions about the format of the 129 packets and the nature of the traffic they are forwarding, which in 130 turn leads to problems using protocols which don't meet these 131 assumptions. It also forces application and transport protocol 132 developers to build protocols that operate in this presumed, least- 133 common-denominator network environment. 135 This situation can be improved by making this cooperation explicit. 136 We first explore the properties of an ideal architecture for explicit 137 cooperation, then consider the constraints imposed by the present 138 configuration of the Internet which would make transition to this 139 ideal architecture infeasible. From this we derive a set of 140 architectural principles and protocol design requirements which will 141 support an incrementally deployable approach to explicit cooperation 142 between applications on endpoints and middleboxes in the Internet. 144 2.1. What does good look like? 146 We can take some guidance for the future from the original Internet 147 architecture. 149 The original Internet architecture defined the split between TCP and 150 IP by defining IP to contain those functions the gateways need to 151 handle (and possibly de- and re-encapsulate, including 152 fragmentation), while defining TCP to contain functions that can be 153 handled by hosts end-to-end [RFC0791]. Gateways were essentially 154 trusted not to meddle in TCP. 156 As a first principle, a strict division between hop-to-hop and end- 157 to-end functions is desirable to restore and maintain end-to-end 158 service in the Internet. 160 In the original architecture, there was no provision for "in-network 161 functionality" beyond forwarding, fragmentation, and basic 162 diagnostics. Forwarding is inherently explicit: placing an address 163 in the destination address field, the endpoint (and by extension, the 164 application) indicates that a packet should be sent to a given 165 address. Fragmentation was implicit in IPv4, though in-network 166 fragmentation was removed in IPv6 [RFC2460]. This was as much a 167 function of adherence to the end-to-end-principle [Saltzer84] as it 168 was an engineering reaction to limited computational and state 169 capacity on the gateways. 171 We note that layer boundaries can be enforced using sufficiently 172 strong cryptography. 174 As a second principle, in-network functionality along a path which 175 results in the modification of packet streams received at the other 176 end of a connection should be explicitly visible (and, where 177 appropriate to the nature of the functionality, controllable) by the 178 endpoints. 180 This explicitness extends into the transport stack in the endpoint. 181 When applications can clearly define transport requirements, instead 182 of implicitly lensing them through known implementations of each 183 socket type, these transport requirements can be exposed to and/or 184 matched with properties of devices along the path, where that is 185 useful. 187 2.2. What keeps us from getting there? 189 The clear separation of network and transport layer has been steadily 190 eroded over the past twenty years or so. Network address and port 191 translation (NAPT) have effectively made the first four bytes of the 192 transport header a de-facto part of the network layer, and have made 193 it difficult to deploy protocols where NAPT devices don't know that 194 the ports are safe to touch: anything other than UDP and TCP. 195 Protocols to support NAT traversal (e.g. Interactive Connectivity 196 Establishment [RFC5245]) do not address this fundamental issue. 198 Mechanisms that could be used to support explicit cooperation between 199 applications and middleboxes could be supported within the network 200 layer. The IPv6 Hop-by-Hop Options Header is intended for this 201 purpose, and a new hop-by-hop option could be defined. However, 202 there are some limitations to using this header: it is only supported 203 by IPv6, it may itself cause packets to be dropped, it may not be 204 handled efficiently (or indeed at all) by currently deployed routers 205 and middleboxes [I-D.baker-6man-hbh-header-handling], and it requires 206 changes to operating system stacks at the endpoints to allow 207 applications to access these headers. 209 One of the effects of the fact that cryptography enforces layer 210 boundaries is that applications and transports run over HTTPS de 211 facto [I-D.blanchet-iab-internetoverport443], since HTTPS is the most 212 widely implemented, accessible, and deployable way for application 213 developers to get this enforcement. 215 However, the greatest barriers to explicit cooperation between 216 applications and devices along the path is the lack of explicit trust 217 among them. While it is possible to assign trust within the "first 218 hop" administrative domains, especially when the endpoint and network 219 operator are the same entity, building and operating an 220 infrastructure for assigning and maintaining these trust 221 relationships within an Internet context is currently impractical. 223 Finally, the erosion of the end-to-end principle has not occurred in 224 a vacuum. There are incentives to deploy in-network functions, and 225 services that are impaired by them have already worked around these 226 impairments. For example, the present trend toward service 227 recentralization can be seen in part as the market's response to the 228 end of end-to-end. If every application-layer transaction is 229 mediated by services owned by the application's operator, two-end NAT 230 traversal is no longer important. This new architecture for services 231 has additional implications for the types of interactions supported, 232 and for the types of business models encouraged, which may in turn 233 make some of the concerns about limited deployability of new 234 transport protocols moot. 236 2.3. What can we do? 238 First we turn to the problem of re-separation of the network layer 239 from the transport layer. NAPT, as noted, has effectively made the 240 ports part of the network layer, and this change is not easy to undo, 241 so we can make this explicit. In many NAPT environments only UDP and 242 TCP traffic will be forwarded, and a packet with a TCP header may be 243 assumed by middleboxes to have TCP semantics; therefore, the solution 244 space is most probably constrained to putting the "new" separation 245 between the network and transport layers within a UDP encapsulation. 247 Since the relative delay in getting new transport protocols into 248 widely deployed kernel implementations has historically been another 249 impediment to deploying these new protocols in the Internet, a UDP 250 encapsulation based approach has a further implication for 251 incremental deployability: it is possible to implement UDP-based 252 encapsulations in userspace. While userspace implementations may 253 lack some of the interfaces to lower layers available to kernelspace 254 implementations necessary to build high-performance transport 255 implementations, the ability to deploy widely and quickly may help 256 break the chicken-and-egg problem of getting a transport protocol 257 adopted into kernelspace. 259 To support explicit cooperation in an environment where trust 260 relationships are variable and there may be no context with which to 261 authenticate every device along a path with which a 263 3. Properties of encapsulation and signaling mechanisms 265 We now turn to observations about and probable constraints on an 266 encapsulation and signaling-based approaches to explicit cooperation. 267 These thoughts are presently unordered, some having come from initial 268 efforts at defining requirements for SPUD. 270 3.1. The narrowness of encapsulation 272 A good deal of experience with tunnels has shown that the per-stream 273 overhead of a given encapsulation is generally less important than 274 its impact on MTU. For instance, the SPUD prototype as presently 275 defined needs at least 20 additional bytes in the header per packet: 276 2 each for source and destination UDP port, 2 for UDP length, 2 for 277 UDP checksum, 8 to identify tubes, 1 for control bits for SPUD 278 itself, and 3 for the smallest possible CBOR map containing a single 279 opaque higher layer datagram. For 1500-byte Ethernet frames, the 280 marginal cost of SPUD before is therefore 1.33% in byte terms, but it 281 does imply that 1450 byte application datagrams will no longer fit in 282 a single SPUD-over-UDP-over-IPv4-over Ethernet packet. 284 This fact has two implications for encapsulation design: First, 285 maximum payload size per packet should be communicated up to the 286 higher layer, as an explicit feature of the transport layer's 287 interface. Second, link-layer MTU is a fundamental property of each 288 link along a path, so any signaling protocol allowing path elements 289 to communicate to the endpoint should treat MTU as one of the most 290 important properties along the path to explicitly signal. 292 3.2. Implicit trust in endpoint-path signaling 294 In a perfect world, the trust relationships among endpoints and 295 elements on path would be precisely and explicitly defined: an 296 endpoint would explicitly delegate some processing to a network 297 element on its behalf, network elements would be able to trust any 298 command from any endpoint, and the integrity and authenticity of 299 signaling in both directions would be cryptographically protected. 301 However, both the economic reality that the users at the endpoints 302 and the operators of the network may not always have aligned 303 interests, as well as the difficulty of universal key exchange and 304 trust distribution among widely heterogeneous devices across 305 administrative domain boundaries, require us to take a different 306 approach toward building deployable, useful metadata signaling. 308 We observe that imperative signaling approaches in the past have 309 often failed in that they give each actor incentives to lie. 310 Markings to ask the network to explicitly treat some packets as more 311 important than others will see their value inflate away - i.e., most 312 packets from most sources will be so marked - unless some mechanism 313 is built to police those markings. Reservation protocols suffer from 314 the same problem: for example, if an endpoint really needs 1Mbps, but 315 there is no penalty for reserving 1.5Mbps "just in case", a 316 conservative strategy on the part of the endpoint leads to over- 317 reservation. 319 3.3. Declarative marking 321 An alternate approach is to treat these markings as declarative and 322 advisory, and to treat all markings on packets and flows as relative 323 to other markings on packets and flows from the same sender. In this 324 case, where neither endpoints nor path elements can reliably predict 325 the actions other elements in the network will take with respect to 326 the marking, and where no endpoint can ask for special treatment at 327 the expense of other endpoints, the incentives to marking inflation 328 are greatly diminished. 330 3.4. Verifiable marking 332 Second, markings and declarations should be defined in such a way 333 that they are verifiable, and verification built end to endpoints and 334 middleboxes wherever practical. Suppose for example an endpoint 335 declares that it will send constant-bitrate, loss-insensitive traffic 336 at 192kbps. The average data rate for the given flow is trivially 337 verifiable at any endpoint. A firewall which uses this data for 338 traffic classification and differential quality of service may spot- 339 check the data rate for such flows, and penalize those flows and 340 sources which are clearly mismarking their traffic. 342 We note that it is optimistic to assume, especially in an environment 343 with ubiquitous opportunistic encryption [RFC7435], that it is 344 possible to define a useful marking vocabulary such that every 345 marking will be so easily verifiable. However, using verifiability 346 as a design goal can lead to marking vocabularies which are less 347 likely, on balance, to be be gameable and gamed. 349 3.5. Privacy Tradeoffs in Metadata Signaling 351 Protocol engineering experience has shown that extensibility is a key 352 design goal for new protocols: especially in this case, an attempt to 353 "de-ossify" the protocol stack is really an attempt to "re-ossify" it 354 around new realities and requirements, so it makes sense to ensure 355 this effort must not be repeated. However, extensibility brings with 356 it the potential for adding new metadata which can be used to 357 increase linkability and surveillability of traffic. Identifiers 358 used internally by the signaling mechanism may also increase 359 linkability. Care must be taken when designing identifier spaces and 360 extensibility mechanisms to minimize these risks. 362 3.6. In-band, out-of-band, piggybacked, and interleaved signaling 364 Signaling channels may be in-band (that is, using the same 5 tuple as 365 the encapsulated traffic) or out-of-band (using another channel and 366 different flows). Here there are also many tradeoffs to consider. 367 In-band signaling has the advantage that it does not require 368 foreknowledge of the identity and addresses of devices along the path 369 by endpoints and vice versa, but does add complexity to the signaling 370 protocol. 372 In-band signaling can be either piggybacked on the overlying 373 transport or interleaved with it. Piggybacked signaling uses some 374 number of bits in each packet generated by the overlying transport to 375 achieve signaling. It requires either reducing the MTU available to 376 the encapsulated transport and/or opportunistically using bits 377 between the network-layer MTU and the bits actually used by the 378 transport. 380 This is even more complicated in the case of middleboxes that wish to 381 add information to piggybacked-signaling packets, and may require the 382 endpoints to introduce "scratch space" in the packets for potential 383 middlebox signaling use, further increasing complexity and overhead. 385 In contrast, interleaved signaling uses signaling packets on the same 386 5-tuple. This reduces complexity and sidesteps MTU problems, but is 387 only applicable when the signaling can be considered valid for the 388 entire flow or bound to some subset of packets in the flow via an 389 identifier. 391 Out-of-band signaling uses direct connections between endpoints and 392 middleboxes, separate from the encapsulated transport - connections 393 that are perhaps negotiated by in-band signaling. A key disadvantage 394 here is that out-of-band signaling packets may not take the same path 395 as the packets in the encapsulated transport; therefore connectivity 396 cannot be guaranteed. 398 Signaling of path-to-endpoint information, in the case that a 399 middlebox wants to signal something to the sender of the packet, 400 raises the added problem of either (1) requiring the middlebox to 401 send the information to the receiver for later reflection back to the 402 sender, which has the disadvantage of complexity, or (2) requiring 403 out-of-band direct signaling back to the sender, which in turn either 404 requires the middlebox to spoof the source address and port of the 405 receiver to ensure equivalent NAT treatment, or some other NAT- 406 traversal approach. 408 The tradeoffs here must be carefully weighed, and a comprehensive 409 approach may use a mix of all these communication patterns. 411 3.7. Reflection protection and return routability 413 The ease of forging source addresses in UDP together with the only 414 limited deployment of network egress filtering [RFC2827] means that 415 UDP traffic presently lacks a return routability guarantee. This 416 leads to UDP being useful for reflection and amplification attacks, 417 which in turn has led in part to the present situation wherein UDP 418 traffic may be blocked by firewalls when not explicitly needed by an 419 organization as part of its Internet connectivity. 421 Return routability is therefore a minimal property of any transport 422 that can be responsibly deployed at scale in the Internet. 424 4. IANA Considerations 426 This document has no actions for IANA. 428 5. Security Considerations 430 This revision of this document presents no security considerations. 431 A more rigorous definition of the limits of declarative and 432 verifiable marking would need to be evaluated against a specified 433 threat model, but we leave this to future work. 435 6. Acknowledgments 437 Many thanks to the attendees of the IAB Workshop on Stack Evolution 438 in a Middlebox Internet (SEMI) in Zurich, 26-27 January 2015; most of 439 the thoughts in this document follow directly from discussions at 440 SEMI and the subsequent SPUD BoF in Dallas in March 2015. Some text 441 for this revision of this document has been taken from 442 [I-D.trammell-spud-req], written with Mirja Kuehlewind, David Black, 443 Ken Calvert, Ted Hardie, Joe Hildebrand, Jana Iyengar, and Eric 444 Rescorla. This work is partially supported by the European 445 Commission under Grant Agrement FP7-318627 mPlane; support does not 446 imply endorsement by the Commission of the content of this work. 448 7. Informative References 450 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 451 1981. 453 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 454 (IPv6) Specification", RFC 2460, December 1998. 456 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 457 (ICE): A Protocol for Network Address Translator (NAT) 458 Traversal for Offer/Answer Protocols", RFC 5245, DOI 459 10.17487/RFC5245, April 2010, 460 . 462 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 463 Security Version 1.2", RFC 6347, January 2012. 465 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 466 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 467 2014, . 469 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 470 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 471 December 2014, . 473 [I-D.ietf-rtcweb-overview] 474 Alvestrand, H., "Overview: Real Time Protocols for 475 Browser-based Applications", draft-ietf-rtcweb-overview-14 476 (work in progress), June 2015. 478 [I-D.ietf-taps-transports] 479 Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 480 provided by IETF transport protocols and congestion 481 control mechanisms", draft-ietf-taps-transports-06 (work 482 in progress), July 2015. 484 [I-D.hildebrand-spud-prototype] 485 Hildebrand, J. and B. Trammell, "Substrate Protocol for 486 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 487 prototype-03 (work in progress), March 2015. 489 [I-D.huitema-tls-dtls-as-subtransport] 490 Huitema, C., Rescorla, E., and J. Jana, "DTLS as 491 Subtransport protocol", draft-huitema-tls-dtls-as- 492 subtransport-00 (work in progress), March 2015. 494 [I-D.blanchet-iab-internetoverport443] 495 Blanchet, M., "Implications of Blocking Outgoing Ports 496 Except Ports 80 and 443", draft-blanchet-iab- 497 internetoverport443-02 (work in progress), July 2013. 499 [I-D.baker-6man-hbh-header-handling] 500 Baker, F., "IPv6 Hop-by-Hop Header Handling", draft-baker- 501 6man-hbh-header-handling-02 (work in progress), July 2015. 503 [I-D.trammell-spud-req] 504 Trammell, B. and M. Kuehlewind, "Requirements for the 505 design of a Substrate Protocol for User Datagrams (SPUD)", 506 draft-trammell-spud-req-00 (work in progress), July 2015. 508 [Saltzer84] 509 Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 510 in System Design (ACM Trans. Comp. Sys.)", 1984. 512 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 513 RFC 792, DOI 10.17487/RFC0792, September 1981, 514 . 516 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 517 Defeating Denial of Service Attacks which employ IP Source 518 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 519 May 2000, . 521 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 522 Discovery", RFC 4821, March 2007. 524 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 525 "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/ 526 RFC7510, April 2015, 527 . 529 [I-D.trammell-stackevo-newtea] 530 Trammell, B., "Thoughts a New Transport Encapsulation 531 Architecture", draft-trammell-stackevo-newtea-01 (work in 532 progress), May 2015. 534 [I-D.iab-semi-report] 535 Trammell, B. and M. Kuehlewind, "IAB Workshop on Stack 536 Evolution in a Middlebox Internet (SEMI) Report", draft- 537 iab-semi-report-01 (work in progress), July 2015. 539 [I-D.ietf-dart-dscp-rtp] 540 Black, D. and P. Jones, "Differentiated Services 541 (DiffServ) and Real-time Communication", draft-ietf-dart- 542 dscp-rtp-10 (work in progress), November 2014. 544 Author's Address 546 Brian Trammell (editor) 547 ETH Zurich 548 Gloriastrasse 35 549 8092 Zurich 550 Switzerland 552 Email: ietf@trammell.ch