idnits 2.17.1 draft-iab-e2e-futures-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9.0 Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10.0 IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 391 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 59 has weird spacing: '... to address ...' == Line 95 has weird spacing: '...ansport layer...' == Line 98 has weird spacing: '... layer proto...' == Line 103 has weird spacing: '...imarily invol...' == Line 104 has weird spacing: '...plicate messa...' == (15 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feburary 2004) is 7435 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 475 looks like a reference -- Missing reference section? '2' on line 478 looks like a reference -- Missing reference section? '3' on line 480 looks like a reference -- Missing reference section? '5' on line 484 looks like a reference -- Missing reference section? '4' on line 483 looks like a reference -- Missing reference section? '6' on line 486 looks like a reference -- Missing reference section? '7' on line 488 looks like a reference -- Missing reference section? '9' on line 492 looks like a reference -- Missing reference section? '12' on line 498 looks like a reference -- Missing reference section? '10' on line 494 looks like a reference -- Missing reference section? '11' on line 496 looks like a reference -- Missing reference section? '13' on line 499 looks like a reference -- Missing reference section? '14' on line 502 looks like a reference -- Missing reference section? '15' on line 505 looks like a reference -- Missing reference section? '16' on line 507 looks like a reference -- Missing reference section? '17' on line 509 looks like a reference -- Missing reference section? '8' on line 490 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 James Kempf 2 Internet Draft Rob Austein 3 Document: draft-iab-e2e-futures-05.txt IAB 4 Expires: August 2004 Feburary 2004 6 The Rise of the Middle and the Future of End to End: 7 Reflections on the Evolution of the Internet Architecture 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The end to end principle is the core architectural guideline of the Internet. 31 In this document, we briefly examine the development of the end to end 32 principle as it has been applied to the Internet architecture over the years. 33 We discuss current trends in the evolution of the Internet architecture in 34 relation to the end to end principle, and try to draw some conclusion about the 35 evolution of the end to end principle, and thus for the Internet architecture 36 which it supports, in light of these current trends. 38 Table of Contents 40 1.0 Introduction..........................................................2 41 2.0 A Brief History of the End to End Principle...........................2 42 3.0 Trends Opposed to the End to End Principle............................4 43 4.0 Whither the End to End Principle?.....................................7 44 5.0 Internet Standards as an Arena for Conflict...........................8 45 6.0 Conclusions...........................................................9 46 7.0 Acknowledgements......................................................9 47 8.0 References............................................................9 48 9.0 Security Considerations..............................................10 49 10.0 IANA Considerations................................................10 50 11.0 Author Information.................................................10 51 12.0 Full Copyright Statement...........................................11 53 1.0 Introduction 55 One of the key architectural guidelines of the Internet is the end to end 56 principle in the papers by Saltzer, Reed, and Clark [1][2]. The end to end 57 principle was originally articulated as a question of where best not to put 58 functions in a communication system. Yet, in the ensuing years, it has evolved 59 to address concerns of maintaining openness, increasing reliability and 60 robustness, and preserving the properties of user choice and ease of new 61 service development as discussed by Blumenthal and Clark in [3]; concerns that 62 were not part of the original articulation of the end to end principle. 64 In this document, we examine how the interpretation of the end to end principle 65 has evolved over the years, and where it stands currently. We examine trends in 66 the development of the Internet that have led to pressure to define services in 67 the network, a topic that has already received some amount of attention from 68 the IAB in RFC 3238 [5]. We describe some considerations about how the end to 69 end principle might evolve in light of these trends. 71 2.0 A Brief History of the End to End Principle 73 2.1 In the Beginning... 75 The end to end principle was originally articulated as a question of where best 76 to put functions in a communication system: 78 The function in question can completely and correctly be implemented only 79 with the knowledge and help of the application standing at the end points of 80 the communication system. Therefore, providing that questioned function as a 81 feature of the communication system itself is not possible. (Sometimes an 82 incomplete version of the function provided by the communication system may 83 be useful as a performance enhancement.) [1]. 85 A specific example of such a function is delivery guarantees [1]. The original 86 ARPANET returned a message "Request for Next Message" whenever it delivered a 87 packet. Although this message was found to be useful within the network as a 88 form of congestion control, since the ARPANET refused to accept another message 89 to the same destination until the previous acknowledgment was returned, it was 90 never particularly useful as an indication of guaranteed delivery. The problem 91 was that the host stack on the sending host typically doesn't want to know just 92 that the network delivered a packet, but rather the stack layer on the sending 93 host wants to know that the stack layer on the receiving host properly 94 processed the packet. In terms of modern IP stack structure, a reliable 95 transport layer requires an indication that transport processing has 96 successfully completed, such as given by TCP's ACK message [4], and not simply 97 an indication from the IP layer that packet arrived. Similarly, an application 98 layer protocol may require an application-specific acknowledgement that 99 contains, among other things, a status code indicating the disposition of the 100 request. 102 The specific examples given in [1] and other references at the time [2] 103 primarily involve transmission of data packets: data integrity, delivery 104 guarantees, duplicate message suppression, per packet encryption, and 105 transaction management. From the viewpoint of today's Internet architecture, we 106 would view most of these as transport layer functions (data integrity, delivery 107 guarantees, duplicate message suppression, and perhaps transaction management), 108 others as network layer functions with support at other layers where necessary 109 (for example, packet encryption), and not application layer functions. 111 2.2 ...In the Middle... 113 As the Internet developed, the end to end principle gradually widened to 114 concerns about where best to put the state associated with applications in the 115 Internet: in the network or at end nodes. The best example is the description 116 in RFC 1958 [6]: 118 This principle has important consequences if we require applications to 119 survive partial network failures. An end-to-end protocol design should not 120 rely on the maintenance of state (i.e. information about the state of the 121 end-to-end communication) inside the network. Such state should be 122 maintained only in the endpoints, in such a way that the state can only be 123 destroyed when the endpoint itself breaks (known as fate-sharing). An 124 immediate consequence of this is that datagrams are better than classical 125 virtual circuits. The network's job is to transmit datagrams as efficiently 126 and flexibly as possible. Everything else should be done at the fringes. 128 The original articulation of the end to end principle - that knowledge and 129 assistance of the end point is essential and that omitting such knowledge and 130 implementing a function in the network without such knowledge and assistance is 131 not possible - took a while to percolate through the engineering community, and 132 had evolved by this point to a broad architectural statement about what belongs 133 in the network and what doesn't. RFC 1958 uses the term "application" to mean 134 the entire network stack on the end node, including network, transport, and 135 application layers, in contrast to the earlier articulation of the end to end 136 principle as being about the communication system itself. "Fate-sharing" 137 describes this quite clearly: the fate of a conversation between two 138 applications is only shared between the two applications; the fate does not 139 depend on anything in the network, except for the network's ability to get 140 packets from one application to the other. 142 The end to end principle in this formulation is specifically about what kind of 143 state is maintained where: 145 To perform its services, the network maintains some state information: 146 routes, QoS guarantees that it makes, session information where that is used 147 in header compression, compression histories for data compression, and the 148 like. This state must be self-healing; adaptive procedures or protocols must 149 exist to derive and maintain that state, and change it when the topology or 150 activity of the network changes. The volume of this state must be minimized, 151 and the loss of the state must not result in more than a temporary denial of 152 service given that connectivity exists. Manually configured state must be 153 kept to an absolute minimum.[6] 155 In this formulation of the end to end principle, state involved in getting 156 packets from one end of the network to the other is maintained in the network. 157 The state is "soft state," in the sense that it can be quickly dropped and 158 reconstructed (or even required to be periodically renewed) as the network 159 topology changes due to routers and switches going on and off line. "Hard 160 state", state upon which the proper functioning of the application depends, is 161 only maintained in the end nodes. This formulation of the principle is a 162 definite change from the original formulation of the principle, about end node 163 participation being required for proper implementation of most functions. 165 In summary, the general awareness both of the principle itself and of its 166 implications for how unavoidable state should be handled grew over time to 167 become a (if not the) foundation principle of the Internet architecture. 169 2.3 ...And Now. 171 An interesting example of how the end to end principle continues to influence 172 the technical debate in the Internet community is IP mobility. The existing 173 Internet routing architecture severely constrains how closely IP mobility can 174 match the end to end principle without making fundamental changes. Mobile IPv6, 175 described in the Mobile IPv6 specification by Johnson, Perkins, and Arkko [7], 176 requires a routing proxy in the mobile node's home network (the Home Agent) for 177 maintaining the mapping between the mobile node's routing locator, the care of 178 address, and the mobile node's node identifier, the home address. But the local 179 subnet routing proxy (the Foreign Agent), which was a feature of the older 180 Mobile IPv4 design that compromised end to end routing, has been eliminated. 181 The end node now handles its own care of address. In addition, Mobile IPv6 182 includes secure mechanisms for optimizing routing to allow end to end routing 183 between the mobile end node and the correspondent node, removing the need to 184 route through the global routing proxy at the home agent. These features are 185 all based on end to end considerations. However, the need for the global 186 routing proxy in the Home Agent in Mobile IPv6 is determined by the aliasing of 187 the global node identifier with the routing identifier in the Internet routing 188 architecture, a topic that was discussed in an IAB workshop and reported in RFC 189 2956 [9], and that hasn't changed in IPv6. 191 Despite this constraint, the vision emerging out of the IETF working groups 192 developing standards for mobile networking is of a largely autonomous mobile 193 node with multiple wireless link options, among which the mobile node picks and 194 chooses. The end node is therefore responsible for maintaining the integrity of 195 the communication, as the end to end principle implies. This kind of innovative 196 application of the end to end principle derives from the same basic 197 considerations of reliability and robustness (wireless link integrity, changes 198 in connectivity and service availability with movement, etc.) that motivated 199 the original development of the end to end principle. While the basic 200 reliability of wired links and routing and switching equipment has improved 201 considerably since the end to end principle was formalized 15 years ago, the 202 reliability or unreliability of wireless links is governed more strongly by the 203 basic physics of the medium and the instantaneous radio propagation conditions. 205 3.0 Trends Opposed to the End to End Principle 207 While the end to end principle continues to provide a solid foundation for much 208 IETF design work, the specific application of the end to end principle 209 described in RFC 1958 has increasingly come into question from various 210 directions. The IAB has been concerned about trends opposing the end to end 211 principle for some time, for example RFC 2956 [9] and RFC 2775 [12]. The 212 primary focus of concern in these documents is the reduction in transparency 213 due to the introduction of NATs and other address translation mechanisms in the 214 Internet, and the consequences to the end to end principle of various scenarios 215 involving full, partial, or no deployment of IPv6. More recently, the topic of 216 concern has shifted to the consequences of service deployment in the network. 217 The IAB opinion on Open Pluggable Edge Services (OPES) in RFC 3238 [5] is 218 intended to assess the architectural desirability of defining services in the 219 network and to raise questions about how such services might result in 220 compromises of privacy, security, and end-to-end data integrity. Clark, et al. 221 in [10] and Carpenter in RFC 3234 [11] also take up the topic of service 222 definition in the network. 224 Perhaps the best review of the forces militating against the end to end 225 principle is by Blumenthal and Clark in [3]. The authors make the point that 226 the Internet originally developed among a community of like-minded technical 227 professionals who trusted each other, and was administered by academic and 228 government institutions who enforced a policy of no commercial use. The major 229 stakeholders in the Internet are quite different today. As a consequence, new 230 requirements have evolved over the last decade. Examples of these requirements 231 are discussed in the following subsections. Other discussions about pressures 232 on the end to end principle in today's Internet can be found in the discussion 233 by Reed [13] and Moors' paper in the 2002 IEEE International Communications 234 Conference [14]. 236 3.1 Need for Authentication 238 Perhaps the single most important change from the Internet of 15 years ago is 239 the lack of trust between users. Because the end users in the Internet of 15 240 years ago were few, and were largely dedicated to using the Internet as a tool 241 for academic research and communicating research results (explicit commercial 242 use of the Internet was forbidden when it was run by the US government), trust 243 between end users (and thus authentication of end nodes that they use) and 244 between network operators and their users was simply not an issue in general. 245 Today, the motivations of some individuals using the Internet are not always 246 entirely ethical, and, even if they are, the assumption that end nodes will 247 always co-operate to achieve some mutually beneficial action, as implied by the 248 end to end principle, is not always accurate. In addition, the growth in users 249 who are either not technologically sophisticated enough or simply uninterested 250 in maintaining their own security has required network operators to become more 251 proactive in deploying measures to prevent naive or uninterested users from 252 inadvertently or intentionally generating security problems. 254 While the end to end principle does not require that users implicitly trust 255 each other, the lack of trust in the Internet today requires that application 256 and system designers make a choice about how to handle authentication, whereas 257 that choice was rarely apparent 15 years ago. One of the most common examples 258 of network elements interposing between end hosts are those dedicated to 259 security: firewalls, VPN tunnel endpoints, certificate servers, etc. These 260 intermediaries are designed to protect the network from unimpeded attack or to 261 allow two end nodes whose users may have no inherent reason to trust each other 262 to achieve some level of authentication. At the same time, these measures act 263 as impediments for end to end communications. Third party trust intermediaries 264 are not a requirement for security, as end to end security mechanisms, such as 265 S/MIME [15], can be used instead, and where third party measures such as PKI 266 infrastructure or keys in DNS are utilized to exchange keying material, they 267 don't necessarily impinge on end to end traffic after authentication has been 268 achieved. Even if third parties are involved, ultimately it is up to the 269 endpoints and their users in particular, to determine which third parties they 270 trust. 272 3.2 New Service Models 274 New service models inspired by new applications require achieving the proper 275 performance level as a fundamental part of the delivered service. These service 276 models are a significant change from the original best effort service model. 277 Email, file transfer, and even Web access aren't perceived as failing if 278 performance degrades, though the user may become frustrated at the time 279 required to complete the transaction. However, for streaming audio and video, 280 to say nothing of real time bidirectional voice and video, achieving the proper 281 performance level, whatever that might mean for an acceptable user experience 282 of the service, is part of delivering the service, and a customer contracting 283 for the service has a right to expect the level of performance for which they 284 have contracted. For example, content distributors sometimes release content 285 via content distribution servers that are spread around the Internet at various 286 locations to avoid delays in delivery if the server is topologically far away 287 from the client. Retail broadband and multimedia services are a new service 288 model for many service providers. 290 3.3 Rise of the Third Party 292 Academic and government institutions ran the Internet of 15 years ago. These 293 institutions did not expect to make a profit from their investment in 294 networking technology. In contrast, the network operator with which most 295 Internet users deal today is the commercial ISP. Commercial ISPs run their 296 networks as a business, and their investors rightly expect the business to turn 297 a profit. This change in business model has led to a certain amount of pressure 298 on ISPs to increase business prospects by deploying new services. 300 In particular, the standard retail dialup bit pipe account with email and shell 301 access has become a commodity service, resulting in low profit margins. While 302 many ISPs are happy with this business model and are able to survive on it, 303 others would like to deploy different service models that have a higher profit 304 potential and provide the customer with more or different services. An example 305 is retail broadband bit pipe access via cable or DSL coupled with streaming 306 multimedia. Some ISPs that offer broadband access also deploy content 307 distribution networks to increase the performance of streaming media. These 308 services are typically deployed so that they are only accessible within the 309 ISP's network, and as a result, they do not contribute to open, end to end 310 service. From an ISP's standpoint, however, offering such service is an 311 incentive for customers to buy the ISP's service. 313 ISPs are not the only third party intermediary that has appeared within the 314 last 10 years. Unlike the previous involvement of corporations and governments 315 in running the Internet, corporate network administrators, and governmental 316 officials have become increasingly demanding of opportunities to interpose 317 between two parties in an end to end conversation. A benign motivation for this 318 involvement is to mitigate the lack of trust, so the third party acts as a 319 trust anchor or enforcer of good behavior between the two ends. A less benign 320 motivation is for the third parties to insert policy for their own reasons, 321 perhaps taxation or even censorship. The requirements of third parties often 322 have little or nothing to do with technical concerns, but rather derive from 323 particular social and legal considerations. 325 4.0 Whither the End to End Principle? 327 Given the pressures on the end to end principle discussed in the previous 328 section, a question arises about the future of the end to end principle. Does 329 the end to end principle have a future in the Internet architecture or not? If 330 it does have a future, how should it be applied? Clearly, an unproductive 331 approach to answering this question is to insist upon the end to end principle 332 as a fundamentalist principle that allows no compromise. The pressures 333 described above are real and powerful, and if the current Internet technical 334 community chooses to ignore these pressures, the likely result is that a market 335 opportunity will be created for a new technical community that does not ignore 336 these pressures but which may not understand the implications of their design 337 choices. A more productive approach is to return to first principles and re- 338 examine what the end to end principle is trying to accomplish, and then update 339 our definition and exposition of the end to end principle given the 340 complexities of the Internet today. 342 4.1 Consequences of the End to End Principle 344 In this section, we consider the two primary desirable consequences of the end 345 to end principle: protection of innovation and provision of reliability and 346 robustness. 348 4.1.1 Protection of Innovation 350 One desirable consequence of the end to end principle is protection of 351 innovation. Requiring modification in the network in order to deploy new 352 services is still typically more difficult than modifying end nodes. The 353 counterargument - that many end nodes are now essentially closed boxes which 354 are not updatable and that most users don't want to update them anyway - does 355 not apply to all nodes and all users. Many end nodes are still user 356 configurable and a sizable percentage of users are "early adopters," who are 357 willing to put up with a certain amount of technological grief in order to try 358 out a new idea. And, even for the closed boxes and uninvolved users, 359 downloadable code that abides by the end to end principle can provide fast 360 service innovation. Requiring someone with a new idea for a service to convince 361 a bunch of ISPs or corporate network administrators to modify their networks is 362 much more difficult than simply putting up a Web page with some downloadable 363 software implementing the service. 365 4.1.2 Reliability and Trust 367 Of increasing concern today, however, is the decrease in reliability and 368 robustness that results from deliberate, active attacks on the network 369 infrastructure and end nodes. While the original developers of the Internet 370 were concerned by large-scale system failures, attacks of the subtlety and 371 variety that the Internet experiences today were not a problem during the 372 original development of the Internet. By and large, the end to end principle 373 was not addressed to the decrease in reliability resulting from attacks 374 deliberately engineered to take advantage of subtle flaws in software. These 375 attacks are part of the larger issue of the trust breakdown discussed in 376 Section 3.1. Thus, the issue of the trust breakdown can be considered another 377 forcing function on the Internet architecture. 379 The immediate reaction to this trust breakdown has been to try to back fit 380 security into existing protocols. While this effort is necessary, it is not 381 sufficient. The issue of trust must become as firm an architectural principle 382 in protocol design for the future as the end to end principle is today. Trust 383 isn't simply a matter of adding some cryptographic protection to a protocol 384 after it is designed. Rather, prior to designing the protocol, the trust 385 relationships between the network elements involved in the protocol must be 386 defined, and boundaries must be drawn between those network elements that share 387 a trust relationship. The trust boundaries should be used to determine what 388 type of communication occurs between the network elements involved in the 389 protocol and which network elements signal each other. When communication 390 occurs across a trust boundary, cryptographic or other security protection of 391 some sort may be necessary. Additional measures may be necessary to secure the 392 protocol when communicating network elements do not share a trust relationship. 393 For example, a protocol might need to minimize state in the recipient prior to 394 establishing the validity of the credentials from the sender in order to avoid 395 a memory depletion DoS attack. 397 4.2 The End to End Principle in Applications Design 399 The concern expressed by the end to end principle is applicable to applications 400 design too. Two key points in designing application protocols are to ensure 401 they don't have any dependencies that would break the end to end principle and 402 to ensure that they can identify end points in a consistent fashion. An example 403 of the former is layer violations - creating dependencies that would make it 404 impossible for the transport layer, for example, to do its work appropriately. 405 Another issue is the desire to insert more applications infrastructure into the 406 network. Architectural considerations around this issue are discussed in RFC 407 3238 [5]. This desire need not result in a violation the end to end principle 408 if the partitioning of functioning is done so that services provided in the 409 network operate with the explicit knowledge and involvement of endpoints, when 410 such knowledge and involvement is necessary for the proper functioning of the 411 service. The result becomes a distributed application, in which the end to end 412 principle applies to each connection involved in implementing the application. 414 5.0 Internet Standards as an Arena for Conflict 416 Internet standards have increasingly become an arena for conflict [10]. ISPs 417 have certain concerns, businesses and government have others, and vendors of 418 networking hardware and software still others. Often, these concerns conflict, 419 and sometimes they conflict with the concerns of the end users. For example, 420 ISPs are reluctant to deploy interdomain QoS services because, among other 421 reasons, every known instance creates a significant and easily exploited 422 DoS/DDoS vulnerability. However, some end users would like to have end-to-end, 423 Diffserv or Intserv-style QoS available to improve support for voice and video 424 multimedia applications between end nodes in different domains, as discussed by 425 Huston in RFC 2990 [16]. In this case, the security, robustness and reliability 426 concerns of the ISP conflict with the desire of users for a different type of 427 service. 429 These conflicts will inevitably be reflected in the Internet architecture going 430 forward. Some of these conflicts are impossible to resolve on a technical 431 level, nor would it even be desirable, because they involve social and legal 432 choices that the IETF is not empowered to make (for a counter argument in the 433 area of privacy, see Goldberg, et al. [17]). But for those conflicts that do 434 involve technical choices, the important properties of user choice and 435 empowerment, reliability and integrity of end to end service, supporting trust 436 and "good network citizen behavior," and fostering innovation in services 437 should be the basis upon which resolution is made. The conflict will then play 438 out on the field of the resulting architecture. 440 6.0 Conclusions 442 The end to end principle continues to guide technical development of Internet 443 standards, and remains as important today for the Internet architecture as in 444 the past. In many cases, unbundling of the end to end principle into its 445 consequences leads to a distributed approach in which the end to end principle 446 applies to interactions between the individual pieces of the application, while 447 the unbundled consequences, protection of innovation and reliability and 448 robustness, apply to the entire application. While the end to end principle 449 originated as a focused argument about the need for the knowledge and 450 assistance of end nodes to properly implement functions in a communication 451 system, particular second order properties developed by the Internet as a 452 result of the end to end principle have come to be recognized as being as 453 important, if not more so, than the principle itself. End user choice and 454 empowerment, integrity of service, support for trust, and "good network citizen 455 behavior" are all properties that have developed as a consequence of the end to 456 end principle. Recognizing these properties in a particular proposal for 457 modifications to the Internet has become more important than before as the 458 pressures to incorporate services into the network have increased. Any proposal 459 to incorporate services in the network should be weighed against these 460 properties before proceeding. 462 7.0 Acknowledgements 464 Many of the ideas presented here originally appeared in the works of Dave 465 Clark, John Wroclawski, Bob Braden, Karen Sollins, Marjory Blumenthal, and Dave 466 Reed on forces currently influencing the evolution of the Internet. The authors 467 would particularly like to single out the work of Dave Clark, who was the 468 original articulator of the end to end principle and who continues to inspire 469 and guide the evolution of the Internet architecture, and John Wroclawski, with 470 whom conversations during the development of this paper helped to clarify 471 issues involving tussle and the Internet. 473 8.0 References 475 [1] Saltzer, J.H., Reed, D.P., and Clark, D.D., "End to End Arguments in 476 System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288. 478 [2] Clark, D., "The Design Philosophy of the DARPA Internet Protocols," 479 Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pp. 106-114. 480 [3] Blumenthal, M., Clark, D.D., "Rethinking the design of the Internet: 481 The end to end arguments vs. the brave new world", ACM Transactions on 482 Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109. 483 [4] Postel, J., "Transmission Control Protocol," RFC 793, September, 1981. 484 [5] Floyd, S., and Daigle, L., "IAB Architectural and Policy Considerations 485 for Open Pluggable Edge Services", RFC 3238, January 2002. 486 [6] Carpenter, B. (editor), "Architectural Principles of the Internet," RFC 487 1958, June, 1996. 488 [7] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6," 489 draft-ietf-mobileip-ipv6-20.txt, a work in progress. 490 [8] Perkins, C., editor, "Mobility Support in IPv4", RFC 3220, August, 491 2002. 492 [9] Kaat, M., "Overview of 1999 IAB Network Layer Workshop," RFC 2956, 493 October, 2000. 494 [10] Clark, D.D., Wroclawski, J., Sollins, K., and Braden, B., "Tussle in 495 Cyberspace: Defining Tommorow's Internet", Proceedings of Sigcomm 2002. 496 [11] Carpenter, B., and Brim, S., "Middleboxes: Taxonomy and Issues," RFC 497 3234, February, 2002. 498 [12] Carpenter, B., "Internet Transparency," RFC 2775, February, 2000. 499 [13] Reed, D., "The End of the End-to-End Argument?", 500 http://www.reed.com/dprframeweb/dprframe.asp?section=paper&fn=endofendt 501 oend.html, April, 2000. 502 [14] Moors, T., "A Critical Review of End-to-end Arguments in System 503 Design," Proc. 2000 IEEE International Conference on Communications, 504 pp. 1214-1219, April, 2002. 505 [15] Ramsdell, B. (editor), "S/MIME Version 3 Message Specification", RFC 506 2633, June, 1999. 507 [16] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, 508 November, 2000. 509 [17] Goldberg, I., Wagner, D., and Brewer, E., "Privacy-enhancing 510 technologies for the Internet," Proceedings of IEEE COMPCON 97, pp. 511 103-109, 1997. 513 9.0 Security Considerations 515 This document does not propose any new protocols, and therefore does not 516 involve any security considerations in that sense. However, throughout this 517 document there are discussions of the privacy and integrity issues and the 518 architectural requirements created by those issues. 520 10.0 IANA Considerations 522 There are no IANA considerations regarding this document. 524 11.0 Author Information 526 Internet Architecture Board 527 EMail: iab@iab.org 529 IAB Membership at time this document was completed: 531 Bernard Aboba 532 Harald Alvestrand 533 Rob Austein 534 Leslie Daigle 535 Patrik F�ltstr�m 536 Sally Floyd 537 Jun-ichiro Itojun Hagino 538 Mark Handley 539 Geoff Huston 540 Charlie Kaufman 541 James Kempf 542 Eric Rescorla 543 Mike St. Johns 545 This draft was created in Feburary 2004. 547 12.0 Full Copyright Statement 549 Copyright (C) The Internet Society (2004). All Rights Reserved. This 550 document and translations of it may be copied and furnished to others, and 551 derivative works that comment on or otherwise explain it or assist in its 552 implementation may be prepared, copied, published and distributed, in whole 553 or in part, without restriction of any kind, provided that the above 554 copyright notice and this paragraph are included on all such copies and 555 derivative works. However, this document itself may not be modified in any 556 way, such as by removing the copyright notice or references to the Internet 557 Society or other Internet organizations, except as needed for the purpose of 558 developing Internet standards in which case the procedures for copyrights 559 defined in the Internet Standards process must be followed, or as required 560 to translate it into languages other than English. The limited permissions 561 granted above are perpetual and will not be revoked by the Internet Society 562 or its successors or assigns. This document and the information contained 563 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 564 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 565 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 567 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.