idnits 2.17.1 draft-iab-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 (May 28, 2015) is 3256 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: November 29, 2015 May 28, 2015 7 IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Report 8 draft-iab-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. The views and positions documented in this report are 26 those of the workshop participants and do not necessarily reflect IAB 27 views and positions. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 29, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 1. Introduction 63 The transport layer of the Internet has becomed ossified, squeezed 64 between narrow interfaces (from BSD sockets to pseudo-transport over 65 HTTPS) and increasing in-network modification of traffic by 66 middleboxes that make assumptions about the protocols running through 67 them. This ossification makes it difficult to innovate in the 68 transport layer, through the deployment of new protocols or the 69 extension of existing ones. At the same time, emerging applications 70 require functionality that existing protocols can provide only 71 inefficiently, if at all. 73 To begin to address this problem, the IAB, within the scope of its IP 74 Stack Evolution Program, organized a workshop to discuss approaches 75 to de-ossifying transport, especially with respect to interactions 76 with middleboxes and new methods for implementing transport 77 protocols. Recognizing that the end-to-end principle has long been 78 compromised, we start with the fundamental question of matching paths 79 through the Internet with certain characteristics to application and 80 transport requirements. 82 We posed the following questions in the call for papers: Which paths 83 through the Internet are actually available to applications? Which 84 transports can be used over these paths? How can applications 85 cooperate with network elements to improve path establishment and 86 discovery? Can common transport functionality and standardization 87 help application developers to implement and deploy such approaches 88 in today's Internet? Could cooperative approaches give us a way to 89 rebalance the Internet back toward its end-to-end roots? 91 The call for papers encouraged a focus on approaches that are 92 incrementally deployable within the present Internet. Identified 93 topics included the following: 95 o Development and deployment of transport-like features in 96 application-layer protocols 98 o Methods for discovery of path characteristics and protocol 99 availability along a path 101 o Methods for middlebox detection and characterization of middlebox 102 behavior and functionality 104 o Methods for NAT and middlebox traversal in the establishment of 105 end-to-end paths 107 o Mechanisms for cooperative path-endpoint signaling, and lessons 108 learned from existing approaches 110 o Economic considerations and incentives for cooperation in 111 middlebox deployment 113 The SEMI workshop followed in part from the IAB's longer term 114 interest in the evolution of the Internet and the adoption of 115 Internet protocols, including the Internet Technology Adoption and 116 Transition workshop [RFC7305], "What Makes for a Successful Protocol" 117 [RFC5218], back to Deering's plenary talk [deering-plenary] at IETF 118 51 in 2001 and before. 120 1.1. Organization of this report 122 This workshop report summarizes the contributions to, and discussions 123 at the workshop, organized by topic. We started with a summary of 124 the current situation with respect to stack ossification, and 125 explored the incentives which have made it that way and the role of 126 incentives in evolution. Many contributions were broadly split into 127 two areas: middlebox measurement, classification, and approaches to 128 defense against middlebox modification of packets; and approaches to 129 support transport evolution. All accepted position papers and 130 detailed transcripts of discussion are available at 131 https://www.iab.org/activities/workshops/semi/. 133 The outcomes of the workshop are discussed in Section 6, including 134 progress after the workshop toward each of the identified work items 135 as of the time of publication of this report. 137 2. The Situation in Review 139 At the time of Deering's talk in 2001, network address translation 140 (NAT) was identified as the key challenge to the Internet 141 architecture. Since then, the NAT traversal problem has been largely 142 solved, but the boxes in the middle are getting smarter and more 143 varied. 145 SEMI, as the IP Stack Evolution program in general, is far from the 146 first attempt to solve the problems caused by middlebox interference 147 in the end to end model. Just within the IETF the MIDCOM, NSIS, and 148 BEHAVE efforts have addressed this problem, and the TRAM working 149 group is updating the NAT traversal outcomes of MIDCOM to reflect 150 current reality. 152 We believe we have an opportunity to improve the situation in the 153 present, however, due to a convergence of forces. While the tussle 154 between security and middleboxes is not new, the accelerating 155 deployment of cryptography for integrity and confidentiality makes 156 many packet inspection and packet modification operations obsolete, 157 creating pressure to improve the situation. There is also new energy 158 in the IETF around work which requires transport layer flexibility 159 we're not sure we have (e.g. WebRTC) as well as around flexibility 160 at the transport interface (TAPS). 162 3. Incentives for Stack Ossification and Evolution 164 The current situation is, of course, the result of a variety of 165 processes, and the convergence of incentives for network operators, 166 content providers, network equipment vendors, application developers, 167 operating system developers, and end users. Moore's Law makes it 168 easier to deploy more processing on-path, network operators need to 169 find ways to add value, enterprises find it more scaleable to deploy 170 functionality in-network than on endpoints, and middleboxes are 171 something vendors can vend. These trends increases ossification of 172 the network stack. 174 Any effort to reduce the resulting ossification in order to make it 175 easier to evolve the transport stack, then, must consider the 176 incentives to deployment of new approaches by each of these actors. 178 As Christian Huitema [huitema-semi] pointed out, encryption provides 179 a powerful incentive here: putting a transport protocol atop a 180 cryptographic protocol atop UDP resets the transport versus middlebox 181 tussle by making inspection and modification above the encryption and 182 demux layer impossible. Any transport evolution strategy using this 183 approach must also deliver better performance or functionality (e.g. 184 setup latency) than existing approaches while being as deployable as 185 these approaches, or moreso. 187 Indeed, significant positive net value at each organization where 188 change is required - operators, application developers, equipment 189 vendors, enterprise and private users - is best to drive deployment 190 of a new protocol, said Dave Thaler, pointing to [RFC5218]. All 191 tussles in networking stem from conflicting incentives unavoidable in 192 a free market. For upper layer protocols, incentives tend to favor 193 protocols that work anywhere, use the most efficient mechanism that 194 works, and are as simple as possible from an implementation, 195 maintenance, and management standpoint. For lower layer protocols, 196 incentives tend toward ignoring and or disabling optional features, 197 as there is a positive feedback cycle between being rarely used and 198 rarely implemented. 200 4. The Role and Rule of Middleboxes 202 Middleboxes are commonplace in the Internet and constrain the ability 203 to deploy new protocols and protocol extensions. Engineering around 204 this problem requires a "bestiary" of middleboxes, a classification 205 of which kinds of impairments middleboxes cause and how often, 206 according to Benoit Donnet [edeline-semi]. 208 Even though the trend towards Network Function Visualization (NFV) 209 allows for faster update-cycle of middleboxes and thereby more 210 flexibility, the function provided by middleboxes will stay. In 211 fact, service chaining may lead to more and more add-ons to address 212 and manage problems in the network, in turn further increasing the 213 complexity of network management. Ted Hardie [hardie-semi] warned 214 that each instance may add a new queue and may increase the 215 bufferbloat problem which is contra-productive for new emerging 216 latency-sensitive applications. However, this new flexibility also 217 provides a chance to move functionality back to the end host. 218 Alternately, more appropriate in-network functionality could benefit 219 from additional information in application and path characteristics, 220 though this in turn implies a variety of complicated trust 221 relationships among nodes in the network. In any case, an increasing 222 trend of in-network functionality can be observed, especially in 223 mobile networks. 225 Costin Raiciu [raiciu-semi] stated that middleboxes make the Internet 226 unpredictable, leading to a trade-off between efficiency and 227 reachability. While constructive cooperation with middleboxes to 228 establish a clear contract between the network and the end might be 229 one approach to address this challenge, enforcement of contract in 230 less cooperative environments might require extensive tunneling. 231 Raiciu's contribution on "ninja tunneling" illustrates one such 232 approach. 234 5. Evolving the Transport Layer 236 For evolution in the transport layer itself various proposals have 237 been discussed, reaching from the development of new protocols 238 (potentially as user-level stacks) encapsulated in UDP as a transport 239 identification sub-header to the use of TCP as a substrate where the 240 semantics of TCP are relaxed (e.g. regarding reliability, ordering, 241 flow control etc.) and a more flexible API is provided to the 242 application. 244 Discussion on evolution during the workshop divided amicably along 245 two lines: working to fix the deployability of TCP extensions ("the 246 TCP Liberation Front") versus working to build new encapulation-based 247 mechanisms to allow wholly new protocols to be deployed ("the 248 People's Front of UDP"). David Black [black-semi] pointed out that 249 UDP encapsulation has to be adapted and separately discussed for 250 every use case, which can be a long and painful process. UDP 251 encapsulation can be an approach to develop more specialized 252 protocols that helps to address special needs of certain 253 applications. However, Stuart Cheshire [cheshire-semi] (as presented 254 by Brian Trammell) pointed out that designing a new protocol instead 255 of fixing/extending TCP might not always solve the problem. 257 To address the extensibility problem of TCP, Bob Briscoe proposed 258 Inner Space [briscoe-semi]. Here, the general principle is to extend 259 layer X's header within layer X+1; in the case of TCP, additional TCP 260 header and option space is provided within the TCP payload, such that 261 it cannot presently be inspected and modified by middleboxes. 263 Further instead of only focusing on those cases there new extensions 264 and protocols are not deployable, Micheal Welzl [welzl-semi] points 265 out that there are also a lot of paths in the network that are not 266 ossified. To enable deployment on these paths an end host would need 267 to probe or use a happy-eyeball-like approach and potentially 268 fallback. The TAPS working group implements the first step to 269 decouples applications from transport protocols allowing for the 270 needed flexibility in the transport layer. 272 6. Outcomes 274 The SEMI workshop identified several areas for further work, outlined 275 below: 277 6.1. Minimal signaling for encapsulated transports 279 Assuming that a way forward for transport evolution in user space 280 would involve encapsulation in UDP datagrams, the workshop identified 281 that it may be useful to have a facility built atop UDP to provide 282 minimal signaling of the semantics of a flow that would otherwise be 283 available in TCP: at the very least, indications of first and last 284 packets in a flow to assist firewalls and NATs in policy decision and 285 state maintenance. This facility could also provide minimal 286 application-to-path and path-to-application signaling, though there 287 was less agreement exactly what should or could be signaled here. 289 The workshop did note that, given the increasing deployment of 290 encryption in the Internet, this facility should cooperate with DTLS 291 [RFC6347] in order to selectively expose information about traffic 292 flows where the transport headers and payload themselves are 293 encrypted. 295 To develop this concept further, it was decided to propose a non 296 working group forming BoF session, SPUD (Substrate Protocol for User 297 Datagrams), at the IETF 92 meeting in March in Dallas. A draft on 298 use cases [I-D.hardie-spud-use-cases], a prototype specification for 299 a shim protocol over UDP {{I-D.hildebrand-spud-prototype}, and a 300 separate specification of the use of DTLS as a subtransport layer 301 [I-D.huitema-tls-dtls-as-subtransport] were prepared following 302 discussions at SEMI, and presented at the BoF. 304 Clear from discussion before and during the SPUD BoF, and drawing on 305 experience with previous endpoint-to-middle and middle-to-endpoint 306 signaling approaches, is that any selective exposure of traffic 307 metadata outside a relatively restricted trust domain must be 308 declarative as opposed to imperative, non-negotiated, and advisory. 309 Each exposed parameter should also be independently verifiable, so 310 that each entity can assign its own trust to other entities. Basic 311 transport over the substrate must continue working even if signaling 312 is ignored or stripped, to support incremental deployment. These 313 restrictions on vocabulary are discussed further in 314 [I-D.trammell-stackevo-newtea]. 316 There was much interest in the room in continuing work on an approach 317 like the one under discussion. It was relatively clear that the 318 state of the discussion and prototyping activity now is not yet 319 mature enough for standardization within an IETF working group. An 320 appropriate venue for continuing the work remains unclear. 322 Discussion contiunes on the spud mailing list (spud@ietf.org). The 323 UDP shim layer prototype described by 324 [I-D.hildebrand-spud-prototype]. 326 6.2. Middlebox measurement 328 Discussion about the impairments caused by middleboxes quickly 329 identified the need to get more and better data about how prevalent 330 certain types of impairments are in the network. It doesn't make 331 much sense, for instance, to engineer complex workarounds for certain 332 types of impairments into transport protocols if those impairments 333 are relatively rare. There are dedicated measurement studies for 334 certain types of impairment, but the workshop noted that prevalence 335 data might be available from error logs from TCP stacks and 336 applications on both clients and servers: these entities are in a 337 position to know when attempts to use particular transport features 338 failed, providing an opportunity to measure the network as a side 339 effect of using it. Many clients already have a feature for sending 340 these bug reports back to their developers. These present 341 opportunities to bring data to bear on discussion and decisions about 342 protocol engineering in an Internet full of middleboxes. 344 The HOPS (How Ossified is the Protocol Stack) informal birds of a 345 feather session ("BarBoF") was held at the IETF 92 meeting in Dallas, 346 to discuss approaches to get aggregated data from these logs about 347 potential middlebox impairment, focusing on common data formats and 348 issues of preserving end-user privacy. While some discussion focused 349 on aggregating impairment observations at the network level, initial 350 work will focus on making relative prevalence information available 351 on an Internet-wide scope. The first activity identified has been to 352 match the types of data required to answer questions relevant to 353 protocol engineering to the data that currently is or can easily be 354 collected. 356 A mailing list (hops@ietf.org) has been established to continue 357 discussion. 359 6.3. Guidelines for middlebox design and deployment 361 The workshop identified the potential to update [RFC3234] to provide 362 guidelines on middlebox design, implementation, and deployment in 363 order to reduce inadvertent or accidental impact on stack 364 ossification in existing and new middlebox designs. This document 365 will be produced by the IAB IP Stack Evolution program, drawing in 366 part on the work of the BEHAVE working group, and on experience with 367 STUN, TURN, and ICE, all of which focus more specifically on network 368 address translation. 370 6.4. Architectural guidelines for transport stack evolution 372 The workshop identified the need for architectural guidance in 373 general for transport stack evolution: tradeoffs between user- and 374 kernel-space implementations, tradeoffs in and considerations for 375 encapsulations (especially UDP), tradeoffs in implicit versus 376 explicit interaction with devices along the path, and so on. This 377 document will be produced by the IAB IP Stack Evolution Program; the 378 new transport encapsulations draft [I-D.trammell-stackevo-newtea] may 379 evolve into the basis for this work. 381 Further due to the underlying discuss on trust and a needed "balance 382 of power" between the end hosts and the network, the workshop 383 participants concluded that it is neccessary to define cryptographic 384 protocol based approaches to enable transport protocol extensibility. 386 6.5. Additional Activities in the IETF and IAB 388 The workshop identified the need to socialize ideas connected to 389 transport stack evolution within the IETF community, including 390 presentations in the transport and applications open area meetings on 391 protocol extensibility, UDP encapsulation considerations, and the 392 application of TLS/DTLS in order to prevent middlebox meddling. Much 393 of the energy coming out of the workshop went into the SPUD BoF (see 394 Section 6.1), so these presentations will be given at future 395 meetings. 397 There are also clear interactions between the future work following 398 the SEMI workshop and the IAB's Privacy and Security Program; Privacy 399 and Security program members will be encouraged to follow 400 developments in transport stack evolution to help especially with 401 privacy implications of the outcomes of the workshop. 403 6.6. Additional Activities in Other Venues 405 Bob Briscoe did an informal liaison of the SEMI workshop discussions 406 to the ETSI Network Function Virtualization (NFV) Industry 407 Specification Group (ISG) following the workshop, focusing as well on 408 the implications of end to end encryption on the present and future 409 of in-network functionality. In the ISG's Security Working Group, he 410 proposed text for best practices on middlebox access to data in the 411 presence of end to end encryption. 413 7. Security Considerations 415 This document presents no security considerations. 417 8. Acknowledgments 419 The IAB thanks the SEMI Program Committee: Brian Trammell, Mirja 420 Kuehlewind, Joe Hildebrand, Eliot Lear, Mat Ford, Gorry Fairhurst, 421 and Martin Stiemerling. We additionally thank Prof. Dr. Bernhard 422 Plattner of the Communication Systems Group at ETH for hosting the 423 workshop, and the Internet Society for its support. Thanks to 424 Suzanne Woolf for the feedback. 426 9. Attendees 428 The following people attended the SEMI workshop: 430 Mary Barnes, Richard Barnes, David Black, Marc Blanchet, Bob Briscoe, 431 Ken Calvert, Spencer Dawkins, Benoit Donnet, Lars Eggert, Gorry 432 Fairhurst, Aaron Falk, Mat Ford, Ted Hardie, Joe Hildebrand, Russ 433 Housley, Felipe Huici, Christian Huitema, Jana Iyengar, Mirja 434 Kuehlewind, Eliot Lear, Barry Leiba, Xing Li, Szilveszter Nadas, Erik 435 Nordmark, Colin Perkins, Bernhard Plattner, Miroslav Ponec, Costin 436 Raiciu, Philipp Schmidt, Martin Stiemerling, Dave Thaler, Brian 437 Trammell, Michael Welzl, Brandon Williams, Dan Wing, and Aaron Yi 438 Ding. 440 Additionally, Stuart Cheshire and Eric Rescorla contributed to the 441 workshop but were unable to attend. 443 10. Informative References 445 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 446 Issues", RFC 3234, February 2002. 448 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 449 Protocol?", RFC 5218, July 2008. 451 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 452 Security Version 1.2", RFC 6347, January 2012. 454 [RFC7305] Lear, E., "Report from the IAB Workshop on Internet 455 Technology Adoption and Transition (ITAT)", RFC 7305, July 456 2014. 458 [I-D.hardie-spud-use-cases] 459 Hardie, T., "Use Cases for SPUD", draft-hardie-spud-use- 460 cases-01 (work in progress), February 2015. 462 [I-D.hildebrand-spud-prototype] 463 Hildebrand, J. and B. Trammell, "Substrate Protocol for 464 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 465 prototype-03 (work in progress), March 2015. 467 [I-D.huitema-tls-dtls-as-subtransport] 468 Huitema, C., Rescorla, E., and J. Jana, "DTLS as 469 Subtransport protocol", draft-huitema-tls-dtls-as- 470 subtransport-00 (work in progress), March 2015. 472 [I-D.trammell-stackevo-newtea] 473 Trammell, B., "Thoughts a New Transport Encapsulation 474 Architecture", draft-trammell-stackevo-newtea-01 (work in 475 progress), May 2015. 477 [black-semi] 478 Black, D., "UDP Encapsulation: Framework Considerations 479 (https://www.iab.org/wp-content/IAB-uploads/2014/12/ 480 semi2015_black.pdf)", January 2015. 482 [briscoe-semi] 483 Briscoe, B., "Tunneling Through Inner Space 484 (https://www.iab.org/wp-content/IAB-uploads/2014/12/ 485 semi2015_briscoe.pdf)", January 2015. 487 [cheshire-semi] 488 Cheshire, S., "Restoring the Reputation of the Much- 489 Maligned TCP (https://www.iab.org/wp-content/IAB- 490 uploads/2015/01/semi2015-cheshire.pdf)", January 2015. 492 [deering-plenary] 493 Deering, S., "Watching the Waist of the Protocol Hourglass 494 (https://www.ietf.org/proceedings/51/slides/plenary-1)", 495 August 2001. 497 [edeline-semi] 498 Edeline, K. and B. Donnet, "On a Middlebox Classification 499 (https://www.iab.org/wp-content/IAB-uploads/2014/12/ 500 semi2015_edeline.pdf)", January 2015. 502 [hardie-semi] 503 Hardie, T., "Network Function Virtualization and Path 504 Character (https://www.iab.org/wp-content/IAB- 505 uploads/2014/12/semi2015_hardie.pdf)", January 2015. 507 [huitema-semi] 508 Huitema, C., "The Secure Transport Tussle 509 (https://www.iab.org/wp-content/IAB-uploads/2014/12/ 510 semi2015_huitema.pdf)", January 2015. 512 [raiciu-semi] 513 Raiciu, C., Olteanu, V., and , "Good Cop, Bad Cop: Forcing 514 Middleboxes to Cooperate (https://www.iab.org/wp-content/ 515 IAB-uploads/2015/01/ninja.pdf)", January 2015. 517 [welzl-semi] 518 Welzl, M., Fairhurst, G., and D. Ros, "Ossification: a 519 result of not even trying? (https://www.iab.org/wp- 520 content/IAB-uploads/2014/12/semi2015_welzl.pdf)", January 521 2015. 523 Authors' Addresses 525 Brian Trammell (editor) 526 ETH Zurich 527 Gloriastrasse 35 528 8092 Zurich 529 Switzerland 531 Email: ietf@trammell.ch 533 Mirja Kuehlewind (editor) 534 ETH Zurich 535 Gloriastrasse 35 536 8092 Zurich 537 Switzerland 539 Email: mirja.kuehlewind@tik.ee.ethz.ch