idnits 2.17.1 draft-trammell-stackevo-newtea-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 07, 2015) is 3277 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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-13 == Outdated reference: A later version (-14) exists of draft-ietf-taps-transports-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational May 07, 2015 5 Expires: November 8, 2015 7 Thoughts a New Transport Encapsulation Architecture 8 draft-trammell-stackevo-newtea-01 10 Abstract 12 This document explores architectural considerations for using 13 encapsulation in support of stack evolution and new transport 14 protocol deployment in an increasingly encrypted Internet. These 15 architectural considerations are based on an idealized architecture 16 where all interactions among applications, endpoints, and the path 17 occur explicitly, with this cooperation enforced cryptographically. 18 This idealized architecture is then lensed through the state of 19 devices in the present Internet and how they would impair the 20 deployability of such an architecture, in order to support an 21 incremental deployment of this approach. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 8, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction and Background 57 The current work of the IAB IP Stack Evolution Program is to support 58 the evolution of the Internet's transport layer and its interfaces to 59 other layers in the Internet Protocol stack. The need for this work 60 is driven by two trends. First is the development and increased 61 deployment of cryptography in Internet protocols to protect against 62 pervasive monitoring [RFC7258], which will break many middleboxes 63 used in the operation and management of Internet-connected networks 64 and which assume access to plaintext content. An additional 65 encapsulation layer to allow selective, explicit metadata exchange 66 between the endpoints and devices on path to replace ad-hoc packet 67 inspection is one approach to retain network manageability in an 68 encrypted Internet. 70 Second is the increased deployment of new applications (e.g. 71 interactive media as in RTCWEB [I-D.ietf-rtcweb-overview]) for which 72 the abstractions provided by today's transport APIs (i.e., either a 73 single reliable stream as in SOCK_STREAM over TCP, or an unreliable, 74 unordered packet sequence as in SOCK_DGRAM over UDP) are inadequate. 75 This evolution is constrained by the presence of middleboxes which 76 interfere with connectivity or packet invariability in the presence 77 of new transport protocols or transport protocol extensions. 79 Parts of this problem are presently being addressed in various ways 80 by the IETF. The Transport Services (TAPS) Working Group is defining 81 a new abstract interface for specifying transport requirements to the 82 transport layer, with a vocabulary based upon existing transport 83 protocol service features. This will allow future transport layers 84 (implemented in userspace libraries, in operating system kernels, or 85 some combination of the two) to select a wire protocol based upon 86 these requirements and the properties of the path between the 87 endpoints, including the impairments of middleboxes along that path. 89 The Substrate Protocol for User Datagrams (SPUD) Birds of a Feather 90 (BoF) session at IETF 92 in Dallas in March 2015 discussed use cases 91 and a prototype protocol [I-D.hildebrand-spud-prototype] for 92 encapsulating opaque content in UDP, with a facility for signaling 93 limited transport semantics and binding metadata to packets and flows 94 in a flexible way. This encapsulation is designed to provide 95 explicit cooperation between endpoints and middleboxes where this 96 makes sense, while allowing new transport protocol development to 97 happen both in the kernel - to which it has largely been restricted 98 due to the history of the development of TCP/IP - as well as in 99 userspace. The outcome of the BoF session was to continue the 100 discussion about the architecture, transport semantics and metadata 101 vocabulary, and experimental implementation of this approach on the 102 mailing list established for the BoF (spud@ietf.org) 104 SPUD is not the only protocol-level work to address explicit 105 communication between endpoints and devices along the path: work in 106 the Transport Layer Security (TLS) working group 107 [I-D.huitema-tls-dtls-as-subtransport] discusses the possibility and 108 provides a gap analysis for running a "minimal common subtransport" 109 exposing common transport semantics as in SPUD directly over the 110 Datagram Transport Layer Security (DTLS) protocol [RFC6347]. 112 These efforts aim at building flexible mechanisms to solve the 113 problem of expanding the interface between the transport layer and 114 the applications above it as well as the problem of making explicit 115 the contract between the transport layer and devices on path which 116 should, in an end-to-end Internet, limit themselves to lower-layer 117 interactions, but practically speaking have not done so for the past 118 two decades. 120 This document aims to provide an architectural basis for these 121 efforts, enumerating a set of architectural assumptions for transport 122 evolution based upon new encapsulations, and discussing limitations 123 on the vocabulary used in each of these new interfaces necessary to 124 achieve deployment. 126 2. Terminology 128 This document borrows terminology from [I-D.ietf-taps-transports], 129 specifically Transport Service, Transport Service Feature, Transport 130 Protocol, and Transport Protocol Component, for discussing the 131 composition of transport services. 133 [EDITOR'S NOTE: define Application Endpoint, Endhost, and Routable 134 Endpoint, as well as Midpoint, Middlebox, etc., using existing 135 terminology where applicable. A defined terminology here will help 136 avoid imprecision in this conversation.] 138 3. An Architecture for Explicit Path-Endpoint Cooperation 140 The present Internet architecture is rife with implicit cooperation 141 between endpoints and devices on the path between them. For example, 142 network address translators (NATs) rewrite addresses and ports in 143 order to increase the size of the Internet at the expense of 144 universal reachability, but this translation is not explicitly 145 invoked by either endpoint. Traffic classification is often required 146 for network management purposes, and often uses deep packet 147 inspection to determine the traffic class of a particular packet or 148 flow. 150 It is this implicit cooperation which has led to the ossification of 151 the transport layer in the Internet. Implicit cooperation requires 152 devices along the path to make assumptions about the format of the 153 packets and the nature of the traffic they are forwarding, which in 154 turn leads to problems using protocols which don't meet these 155 assumptions. It also forces application and transport protocol 156 developers to build protocols that operate in this presumed, least- 157 common-denominator network environment. 159 We take the position that this situation can be improved by replacing 160 implicit cooperation with explicit cooperation. We first explore the 161 properties of an ideal architecture for explicit cooperation, then 162 consider the constraints imposed by the present configuration of the 163 Internet which would make transition to this ideal architecture 164 infeasible. From this we derive a set of architectural principles 165 and protocol design requirements which will support an incrementally 166 deployable approach to explicit cooperation between applications on 167 endpoints and middleboxes in the Internet. 169 3.1. Principles: What does good look like? 171 We can take some guidance for the future from the original Internet 172 architecture. 174 The original Internet architecture defined the split between TCP and 175 IP by defining IP to contain those functions the gateways need to 176 handle (and possibly de- and re-encapsulate, including 177 fragmentation), while defining TCP to contain functions that can be 178 handled by hosts end-to-end [RFC0791]. Gateways were essentially 179 trusted not to meddle in TCP. 181 As a first principle, a strict division between hop-to-hop and end- 182 to-end functions is desirable to restore and maintain end-to-end 183 service in the Internet. 185 In the original architecture, there was no provision for "in-network 186 functionality" beyond forwarding, fragmentation, and basic 187 diagnostics. This was as much a function of adherence to the end-to- 188 end-principle [Saltzer84] as a desire to limit computational 189 complexity and state requirements on the gateways. 191 In-network functions in the Internet Protocol as presently defined 192 are explicit. Forwarding is inherently explicit: placing an address 193 in the destination address field, the endpoint (and by extension, the 194 application) indicates that a packet should be sent to a given 195 address. The contract for fragmentation was implicit in IPv4, but 196 in-network fragmentation was removed in IPv6 [RFC2460]. 198 We note that layer boundaries can be enforced using sufficiently 199 strong cryptography. 201 As a second principle, the presence of in-network functionality along 202 a path which results in the modification of packet streams received 203 at the other end of a connection should be explicit. 205 For optional functionality, the applications at either end of a 206 connection should have appropriate explicit control over the presence 207 of those functions on path, even if they are present by default. For 208 those functions which are necessary, without which there is no end- 209 to-end connectivity (e.g. NATs in many environments), or which are 210 otherwise non-optional for operational reasons (e.g. firewalls), the 211 functionality should be explicitly discoverable by the applications 212 on either end. 214 This explicitness extends into the transport stack in the endpoint. 215 When applications can clearly define transport requirements, instead 216 of implicitly lensing them through known implementations of each 217 socket type, these transport requirements can be exposed to and/or 218 matched with properties of devices along the path, where that is 219 useful. 221 [EDITOR'S NOTE: this is perhaps a bit further than we want to 222 actually go, but this would seem to be the logical conclusion of 223 "make path interaction explicit"] 225 3.2. Impairments: What keeps us from getting there? 227 The clear separation of network and transport layer has been steadily 228 eroded over the past twenty years or so. Network address and port 229 translation (NAPT) have effectively made the first four bytes of the 230 transport header a de-facto part of the network layer, and have made 231 it difficult to deploy protocols where NAPT devices don't know that 232 the ports are safe to touch: anything other than UDP and TCP. 233 Protocols to support with NAT traversal (e.g. Interactive 234 Connectivity Establishment [RFC5245]) do not address this fundamental 235 problem. 237 Mechanisms that could be used to support explicit cooperation between 238 applications and middleboxes could be supported within the network 239 layer. The IPv6 Hop-by-Hop Options Header is explicitly intended for 240 this purpose, and a new hop-by-hop option could be defined. However, 241 there are some limitations to using this header: it is only supported 242 by IPv6, it may itself cause packets to be dropped, it may not be 243 handled efficiently (or indeed at all) by currently deployed routers 244 and middleboxes, and it requires changes to operating system stacks 245 at the endpoints to allow applications to access these headers. 247 One of the effects of the fact that cryptography enforces layer 248 boundaries is that applications and transports run over HTTPS de 249 facto [I-D.blanchet-iab-internetoverport443], since HTTPS is the most 250 widely implemented, accessible, and deployable way for application 251 developers to get this enforcement. 253 However, the greatest barriers to explicit cooperation between 254 applications and devices along the path is the lack of explicit trust 255 among them. While it is possible to assign trust within the "first 256 hop" administrative domains, especially when the endpoint and network 257 operator are the same entity, building and operating an 258 infrastructure for assigning and maintaining these trust 259 relationships within an Internet context is currently impractical. 261 Finally, the erosion of the end-to-end principle has not occurred in 262 a vacuum. There are incentives to deploy in-network functions, and 263 services that are impaired by them have already worked around these 264 impairments. For example, the present trend toward service 265 recentralization ("cloud computing") can be seen in part as the 266 market's response to the end of end-to-end. Tf every application- 267 layer transaction is mediated by services owned by the application's 268 operator, two-end NAT traversal is no longer important. This new 269 architecture for services has additional implications for the types 270 of interactions supported, and for the types of business models 271 encouraged, which may in turn make some of the concerns about limited 272 deployability of new transport protocols moot. 274 3.3. What can we do? 276 First we turn to the problem of re-separation of the network layer 277 from the transport layer. NAPT, as noted, has effectively made the 278 ports part of the network layer, and this change is not easy to undo, 279 so we can make this explicit. In many NAPT environments only UDP and 280 TCP traffic will be forewarded, and a packet with a TCP header may be 281 assumed by middleboxes to have TCP semantics; therefore, the solution 282 space is constrained to putting the "new" separation between the 283 network and transport layers within a UDP encapsulation. This has a 284 further positive implication for incremental deployability: it is 285 possible to implement UDP-based encapsulations in userspace 287 4. Encapsulation and signaling mechanisms 289 [EDITOR'S NOTE: frontmatter on encaps] 291 4.1. Encapsulations are narrow 293 A good deal of experience with tunnels has shown that the per-stream 294 overhead of a given encapsulation is generally less important than 295 its impact on MTU. For instance, the SPUD prototype as presently 296 defined needs at least 20 additional bytes in the header per packet: 297 2 each for source and destination UDP port, 2 for UDP length, 2 for 298 UDP checksum, 8 to identify tubes, 1 for control bits for SPUD 299 itself, and 3 for the smallest possible CBOR map containing a single 300 opaque higher layer datagram. For 1500-byte Ethernet frames, the 301 marginal cost of SPUD before is therefore 1.33% in byte terms, but it 302 does imply that 1450 byte application datagrams will no longer fit in 303 a single SPUD-over-UDP-over-IPv4-over Ethernet packet. 305 This fact has two implications for encapsulation design: First, 306 maximum payload size per packet should be communicated up to the 307 higher layer, as an explicit feature of the transport layer's 308 interface. Second, link-layer MTU is a fundamental property of each 309 link along a path, so any signaling protocol allowing path elements 310 to communicate to the endpoint should treat MTU as one of the most 311 important properties along the path to explicitly signal. 313 5. Implicit trust in endpoint-path signaling 315 In a perfect world, the trust relationships among endpoints and 316 elements on path would be precisely and explicitly defined: an 317 endpoint would explicitly delegate some processing to a network 318 element on its behalf, network elements would be able to trust any 319 command from any endpoint, and the integrity and authenticity of 320 signaling in both directions would be cryptographically protected. 322 However, both the economic reality that the users at the endpoints 323 and the operators of the network may not always have aligned 324 interests, as well as the difficulty of universal key exchange and 325 trust distribution among widely heterogeneous devices across 326 administrative domain boundaries, require us to take a different 327 approach toward building deployable, useful metadata signaling. 329 We observe that imperative signaling approaches in the past have 330 often failed in that they give each actor incentives to lie. 331 Markings to ask the network to explicitly treat some packets as more 332 important than others will see their value inflate away - i.e., most 333 packets from most sources will be so marked - unless some mechanism 334 is built to police those markings. Reservation protocols suffer from 335 the same problem: for example, if an endpoint really needs 1Mbps, but 336 there is no penalty for reserving 1.5Mbps "just in case", a 337 conservative strategy on the part of the endpoint leads to over- 338 reservation. 340 5.1. Declarative marking 342 An alternate approach is to treat these markings as declarative and 343 advisory, and to treat all markings on packets and flows as relative 344 to other markings on packets and flows from the same sender. In this 345 case, where neither endpoints nor path elements can reliably predict 346 the actions other elements in the network will take with respect to 347 the marking, and where no endpoint can ask for special treatment at 348 the expense of other endpoints, the incentives to marking inflation 349 are greatly diminished. 351 5.2. Verifiable marking 353 Second, markings and declarations should be defined in such a way 354 that they are verifiable, and verification built end to endpoints and 355 middleboxes wherever practical. Suppose for example an endpoint 356 declares that it will send constant-bitrate, loss-insensitive traffic 357 at 192kbps. The average data rate for the given flow is trivially 358 verifiable at any endpoint. A firewall which uses this data for 359 traffic classification and differential quality of service may spot- 360 check the data rate for such flows, and penalize those flows and 361 sources which are clearly mismarking their traffic. 363 It is probably not possible, especially in an environment with 364 ubiquitous opportunistic encryption [RFC7435], to define a useful 365 marking vocabulary such that every marking will be so easily 366 verifiable. However, in an environment in which markings are 367 variably-trusted and verified, trustworthiness can be dynamically 368 assigned by each device, as well as 370 the trustworthiness of each endpoint and path can be independently 371 assessed by any node involved in a communication, and reputation- 372 tracking approaches can be used to signal how believable a 373 declaration is to transport protocols which use those declarations, 374 as well as to provide an additional incentive to mark honestly. 376 6. IANA Considerations 378 This document has no considerations for IANA. 380 7. Security Considerations 382 This revision of this document presents no security considerations. 383 A more rigorous definition of the limits of declarative and 384 verifiable marking would need to be evaluated against a specified 385 threat model, but we leave this to future work. 387 8. Acknowledgments 389 Many thanks to the attendees of the IAB Workshop on Stack Evolution 390 in a Middlebox Internet (SEMI) in Zurich, 26-27 January 2015; most of 391 the thoughts in this document follow directly from discussions at 392 SEMI. This work is partially supported by the European Commission 393 under Grant Agrement FP7-318627 mPlane; support does not imply 394 endorsement by the Commission of the content of this work. 396 9. Informative References 398 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 399 1981. 401 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 402 (IPv6) Specification", RFC 2460, December 1998. 404 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 405 (ICE): A Protocol for Network Address Translator (NAT) 406 Traversal for Offer/Answer Protocols", RFC 5245, April 407 2010. 409 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 410 Security Version 1.2", RFC 6347, January 2012. 412 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 413 Attack", BCP 188, RFC 7258, May 2014. 415 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 416 Most of the Time", RFC 7435, December 2014. 418 [I-D.ietf-rtcweb-overview] 419 Alvestrand, H., "Overview: Real Time Protocols for 420 Browser-based Applications", draft-ietf-rtcweb-overview-13 421 (work in progress), November 2014. 423 [I-D.ietf-taps-transports] 424 Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 425 provided by IETF transport protocols and congestion 426 control mechanisms", draft-ietf-taps-transports-03 (work 427 in progress), February 2015. 429 [I-D.hildebrand-spud-prototype] 430 Hildebrand, J. and B. Trammell, "Substrate Protocol for 431 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 432 prototype-03 (work in progress), March 2015. 434 [I-D.huitema-tls-dtls-as-subtransport] 435 Huitema, C., Rescorla, E., and J. Jana, "DTLS as 436 Subtransport protocol", draft-huitema-tls-dtls-as- 437 subtransport-00 (work in progress), March 2015. 439 [I-D.blanchet-iab-internetoverport443] 440 Blanchet, M., "Implications of Blocking Outgoing Ports 441 Except Ports 80 and 443", draft-blanchet-iab- 442 internetoverport443-02 (work in progress), July 2013. 444 [Saltzer84] 445 Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 446 in System Design (ACM Trans. Comp. Sys.)", 1984. 448 Author's Address 450 Brian Trammell 451 ETH Zurich 452 Gloriastrasse 35 453 8092 Zurich 454 Switzerland 456 Email: ietf@trammell.ch