idnits 2.17.1 draft-trammell-semi-report-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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2015) is 3284 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 (-03) exists of draft-hildebrand-spud-prototype-02 == Outdated reference: A later version (-01) exists of draft-trammell-stackevo-newtea-00 Summary: 1 error (**), 0 flaws (~~), 3 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: October 31, 2015 April 29, 2015 7 IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Report 8 draft-trammell-semi-report-00 10 Abstract 12 The Internet Architecture Board (IAB) through its IP Stack Evolution 13 program, the Internet Society, and the Swiss Federal Institute of 14 Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox 15 Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore 16 the ability to evolve the transport layer in the presence of 17 middlebox- and interface-related ossification of the stack. The goal 18 of the workshop was to produce architectural and engineering guidance 19 on future work to break the logjam, focusing on incrementally 20 deployable approaches with clear incentives to deployment both on the 21 endpoints (in new transport layers and applications) as well as on 22 middleboxes (run by network operators). This document summarizes the 23 contributions to the workshop, provides an overview of the discussion 24 at the workshop, as well as the outcomes and next steps identified by 25 the workshop. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 31, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 The transport layer of the Internet has becomed ossified, squeezed 62 between narrow interfaces (from BSD sockets to pseudo-transport over 63 HTTPS) and increasing in-network modification of traffic by 64 middleboxes that make assumptions about the protocols running through 65 them. This ossification makes it difficult to innovate in the 66 transport layer, through the deployment of new protocols or the 67 extension of existing ones. At the same time, emerging applications 68 require functionality that existing protocols can provide only 69 inefficiently, if at all. 71 To begin to address this problem, the IAB, within the scope of its IP 72 Stack Evolution Program, organized a workshop to discuss approaches 73 to de-ossifying transport, especially with respect to interactions 74 with middleboxes and new methods for implementing transport 75 protocols. Recognizing that the end-to-end principle has long been 76 compromised, we start with the fundamental question of matching paths 77 through the Internet with certain characteristics to application and 78 transport requirements. 80 We posed the following questions in the call for papers: Which paths 81 through the Internet are actually available to applications? Which 82 transports can be used over these paths? How can applications 83 cooperate with network elements to improve path establishment and 84 discovery? Can common transport functionality and standardization 85 help application developers to implement and deploy such approaches 86 in today's Internet? Could cooperative approaches give us a way to 87 rebalance the Internet back toward its end-to-end roots? 89 Topics for contributions in the call for papers with a focus on 90 approaches that are incrementally deployable within the present 91 Internet were identified as follows: 93 o Development and deployment of transport-like features in 94 application-layer protocols 96 o Methods for discovery of path characteristics and protocol 97 availability along a path 99 o Methods for middlebox detection and characterization of middlebox 100 behavior and functionality 102 o Methods for NAT and middlebox traversal in the establishment of 103 end-to-end paths 105 o Mechanisms for cooperative path-endpoint signaling, and lessons 106 learned from existing approaches 108 o Economic considerations and incentives for cooperation in 109 middlebox deployment 111 The SEMI workshop followed in part from the IAB's longer term 112 interest in the evolution of the Internet and the adoption of 113 Internet protocols, including the Internet Technology Adoption and 114 Transition workshop [RFC7305], "What Makes for a Successful Protocol" 115 [RFC5218], back to Deering's "Watching the Waist of the Protocol 116 Hourglass" at IETF 51 in 2001 and before. 118 1.1. Organization of this report 120 This workshop report summarizes the contributions to and discussions 121 at the workshop, organized by topic. We started with a summary of 122 the current situation with respect to stack ossification, and 123 explored the incentives which have made it that way and the role of 124 incentives in evolution. Many contributions were broadly split into 125 two areas: middlebox measurement, classification, and approaches to 126 defense against middlebox modification of packets; and approaches to 127 support transport evolution. All accepted position papers are 128 available at https://www.iab.org/activities/workshops/semi/. 130 The outcomes of the workshop are discussed in Section 6, and discuss 131 progress after the workshop toward each of the identified work items 132 as of the time of publication of this report. 134 2. The Situation in Review 136 At the time of Deering's talk in 2001, network address translation 137 (NAT) was identified as the key challenge to the Internet 138 architecture. Since then, the NAT traversal problem has been largely 139 solved, but the boxes in the middle are getting smarter and more 140 varied. 142 SEMI and the Stack Evolution program in general are by far not the 143 first attempt to solve the problems caused by middlebox interference 144 in the end to end model. Just within the IETF the MIDCOM, NSIS, and 145 BEHAVE efforts have addressed this problem, and the TRAM working 146 group is updating the NAT traversal outcomes of MIDCOM to reflect 147 current reality. 149 We believe we have an opportunity to improve the situation in the 150 present, however, due to a convergence of forces. While the tussle 151 between security and middleboxes is not new, the accelerating 152 deployment of cryptography for integrity and confidentiality makes 153 many packet inspection and packet modification operations obsolete, 154 creating pressure to improve the situation. There is also new energy 155 in the IETF around work which requires transport layer flexibility 156 we're not sure we have (e.g. WebRTC) as well as around flexibility 157 at the transport interface (TAPS). 159 3. Incentives for Stack Ossification and Evolution 161 The current situation is, of course, the result of a variety of 162 processes, and the convergence of incentives for network operators, 163 content providers, network equipment vendors, application developers, 164 operating system developers, and end users. Moore's Law makes it 165 easier to deploy more processing on-path, network operators need to 166 find ways to add value, enterprises find it more scaleable to deploy 167 functionality in-network than on endpoints, and middleboxes are 168 something vendors can vend. This trend increases ossification of the 169 network stack. 171 Any effort to reduce this ossification in order to make it easier to 172 evolve the transport stack, then, must consider the incentives to 173 deployment of new approaches by each of these actors. 175 As Christian Huitema [huitema-semi] pointed out, encryption provides 176 a powerful incentive here: putting a transport protocol atop a 177 cryptographic protocol atop UDP resets the transport versus middlebox 178 tussle by making inspection and modification above the encryption and 179 demux layer impossible. Any transport evolution strategy using this 180 approach must also deliver better performance or functionality (e.g. 181 setup latency) than existing approaches while being as or more 182 deployable than these approaches. 184 Indeed, significant positive net value at each organization where 185 change is required - operators, application developers, equipment 186 vendors, enterprise and private users - is best to drive deployment 187 of a new protocol, said Dave Thaler, pointing to [RFC5218]. All 188 tussles in networking stem from conflicting incentives unavoidable in 189 a free market. For upper layer protocols, incentives tend to favor 190 protocols that work anywhere, use the most efficient mechanism that 191 works, and are as simple as possible from a implementation, 192 maintenance, and management standpoint. For lower layer protocols, 193 incentives tend toward ignoring and or disabling optional features, 194 as there is a positive feedback cycle between being rarely used and 195 rarely implemented. 197 [EDITOR'S NOTE: check transcript for points of discussion here] 199 4. The Role and Rule of Middleboxes 201 Middleboxes are commonplace in the Internet and constrain the ability 202 to deploy new protocols and protocol extensions. Engineering around 203 this problem requires a "bestiary" of middleboxes, a classification 204 of which kinds of impairments middleboxes cause and how often, 205 according to Benoit Donnet [edeline-semi]. 207 Even though the trend towards Network Function Visualization (NFV) 208 allows for faster update-cycle of middleboxes and thereby more 209 flexibility, the function provided by middleboxes will stay. In fact 210 Service Chaining may lead to more and more add-ons to address and 211 management a problem in the network which might further increase the 212 complexity of network management. Ted Hardie warns that each 213 instance may add a new queue and may increase the bufferbloat problem 214 which is contra-productive for new emerging latency-sensitive 215 applications. However, as further discussed at the workshop this new 216 felexibilty also provides a chance to move functionalitly back to the 217 end host and/or implemenent more appropriate in-network functionality 218 that could benefit from additional information in application and 219 path characteritics but might also require trust (domains) between 220 different actors. (Especially in mobile networks an increasing trend 221 of in-network functionality can be observed.) 223 Costin Raiciu states that middleboxes make the Internet unpredictable 224 leading to a trade-off between efficiency and reachability. While 225 constructive cooperation with middleboxes to establish a clear 226 contract between the network and the end might be one approach to 227 address this challenge, the alternative to force this contract might 228 lead to extensive tunneling as illustrated by the "ninja tunneling" 229 approach. 231 [EDITOR'S NOTE: check transcript for points of discussion here] 233 5. Evolving the Transport Layer 235 For evolution in the transport layer itself various proposals have 236 been discussed, reaching from the development of new protocols 237 (potentially as user-level stacks) encapsulated in UDP as a transport 238 identification sub-header to the use of TCP as a substrate where the 239 semantics of TCP are relaxed (e.g. regarding reliability, ordering, 240 flow control etc.) and a more flexible API is provided to the 241 application. 243 As experienced by David Black UDP encapsulation has to be adapted and 244 separately discussed for every use case which can be a long (and 245 painful) process. UDP encapsulation can be an approach to develop 246 more specialized protocols than helps to address special needs of a 247 certain applications, however, as presented by Brian Trammell and 248 brought in by Stuart Cheshire just designing a new protocol instead 249 of fixing/extending TCP might not always solve the problem. 251 To address the extensibility problem of TCP, Inner Space was proposed 252 by Bob Briscoe. In Inner Space the general principle is applied to 253 extend the layer header within layer X+1 by proposing additional 254 header/option space in the TCP payload that can not be seen by 255 middleboxes. 257 Further instead of only focusing on those cases there new extensions 258 and protocols are not deployable, Micheal Welzl points out that there 259 are also a lot of paths in the network that are not ossified. To 260 enable deployment on these paths an end host would need to probe or 261 use a happy-eyeball-like approach and potentially fallback. The TAPS 262 working group implements the first step to decouples applications 263 from transport protocols allowing for the needed flexibility in the 264 transport layer. 266 [EDITOR'S NOTE: check transcript for points of discussion here] 268 6. Outcomes 270 The SEMI workshop identified several areas for further work, outlined 271 below: 273 6.1. Minimal signaling for encapsulated transports 275 Assuming that a way forward for transport evolution in user space 276 would involve encapsulation in UDP datagrams, the workshop identified 277 that it may be useful to have a facility built atop UDP to provide 278 minimal signaling of the semantics of a flow that would otherwise be 279 available in TCP: at the very least, indications of first and last 280 packets in a flow to assist firewalls and NATs in policy decision and 281 state maintenance. This facility could also provide minimal 282 application-to-path and path-to-application signaling, though there 283 was less agreement exactly what should or could be signaled here. 285 The workshop did note that, given the increasing deployment of 286 encryption in the Internet, this facility should cooperate with DTLS 287 [RFC6347] in order to selectively expose information about traffic 288 flows where the transport headers and payload themselves are 289 encrypted. 291 To develop this concept further, it was decided to propose a non 292 working group forming BoF session, SPUD (Substrate Protocol for User 293 Datagrams), at the IETF 92 meeting in March in Dallas. A draft on 294 use cases [I-D.hardie-spud-use-cases], a prototype specification for 295 a shim protocol over UDP {{I-D.hildebrand-spud-prototype}, and a 296 separate specification of the use of DTLS as a subtransport layer 297 [I-D.huitema-tls-dtls-as-subtransport] were prepared following 298 discussions at SEMI, and presented at the BoF. 300 Clear from discussion before and during the SPUD BoF, and drawing on 301 experience with previous endpoint-to-middle and middle-to-endpoint 302 signaling approaches, is that any selective exposure of traffic 303 metadata outside a relatively restricted trust domain must be 304 declarative as opposed to imperative, non-negotiated, and advisory. 305 Each exposed parameter should also be independently verifiable, so 306 that each entity can assign its own trust to other entities. Basic 307 transport over the substrate must continue working even if signaling 308 is ignored or stripped, to support incremental deployment. These 309 restrictions on vocabulary are discussed further in 310 [I-D.trammell-stackevo-newtea]. 312 There was much interest in the room in continuing work on an approach 313 like the one under discussion. While it was relatively clear that 314 the state of the discussion and prototyping activity now is not yet 315 mature enough for standardization within an IETF working group, it is 316 not clear in what venue the work should continue. 318 Discussion contiunes on the spud mailing list (spud@ietf.org). The 319 UDP shim layer prototype described by 320 [I-D.hildebrand-spud-prototype]. 322 6.2. Middlebox measurement 324 Discussion about the impairments caused by middleboxes quickly 325 identified the need to get more and better data about how prevalent 326 certain types of impairments are in the network. It doesn't make 327 much sense, for instance, to engineer complex workarounds for certain 328 types of impairments into transport protocols if those impairments 329 are relatively rare. There are dedicated measurement studies for 330 certain types of impairment, but the workshop noted that prevalence 331 data might be available from error logs from TCP stacks and 332 applications on both clients and servers: these entities are in a 333 position to know when attempts to use particular transport features 334 failed, providing an opportunity to measure the network as a side 335 effect of using it. Many clients already have a feature for sending 336 these bug reports back to their developers. These present 337 opportunities to bring data to bear on discussion and decisions about 338 protocol engineering in an Internet full of middleboxes. 340 The HOPS (How Ossified is the Protocol Stack) informal birds of a 341 feather session ("BarBoF") was held at the IETF 92 meeting in Dallas, 342 to discuss approaches to get aggregated data from these logs about 343 potential middlebox impairment, focusing on common data formats and 344 issues of preserving end-user privacy. While some discussion focused 345 on aggregating impairment observations at the network level, initial 346 work will focus on making relative prevalence information available 347 on an Internet-wide scope. The first activity identified has been to 348 match the types of data required to answer questions relevant to 349 protocol engineering to the data that currently is or can easily be 350 collected. 352 A mailing list (hops@ietf.org) has been established to continue 353 discussion. 355 6.3. Guidelines for middlebox design and deployment 357 The workshop identified the potential to update [RFC3234] to provide 358 guidelines on middlebox design, implementation, and deployment in 359 order to reduce inadvertent or accidental impact on stack 360 ossification in existing and new middlebox designs. This document 361 will be produced by the IAB IP Stack Evolution program, drawing in 362 part on the work of the BEHAVE working group, and on experience with 363 STUN, TURN, and ICE, all of which focus more specifically on network 364 address translation. 366 6.4. Architectural guidelines for transport stack evolution 368 The workshop identified the need for architectural guidance in 369 general for transport stack evolution: tradeoffs between user- and 370 kernel-space implementations, tradeoffs in and considerations for 371 encapsulations (especially UDP), tradeoffs in implicit versus 372 explicit interaction with devices along the path, and so on. This 373 document will be produced by the IAB IP Stack Evolution Program; the 374 new transport encapsulations draft [I-D.trammell-stackevo-newtea] may 375 evolve into the basis for this work. 377 Further due to the underlying discuss on trust and a needed "balance 378 of power" between the end hosts and the network, the workshop 379 participants concluded that it is neccessary to define cryptographic 380 protocol based approaches to enable transport protocol extensibility. 382 6.5. Additional Activities in the IETF and IAB 384 The workshop identified the need to socialize ideas connected to 385 transport stack evolution within the IETF community, including 386 presentations in the transport and applications open area meetings on 387 protocol extensibility, UDP encapsulation considerations, and the 388 application of TLS/DTLS in order to prevent middlebox meddling. Much 389 of the energy coming out of the workshop went into the SPUD BoF (see 390 Section 6.1), so these presentations will be given at future 391 meetings. 393 There are also clear interactions between the future work following 394 the SEMI workshop and the IAB's Privacy and Security Program; Privacy 395 and Security program members will be encouraged to follow 396 developments in transport stack evolution to help especially with 397 privacy implications of the outcomes of the workshop. 399 6.6. Additional Activities in Other Venues 401 Bob Briscoe did an informal liaison of the SEMI workshop discussions 402 to the ETSI Network Function Virtualization (NFV) Industry 403 Specification Group (ISG) following the workshop, focusing as well on 404 the implications of end to end encryption on the present and future 405 of in-network functionality. In the ISG's Security Working Group, he 406 proposed text for best practices on middlebox access to data in the 407 presence of end to end encryption. 409 7. Security Considerations 411 This document presents no security considerations. 413 8. Acknowledgments 415 The IAB thanks the SEMI Program Committee: Brian Trammell, Mirja 416 Kuehlewind, Joe Hildebrand, Eliot Lear, Mat Ford, Gorry Fairhurst, 417 and Martin Stiemerling. We additionally thank Prof. Dr. Bernhard 418 Plattner of the Communication Systems Group at ETH for hosting the 419 workshop, and the Internet Society for its support. 421 9. Attendees 423 The following people attended the SEMI workshop: 425 Aaron Yi Ding, Aaron Falk, Barry Leiba, Benoit Donnet, Bob Briscoe, 426 Brandon Williams, Ken Calvert, Costin Raiciu, Colin Perkins, David 427 Black, Dave Thaler, Dan Wing, Felipe Huici, Mat Ford, Gorry 428 Fairhurst, Russ Housely, Christian Huitema, Brian Trammell, Joe 429 Hildebrand, Jana Ivengar, Lars Eggert, Eliot Lear, Marc Blanchet, 430 Mary Barns, Michael Welzl, Mirja Kuehlewind, Martin Stiemerling, 431 Miroslav Ponec, Erik Nordmark, Philipp Schmidt, Bernhard Plattner, 432 Richard Barnes, Spencer Dawkins, Szilveszter Nadas, Ted Hardie, Dan 433 Wing, and Xing Li. Additionally, Eric Rescorla and Stuart Cheshire 434 contributed to the workshop but were unable to attend. 436 10. Informative References 438 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 439 Issues", RFC 3234, February 2002. 441 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 442 Protocol?", RFC 5218, July 2008. 444 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 445 Security Version 1.2", RFC 6347, January 2012. 447 [RFC7305] Lear, E., "Report from the IAB Workshop on Internet 448 Technology Adoption and Transition (ITAT)", RFC 7305, July 449 2014. 451 [I-D.hardie-spud-use-cases] 452 Hardie, T., "Use Cases for SPUD", draft-hardie-spud-use- 453 cases-01 (work in progress), February 2015. 455 [I-D.hildebrand-spud-prototype] 456 Hildebrand, J. and B. Trammell, "Substrate Protocol for 457 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 458 prototype-02 (work in progress), March 2015. 460 [I-D.huitema-tls-dtls-as-subtransport] 461 Huitema, C., Rescorla, E., and J. Jana, "DTLS as 462 Subtransport protocol", draft-huitema-tls-dtls-as- 463 subtransport-00 (work in progress), March 2015. 465 [I-D.trammell-stackevo-newtea] 466 Trammell, B., "Thoughts on New Transport Encapsulation 467 Approaches", draft-trammell-stackevo-newtea-00 (work in 468 progress), March 2015. 470 [huitema-semi] 471 Huitema, C., "The Secure Transport Tussle 472 (https://www.iab.org/wp-content/IAB-uploads/2014/12/ 473 semi2015_huitema.pdf)", January 2015. 475 [edeline-semi] 476 Edeline, K. and B. Donnet, "On a Middlebox Classification 477 (https://www.iab.org/wp-content/IAB-uploads/2014/12/ 478 semi2015_edeline.pdf)", January 2015. 480 Authors' Addresses 482 Brian Trammell (editor) 483 ETH Zurich 484 Gloriastrasse 35 485 8092 Zurich 486 Switzerland 488 Email: ietf@trammell.ch 490 Mirja Kuehlewind (editor) 491 ETH Zurich 492 Gloriastrasse 35 493 8092 Zurich 494 Switzerland 496 Email: mirja.kuehlewind@tik.ee.ethz.ch