idnits 2.17.1 draft-iab-research-funding-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2003) is 7741 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: 'RFC2385' is mentioned on line 346, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Missing Reference: 'RFC2082' is mentioned on line 346, but not defined ** Obsolete undefined reference: RFC 2082 (Obsoleted by RFC 4822) == Missing Reference: 'RFC2154' is mentioned on line 352, but not defined == Missing Reference: 'RFC2501' is mentioned on line 392, but not defined == Unused Reference: 'Handley02' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'NetManagement' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'ResearchQuestions' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'RFC-2082' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC-2154' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'RFC-2385' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'RFC-2407' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'RFC-2501' is defined on line 854, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2082 (Obsoleted by RFC 4822) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ran Atkinson, Editor 3 INTERNET DRAFT Sally Floyd, Editor 4 draft-iab-research-funding-00.txt Internet Architecture Board 5 February 2003 7 IAB Concerns & Recommendations Regarding Internet Research & Evolution 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document discusses IAB concerns that ongoing research is needed 33 to further the evolution of the Internet infrastructure, and that 34 consistent, sufficient non-commercial funding is needed to enable 35 such research. 37 This draft is being submitted as a first step towards getting 38 feedback from the wider community. Feedback can be sent to the IAB 39 mailing list at iab@ietf.org, or to the editors at 40 rja@extremenetworks.com and floyd@icir.org. We hope to set up a 41 mailing list for feedback at research-funding@ietf.org. When this 42 gets set up, requests to join can be sent to research-funding- 43 request@ietf.org. 45 1. Introduction 47 This document discusses the history of funding for Internet research, 48 expresses concern about the current state of such funding, and 49 outlines several specific areas that the IAB believes merit 50 additional research. Current funding levels for Internet research 51 are not generally adequate, and several important research areas are 52 significantly underfunded. This situation needs to be rectified for 53 the Internet to continue its evolution and development. 55 1.1 Document Organization 57 The first part of the document is a high-level discussion of the 58 history of funding for Internet research to provide some historical 59 context to this document. The early funding of Internet research was 60 largely from the U.S. government, followed by a period in the second 61 half of the 1990s of commercial funding and of funding from several 62 governments. [Add a citation.] However, the commercial funding for 63 Internet research has been reduced due to the recent economic 64 downturn. 66 The second part of the document provides an incomplete set of open 67 Internet research topics. These are only examples, intended to 68 illustrate the breadth of open research topics. This second section 69 supports the general thesis that ongoing research is needed to 70 further the evolution of the Internet infrastructure. This includes 71 research on the medium-time-scale evolution of the Internet 72 infrastructure as well as research on longer-time-scale grand 73 challenges. This also includes many research issues that are already 74 being actively investigated in the Internet research community. 76 Areas that are discussed in this section include the following: 77 naming, routing, security, network management, and transport. Issues 78 that require more research also include more general architectural 79 issues such as layering and communication between layers. In 80 addition, general topics discussed in this section include modeling, 81 measurement, simulation, test-beds, etc. We are focusing on topics 82 that are related to the IETF and IRTF (Internet Research Task Force) 83 agendas. (E.g., issues related to the global grid are not discussed 84 in this document because these issues are addressed through the 85 Global Grid Forum and other grid-specific organizations, not in the 86 IETF.) 88 Where at all possible, the examples in the paper point to separate 89 documents on these issues, and only give a high-level summary of the 90 issues raised in those documents. 92 1.2 IAB Concerns 94 Recently, in the aftermath of September 11 2001, there seems to be a 95 renewed interest by governments in funding research for Internet- 96 related security issues. From [J02]: "It is generally agreed that 97 the security and reliability of the basic protocols underlying the 98 Internet have not received enough attention because no one has a 99 proprietary interest in them". 101 That quote brings out a key issue in funding for Internet research, 102 which is that because no single organization (e.g., no single 103 government, software company, equipment vendor, or network operator) 104 has a sense of ownership of the global Internet infrastructure, 105 research on the general issues of the Internet infrastructure are 106 often not adequately funded. In our current challenging economic 107 climate, it is not surprising that commercial funding sources are 108 more likely to fund that research that leads to a direct competitive 109 advantage. 111 One of the principal theses of this document is that if commercial 112 funding is the main source of funding for future Internet research, 113 the future of the Internet infrastructure could be in trouble. In 114 addition to issues about which projects were funded, the funding 115 source can also affect the content of the research, for example, 116 towards or against the development of open standards, or taking 117 varying degrees of care about the effect of the developed protocols 118 on the other traffic on the Internet. 120 At the same time, many significant research contributions in 121 networking have come from commercial funding. However, for most of 122 the topics in this document, relying solely on commercially-funded 123 research would not be adequate. Much of today's commercial funding 124 is focused on technology transition, taking results from non- 125 commercial research and putting them into shipping commercial 126 products. We have not tried to delve into each of the research 127 issues below to discuss, for each issue, what are the potentials and 128 limitations of commercial funding for research in that area. 130 On a more practical note, if there was no commercial funding for 131 Internet research, then few research projects would be taken to 132 completion with implementations, deployment, and follow-up 133 evaluation. 135 While it is theoretically possible for there to be too much funding 136 for Internet research, that is far from the current problem. 138 1.3 Contributions to this Document 140 A number of people have directly contributed text for this document, 141 even though, following current conventions, the official RFC author 142 list includes only the key editors of the document. The 143 Acknowledgements section at the end of the document thanks other 144 people who contributed to this document in some form. 146 2. History of Internet Research & Research Funding 148 2.1 Prior to 1980 150 Most of the early research into packet-switched networks was 151 sponsored by the U.S. Defense Advanced Research Projects Agency 152 (DARPA) [CSTB99]. This includes the initial design, implementation, 153 and deployment of the ARPAnet connecting several universities and 154 other DARPA contractors. The ARPAnet originally came online in the 155 late 1960s. It grew in size during the 1970s, still chiefly with 156 DARPA funding, and demonstrated the utility of packet-switched 157 networking. 159 2.2 1980s and early 1990s 161 The ARPAnet converted to the Internet Protocol on January 1, 1983, 162 approximately 20 years before this document was written. Throughout 163 the 1980s, the U.S. Government continued strong research and 164 development funding for Internet technology. DARPA continued to be 165 the key funding source, but was supplemented by other DoD (US 166 Department of Defense) funding (e.g. via DCA's Defense Data Network 167 (DDN) program) and other U.S. Government funding (e.g. US Department 168 of Energy (DoE) funding for research networks at DoE national 169 laboratories, (US) National Science Foundation (NSF) funding for 170 academic institutions). This funding included basic research, 171 applied research (including freely distributable prototypes), the 172 purchase of IP-capable products, and operating support for the IP- 173 based government networks such as ARPAnet, ESnet, MILnet, and NSFnet. 175 In the late 1980s, the U.S. DoD desired to leave the business of 176 providing operational network services to academic institutions, so 177 funding for many academic activities moved over to the NSF. NSF 178 funding included research projects into networking, as well as 179 creating the NSFnet backbone and sponsoring the creation of several 180 NSF regional networks (e.g. SURAnet) and interconnections with 181 several international research networks. 183 Most research funding outside the U.S. during the 1980s and early 184 1990s was focused on the ISO OSI networking project. 186 2.3 Mid-1990s to 2003 188 Starting in the middle 1990s, U.S. Government funding for Internet 189 research and development was significantly reduced. The premise for 190 this was that the growing Internet industry would pay for whatever 191 research and development that was needed. Some funding for Internet 192 research and development has continued in this period from European 193 and Asian organizations (e.g., the WIDE Project in Japan [WIDE]). 194 RIPE (Reseaux IP Europeens) [RIPE] is an example of market-funded 195 research in Europe during this period. 197 Experience during this period has been that commercial firms have 198 often focused on donating equipment to academic institutions and 199 promoting somewhat vocationally-focused educational projects. Some 200 of the commercially-funded research and development projects appear 201 to have been selected because they appeared likely to give the 202 funding source a specific short-term economic advantage over its 203 competitors. Higher risk, more innovative research proposals 204 generally have not been funded by industry. 206 2.4 Current Status 208 The net result of reduced U.S. Government funding and profit-focused, 209 low-risk, short-term industry funding has been a sharp decline in 210 higher-risk but more innovative research activities. Industry has 211 also been less interested in research to evolve the overall Internet 212 architecture, because such work does not translate into a competitive 213 advantage for the firm funding such work. The IAB believes that it 214 would be helpful for governments and other non-commercial sponsors to 215 increase their funding of both basic research and applied research 216 relating to the Internet. Furthermore, those increased funding 217 levels should be sustained and protected against inflation going 218 forward. 220 3. Open Internet Research Topics 222 This section primarily discusses some specific topics that the IAB 223 believes merit additional research. Research, of course, includes 224 not just devising a theory, algorithm, or mechanism to accomplish a 225 goal, but also evaluating the general efficacy of the approach and 226 then the benefits vs. the costs of deploying that algorithm or 227 mechanism. Important cautionary notes about this discussion are 228 given in the next sub-section. This particular set of topics is not 229 intended to be comprehensive, but instead is intended to demonstrate 230 the breadth of open Internet research questions. 232 3.1 Scope & Limitations 234 This document is NOT intended as a guide for funding organizations as 235 to exactly which projects or proposals should or should not be 236 funded. 238 In particular, this document is NOT intended to be a comprehensive 239 list of *all* of the research questions that are important to further 240 the evolution of the Internet; that would be a daunting task, and 241 would presuppose a wider and more intensive effort than we have 242 undertaken in this document. 244 Similarly, this document is not intended to list the research 245 questions that are judged to be only of peripheral importance, or to 246 survey the current (global; governmental, commercial, and academic) 247 avenues for funding for Internet research, or to make specific 248 recommendations about which areas need additional funding. The 249 purpose of the document is to persuade the reader that ongoing 250 research is needed towards the continued evolution of the Internet 251 infrastructure; the purpose is not to make binding pronouncements 252 about which specific areas are and are not worthy of future funding. 254 For some research clearly relevant to the future evolution of the 255 Internet, there are grand controversies between competing proposals 256 or competing schools of thought; it is not the purpose of this 257 document to take positions in these controversies, or to take 258 positions on the nature of the solutions for areas needing further 259 research. That approach would not be appropriate in a general, high- 260 level overview document. 262 That all carefully noted, the remainder of this section discusses a 263 broad set of research areas, noting a subset of particular topics of 264 interest in each of those research areas. Again, this list is NOT 265 comprehensive, but rather is intended to suggest that a broad range 266 of ongoing research is needed, and to propose some candidate topics. 268 3.2 Naming 270 The Internet currently has several different namespaces, including IP 271 addresses, sockets (specified by the IP address, upper-layer 272 protocol, and upper-layer port number), and the Fully-Qualified 273 Domain Name (FQDN). Many of the Internet's namespaces are supported 274 by the widely deployed Domain Name System [RFC refs] or by various 275 Internet applications [RFC-2407, Section 4.6.2.1] 277 3.2.1 Domain Name System (DNS) 279 The DNS system, while it works well given its current constraints, 280 has several stress points. 282 [More will be added here later about the DNS-specific concerns and 283 research opportunities, such as DNSsec, signing the root zone, 284 overloading of namespaces, etc.] 286 3.2.2 New Namespaces 288 Additionally, the Namespace Research Group (NSRG) of the Internet 289 Research Task Force (IRTF) studied adding one or more additional 290 namespaces to the Internet Architecture [LD2002]. Many participants 291 in the IRTF NSRG membership believe that there would be significant 292 architectural benefit to adding one or more additional namespaces to 293 the Internet Architecture. Because smooth consensus on that question 294 or on the properties of a new namespace was not obtained, the IRTF 295 NSRG did not make a formal recommendation to the IETF community 296 regarding namespaces. The IAB believes that this is an open research 297 question worth examining further. 299 Finally, we believe that future research into the evolution of 300 Internet-based distributed computing might well benefit from studying 301 adding additional namespaces as part of a new approach to distributed 302 computing. 304 3.3 Routing 306 The currently deployed unicast routing system works reasonably well 307 for most users. However, the current unicast routing architecture is 308 suboptimal in several areas, including the following: end-to-end 309 convergence times in global-scale catenets (a system of networks 310 interconnected via gateways); the ability of the existing inter- 311 domain path-vector algorithm to scale well beyond 200K prefixes; the 312 ability of both intra-domain and inter-domain routing to use multiple 313 metrics and multiple kinds of metrics concurrently; and the ability 314 of IPv4 and IPv6 to support widespread site multi-homing without 315 undue adverse impact on the inter-domain routing system. Integrating 316 policy into routing is also a general concern, both for intra-domain 317 and inter-domain routing. 319 3.3.1 Inter-domain Routing 321 The current operational inter-domain routing system has between 322 150,000 and 200,000 routing prefixes in the default-free zone (DFZ) 323 [RFC-3221]. ASIC technology obviates concerns about the ability to 324 forward packets at very high speeds. ASIC technology also obviates 325 concerns about the time required to perform longest-prefix-match 326 computations. However, some senior members of the Internet routing 327 community have concerns that the end-to-end convergence properties of 328 the global Internet might hit algorithmic limitations (i.e. not 329 hardware limitations) when the DFZ is somewhere between 200,000 and 330 300,000 prefixes. Research into whether this concern is well-founded 331 in scientific terms seems very timely. 333 The current approach to site multi-homing has the highly undesirable 334 side-effect of significantly increasing the growth rate of prefix 335 entries in the DFZ (by impairing the deployment of prefix 336 aggregation). Research is needed into new routing architectures that 337 can support large-scale site multi-homing without the undesirable 338 impacts on inter-domain routing of the current multi-homing 339 technique. 341 3.3.2 Routing Integrity 343 Recently there has been increased awareness of the longstanding issue 344 of deploying strong authentication into the Internet inter-domain 345 routing system. Currently deployed mechanisms (e.g. BGP TCP MD5 346 [RFC2385], OSPF MD5, RIP MD5 [RFC2082]) provide cryptographic 347 authentication of routing protocol messages, but no authentication of 348 the actual routing data. Current proposals (e.g. S-BGP [KLMS2000]) 349 for improving this in inter-domain routing are unduly challenging to 350 deploy across the Internet because of their reliance on a single 351 trust hierarchy (e.g., a single PKI). Similar proposals (e.g. OSPF 352 with Digital Signatures, [RFC2154]) for intra-domain routing are 353 argued to be computationally infeasible to deploy in a large network. 355 Alternative approaches to authentication of data in the routing 356 system need to be developed. In particular, the ability to perform 357 partial authentication of routing data would facilitate incremental 358 deployment of routing authentication mechanisms. Also, the ability 359 to use non-hierarchical trust models (e.g. the web of trust used in 360 the PGP application) might facilitate incremental deployment and 361 might resolve existing concerns about centralized administration of 362 the routing system, hence merits additional study and consideration. 364 3.3.3 Routing Algorithms 366 The current Internet routing system relies primarily on only three 367 algorithms. Link-state routing uses the Dijkstra algorithm 368 [Dijkstra59]. The Distance-Vector and Path-Vector algorithms use the 369 Bellman-Ford algorithm [Bellman1957, FF1962]. Additional ongoing 370 basic research into graph theory as applied to routing is worthwhile 371 and might yield algorithms that would enable a new routing 372 architecture or otherwise provide improvements to the routing system. 374 Currently deployed multicast routing relies on the Deering RPF 375 algorithm [Deering1988]. Ongoing research into alternative multicast 376 routing algorithms and protocols might help alleviate current 377 concerns with the scalability of multicast routing. 379 The deployed Internet routing system assumes that the shortest path 380 is always the best path. This is provably false, however it is a 381 reasonable compromise given the routing protocols currently 382 available. Research into policy-based routing or routing with 383 alternative metrics (i.e. some metric other than the number of hops 384 to the destination) would be worthwhile. Examples of alternative 385 policies include: the path with lowest monetary cost; the path with 386 the lowest probability of packet loss; the path with minimized 387 jitter; and the path with minimized latency. Policy metrics are also 388 needed that take business relationships into account. 390 3.3.4 Mobile & Ad-Hoc Routing 392 Mobile routing [IM1993] and mobile ad-hoc routing [RFC2501] are 393 relatively recent arrivals in the Internet, and are not yet widely 394 deployed. The current approaches are not the last word in either of 395 those arenas. We believe that additional research into routing 396 support for mobile hosts and mobile networks is needed. Additional 397 research for ad-hoc mobile hosts and mobile networks is also 398 worthwhile. Ideally, mobile routing and mobile ad-hoc routing 399 capabilities should be native inherent capabilities of the Internet 400 routing architecture. This probably will require a significant 401 evolution from the existing Internet routing architecture. (NB: The 402 term "mobility" as used here is not limited to mobile telephones, but 403 instead is very broadly defined, including laptops that people carry, 404 cars/trains/aircraft, and so forth.) 406 Included in this topic are a wide variety of issues. The more 407 distributed and dynamic nature of partially or completely self- 408 organizing routing systems (including the associated end nodes) 409 creates unique security challenges (especially relating to AAA and 410 key management). Scalability of wireless networks can be difficult 411 to measure or to achieve. Enforced hierarchy is one approach, but 412 can be very limiting. Research into alternative approaches to 413 wireless scalability (e.g. optimized flooding, fuzzy-sighted routing) 414 seems worthwhile. Because wireless link-layer protocols usually have 415 more knowledge about the details of the current propagation 416 characteristics, it might be desirable to find ways to let network- 417 layer routing use such data. This raises architectural questions of 418 what the proper layering should be, which functions should be in 419 which layer, and also practical considerations of how and when such 420 information sharing should occur in real implementations. 422 3.4. Security 424 The Internet has a reputation for not having sufficient security. In 425 fact, the Internet has a number of security mechanisms standardized, 426 some of which are widely deployed. However, there are a number of 427 open research questions relating to Internet security. 429 3.4.1 Freely Distributable Prototypes 431 U.S.'s DARPA has historically funded development of freely 432 distributable implementations of various security technologies, such 433 as IP security, in a variety of operating systems. Experience has 434 shown that a good way to speed deployment of a new technology is to 435 provide an unencumbered, freely-distributable prototype. We believe 436 that applied research projects in Internet security will have an 437 increased probability of success if the research project teams make 438 their resulting software implementations freely available for both 439 commercial and non-commercial uses. Examples of successes here 440 include the DARPA funding of TCP/IPv4 integration into the 4.2 BSD 441 system and DARPA/USN funding of ESP/AH design and integration into 442 the 4.4 BSD system. 444 3.4.2 Formal Methods 446 There is an ongoing need for funding of basic research relating to 447 Internet security, including funding of formal methods research that 448 relates to security algorithms, protocols, and systems. For example, 449 while there has been significant work into hierarchical security 450 models (e.g. Bell-Lapadula) [BL1976], there has not been adequate 451 formal study of alternative security models (e.g. PGP's Web-of-Trust 452 model) that might be more applicable to nodes in ad-hoc networks, 453 mobile networks, or new distributed computing paradigms. Additional 454 study of alternative trust models seems worthwhile. While there has 455 been some work on the application of formal methods to cryptographic 456 algorithms and cryptographic protocols, there is a continued need for 457 research in that area and also into how formal methods might be 458 applied to the design of new cryptographic algorithms or protocols. 459 The creation of automated tools for applying formal methods to 460 cryptographic algorithms and protocols would be highly desirable. 462 3.4.3 Key Management 464 A recurring challenge to the Internet community is how to design, 465 implement, and deploy key management appropriate to the myriad 466 security contexts existing in the global Internet. Some examples of 467 topics worthy of additional research include key management 468 techniques, such as non-hierarchical key management architectures, 469 that are useful by ad-hoc groups in mobile networks and/or 470 distributed computing. 472 Although some progress has been made in recent years, scalable 473 multicast key management is far from being a solved problem. 474 Existing approaches to scalable multicast key management add 475 significant constraints on the problem scope in order to come up with 476 a deployable technical solution. Having a more general approach to 477 scalable multicast key management (i.e. one having broader 478 applicability and fewer constraints) would enhance the Internet's 479 capabilities. 481 In many cases, attribute negotiation is an important capability of a 482 key management protocol. Experience with the Internet Key Exchange 483 (IKE) to date has been that it is unduly complex. Much of IKE's 484 complexity derives from its very general attribute negotiation 485 capabilities. A new key management approach that supported 486 significant attribute negotiation without creating challenging levels 487 of deployment and operations complexity is desired. 489 3.4.4 Cryptography 491 There is an ongoing need to continue the open-world research funding 492 into both cryptography and cryptanalysis. Most governments focus 493 their cryptographic research in the military-sector. While this is 494 understandable, those efforts often have limited (or no) publications 495 in the open literature. Since the Internet engineering community 496 must work from the open literature, it is important that open-world 497 research continues in the future. 499 3.4.5 Security for Distributed Computing 501 MIT's Project Athena was an important and broadly successful research 502 project into distributed computing. Project Athena developed the 503 Kerberos [RFC-1510] security system, which has significant deployment 504 today in campus environments. However, inter-realm Kerberos is 505 neither as widely deployed nor perceived as widely successful as 506 single-realm Kerberos. Inter-domain user authentication is an 507 important open research topic. More generally, the Internet would 508 benefit from additional research into security architectures and 509 protocols to support distributed computing, including architectures 510 that support ad-hoc and mobile distributed computing environments. 512 3.4.6 Deployment Considerations in Security 514 Lots of work has been done on theoretically perfect security that is 515 impossible to deploy. Unfortunately, Kent's S-BGP proposal is an 516 example of a good research product that makes a non-deployable 517 protocol. Unfortunately, it isn't obvious how one can tweak S-BGP 518 and make it into a deployable protocol [cite]. Security mechanisms 519 that need infrastructure have not been deployed well. We desperately 520 need security that is general, easy to install, and easy to manage. 522 3.5. Network Management 524 The Internet had early success in network device monitoring with the 525 Simple Network Management Protocol (SNMP) and its associated 526 Management Information Bases (MIBs). There has been comparatively 527 less success in managing networks, in contrast to the hierarchical 528 monitoring of individual devices. 530 Unfortunately, network management research has historically been very 531 underfunded, because it is difficult to get funding bodies to 532 recognize this as legitimate networking research. 534 3.5.1 Configuration Management 536 Operators at the recent IAB Network Management Workshop reported that 537 scalable distributed configuration management for sets of network 538 devices is a significant challenge today. An enhanced network 539 management architecture that more fully supports real operational 540 needs is desirable. Even individual improvements in configuration 541 management for sets of networked devices would be very welcome. Such 542 improvements would need to include an integrated approach to security 543 for the configuration data. 545 3.5.1 Enhanced Monitoring Capabilities 547 SNMP does not scale very well to monitoring large numbers of objects 548 in many devices in different parts of the network. An alternative 549 approach worth exploring is how to provide scalable and distributed 550 monitoring, not on individual devices, but instead on groups of 551 devices and networks-as-a-whole. 553 3.5.2 Managing Networks, Not Devices 555 In particular, at present there are few or no good tools for managing 556 a whole network of devices, though SNMP (Simple Network Management 557 Protocol) and CMIP (Common Management Information Protocol) are fine 558 for reading status of well-defined objects from individual boxes. 559 Applied research into methods of managing sets of networked devices 560 seems worthwhile. Ideally this configuration management approach 561 would support distributed management, rather than being strictly 562 hierarchical. 564 As an example, the current set of network management tools for 565 managing multimedia (voice and video) IP networks is inadequate, and 566 research would be useful in this area. 568 3.5.3 Application of AI to Network Management 570 An open issue related to network management is helping users and 571 others to identify and resolve problems in the network. If a user 572 can't access a web page, it would be useful if the user could find 573 out, easily, without having to run ping and traceroute, whether the 574 problem was that the web server was down, that the network was 575 partitioned due to a link failure, that there was heavy congestion 576 along the path, that the DNS name couldn't be resolved, that the 577 firewall prohibited the access, or something else. We encourage work 578 on application of artificial intelligence (AI) or expert system 579 techniques to network management systems. 581 3.6. Quality of Service 583 There has been an intensive body of research and development work on 584 adding QoS to the Internet architecture for more than ten years now 585 [cite intserv, diffserv, rsvp], yet we still don't have end-to-end 586 QoS in the Internet [RFC-2990]. There is a need for further research 587 and development. The IETF is good at defining QoS mechanisms, but 588 poor at work on QoS architectures. Thus, while Differentiated 589 Services (DiffServ) mechanisms have been standardized as per-hop 590 behaviors, there is still much to be learned about the deployment of 591 that or other QoS mechanisms for end-to-end QoS. In addition to work 592 on purely technical issues, this includes close attention to the 593 economic models and deployment strategies that would enable an 594 increased deployment of QoS in the network. 596 One of the factors that has blunted the demand for QoS has been the 597 transition of the Internet infrastructure from heavy congestion in 598 the early 1990s, to overprovisioning in backbones and in many 599 international links now. Thus, research in QoS mechanisms also has 600 to include some careful attention to the relative costs and benefits 601 of QoS in different places in the network. 603 3.6.1 Inter-Domain QoS Architecture 605 Deploying existing Quality-of-Service (QoS) mechanisms, for example 606 Differentiated Services or Integrated Services, across an inter- 607 domain boundary creates a significant and easily exploited denial-of- 608 service vulnerability for any network that provides inter-domain QoS 609 support. This has caused network operators to refrain from 610 supporting inter-domain QoS. The Internet would benefit from 611 additional research into alternative approaches to QoS, approaches 612 that do not create such vulnerabilities and can be deployed end-to- 613 end [RFC-2990]. 615 3.6.2 New Queuing Disciplines 617 The overall Quality-of-Service for traffic is in part determined by 618 the scheduling and queue management mechanisms at the routers. 619 Continued work is needed into new queuing and queue management 620 disciplines that could be used for DiffServ traffic, for other QoS 621 mechanisms, and for better QoS for best-effort traffic. 623 3.7. Congestion control. 625 TCP's congestion control mechanisms, from 1988 [J88], have been a key 626 factor in maintaining the stability of the Internet, and are used by 627 the bulk of the Internet's traffic. However, the congestion control 628 mechanisms of the Internet need to be expanded and modified to meet a 629 wide range of new stresses, from new applications such as streaming 630 media and multicast to new environments such as wireless networks or 631 very high bandwidth paths, and new requirements for minimizing 632 queueing delay. While there are significant bodies of work in 633 several of these issues, considerably more needs to be done. (We 634 would note that research on TCP congestion control is also not yet 635 "done", with much still to be accomplished in high-speed TCP, or in 636 adding robust performance over paths with significant reordering, 637 intermittent connectivity, non-congestive packet loss, and the like.) 639 Several of these issues bring up difficult fundamental questions 640 about the potential costs and benefits of increased communication 641 between layers. Would it help transport to receive hints or other 642 information from routing, from link layers, or from other transport- 643 level connections? If so, what would be the cost to robust operation 644 across diverse environments? 646 For congestion control mechanisms in routers, active queue management 647 and Explicit Congestion Notification are generally not yet deployed, 648 and there are a range of proposals, in various states of maturity, in 649 this area. At the same time, there is a great deal that we still do 650 not understand about the interactions of queue management mechanisms 651 with other factors in the network. Router-based congestion control 652 mechanisms are also needed for detecting and responding to aggregate 653 congestion such as in Distributed Denial of Service attacks and flash 654 crowds. 656 As more applications have the need to transfer very large files over 657 high delay-bandwidth-product paths, the stresses on current 658 congestion control mechanisms raise the question of whether we need 659 more fine-grained feedback from routers. This includes the challenge 660 of allowing connections to avoid the delays of slow-start, and to 661 rapidly make use of newly-available bandwidth. 663 There is also a need for long-term research in congestion control 664 that is separate from specific functional requirements like the ones 665 listed above. We know very little about congestion control dynamics 666 or traffic dynamics a large, complex network like the global 667 Internet, with its heterogeneous and changing traffic mixes, link- 668 level technologies, network protocols and router mechanisms, patterns 669 of congestion, pricing models, and the like. Expanding our knowledge 670 in this area seems likely to require a rich mix of measurement, 671 analysis, simulations, and experimentation. 673 3.8. Studying the Evolution of the Internet Infrastructure 675 The evolution of the Internet infrastructure has been frustratingly 676 slow and difficult, with long stories about the difficulties in 677 adding IPv6, QoS, multicast, and other functionality to the Internet. 678 We need a more scientific understanding of the evolutionary 679 potentials and evolutionary difficulties of the Internet 680 infrastructure. 682 This evolutionary potential is affected not only by the technical 683 issues of the layered IP architecture, but by other factors as well. 684 These factors include the changes in the environment over time (e.g., 685 the recent overprovisioning of backbones, the deployment of 686 firewalls), and the role of standardization process. Economic and 687 public policy factors are also critical, including the central fact 688 of the Internet as a decentralized system, with key players being not 689 only individuals, but also ISPs, companies, and entire industries. 690 Deployment issues are also key factors in the evolution of the 691 Internet, including the continual chicken-and-egg problem of having 692 enough customers to merit rolling out a service whose utility depends 693 on the size of the customer base in the first place. 695 Overlay networks could sometimes serve as a transition technology for 696 new functionality, with an initial deployment in overlay networks, 697 and with that functionality moving later into the core if it seems 698 warranted. 700 There are also increased obstacles to the evolution of the Internet 701 in the form of increased complexity [WD02], unanticipated feature 702 interactions [K00], interactions between layers, interventions by 703 middleboxes, and the like. Because increasing complexity appears 704 inevitable, research is needed to understand architectural mechanisms 705 that can accommodate increased complexity without decreasing 706 robustness of performance in unknown environments, and without 707 closing off future possibilities for evolution. 709 3.9. Middleboxes 711 [A section will be added on research that is needed to address the 712 challenges posed by middleboxes. This includes issues of security, 713 control, and data integrity, and on the general impact of middleboxes 714 on the architecture. In many ways middleboxes are a direct outgrowth 715 of commercial interests, but there is a need to look beyond the near- 716 term need for the technology to research its broader implications and 717 ways to improve how middleboxes fit into the architecture.] 719 3.10. Meeting the Needs of the Future 721 As network size, link bandwidth, CPU capacity, and the number of 722 users all increase, research will be needed to ensure that the 723 Internet of the future scales to meet these increasing demands. We 724 have discussed some of these scaling issues in specific sections 725 above. However, for all of the research questions discussed in this 726 document, the goal of the research must be not only to meet the 727 challenges already experienced today, but also to meet the challenges 728 that can be expected to emerge in the future. 730 3.11. Additional topics 732 We have not yet included in this document discussions about the need 733 for additional research in providing tools for researchers (e.g., 734 modeling, simulations, test-beds). 736 We also don't yet have sections on the research needs in network 737 measurement. 739 [Any new material should be focused on the problems that need to be 740 addressed, rather than focused on the new approaches or technologies 741 that might be promising answers to those problems.] 743 4. Conclusions 745 This document has summarized the history of research funding for the 746 Internet and highlighted examples of open research questions. The 747 IAB believes that more research is required to further the evolution 748 of the Internet infrastructure, and that consistent, sufficient non- 749 commercial funding is needed to enable such research. 751 5. Acknowledgements 753 The people who directly contributed to this document in some form 754 include the following: Ran Atkinson, Jon Crowcroft, Sally Floyd, 755 James Kempf, Vern Paxson, Mike St. Johns. 757 We have also drawn widely on the following sources: [Cyberspace02], 758 [Netvision2012], [NSF02], [NSF03]. Upcoming workshops include the 759 following: [COST-NSF03]. 761 6 References 763 There are no Normative References because this is an Informational 764 document. 766 Informative References 768 [CSTB99] Funding a Revolution: Government Support for Computing 769 Research, CSTB publication, 1999, URL 770 "http://www7.nationalacademies.org/cstb/pub_revolution.html". 772 [Cyberspace02] National Strategy to Secure Cyberspace, September 773 2002, URL "http://www.whitehouse.gov/pcipb/". 775 [Bellman1957] R.E. Bellman, "Dynamic Programming", Princeton 776 University Press, Princeton, NJ, 1957. 778 [BL1976] D. E. Bell & L. J. LaPadula, "Secure Computer Systems: 779 Unified Exposition and Multics Interpretation", MITRE Technical 780 Report NMTR-1997 (ESD-TR-75-306), The Mitre Corporation, March 1976. 782 [COST-NSF03] COST-IST(EU)--NSF(USA) Workshop on Networking, June, 783 2003. URL "http://cgi.di.uoa.gr/~istavrak/costnsf/". 785 [Deering1988] S. Deering, "Multicast Routing in Internetworks and 786 LANs", ACM Computer Communications Review, Volume 18, Issue 4, August 787 1988. 789 [Dijkstra59] E. Dijkstra, "A note on two problems in connexion with 790 graphs", Numerishe Mathematik, 1, 1959, pp.269-271. 792 [FF1962] L.R. Ford Jr. & D.R. Fulkerson, "Flows in Networks", 793 Princeton University Press, Princeton, NJ, 1962. 795 [Handley02] Mark Handley's viewgraphs to an NSF meeting, 2002. 797 [IM1993] J. Ioannidis & G. Maguire Jr., "The Design and 798 Implementation of a Mobile Internetworking Architecture", Proceedings 799 of the Winter USENIX Technical Conference, pages 489-500, January 800 1993. 802 [J88] Van Jacobson, Congestion Avoidance and Control, SIGCOMM, 1988. 803 URL "http://citeseer.nj.nec.com/jacobson88congestion.html". 805 [J02] William Jackson, "U.S. should fund R&D for secure Internet 806 protocols, Clarke says", 10/31/02, URL 807 "http://www.gcn.com/vol1_no1/security/20382-1.html". 809 [K00] Hans Kruse, The Pitfalls of Distributed Protocol Development: 810 Unintentional Interactions between Network Operations and 811 Applications Protocols, 8th International Conference on 812 Telecommunication Systems Design, Nashville, March 2000. URL 813 "http://www.csm.ohiou.edu/kruse/publications/TSYS2000.pdf". 815 [KLMS2000] S. Kent, C. Lynn, J. Mikkelson, & K. Seo, "Secure Border 816 Gateway Protocol (S-BGP)", Proceedings of ISoc Network & Distributed 817 Systems Security Symposium, Internet Society, Reston, VA, February 818 2000. 820 [LD2002] E. Lear & R. Droms, "What's in a Name: Thoughts from the 821 NSRG", Internet-Draft, December 2002. 823 [NetManagement] IAB Network Management workshop, 2002. 825 [Netvision2012] NetVision 2012, DARPA's Ten-Year Strategic Plan for 826 Networking Research, October 2002, December 2002. Citation for 827 acknowledgement purposes only. 829 [NSF02] NSF Workshop on Network Research Testbeds, October 2002. URL 830 "http://www-net.cs.umass.edu/testbed_workshop/". 832 [NSF03] NSF ANIR Principal Investigator meeting, January 9-10, 2003, 833 URL "http://www.ncne.org/training/nsf-pi/2003/nsfpimain.html". 835 [ResearchQuestions] Web Page on "Papers about Research Questions for 836 the Internet", URL 837 "http://www.icir.org/floyd/research_questions.html". 839 [RFC-1510] J. Kohl & C. Neuman, "The Kerberos Network Authentication 840 Service (V5)", RFC 1510, September 1993. 842 [RFC-2082] F. Baker & R. Atkinson, "RIPv2 MD5 Authentication", 843 RFC-2082, January 1997. 845 [RFC-2154] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital 846 Signatures", RFC-2154, June 1997. 848 [RFC-2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 849 Signature Option", RFC-2385, August 1998. 851 [RFC-2407] D. Piper, "The Internet IP Security Domain of 852 Interpretation for ISAKMP", RFC-2407, November 1998. 854 [RFC-2501] S. Corson & J. Macker, "Mobile Ad Hoc Networking (MANET): 855 Routing Protocol Performance Issues and Evaluation Considerations", 856 RFC-2501, January 1999. 858 [RFC-2990] G. Huston, "Next Steps for the IP QoS Architecture", 859 RFC-1990, November 2000. 861 [RFC-3221] G. Huston, "Commentary on Inter-Domain Routing in the 862 Internet", RFC-3221, December 2001. 864 [RIPE] RIPE (Reseaux IP Europeens), URL "http://www.ripe.net/ripe/". 866 [WD02] Walter Willinger and John Doyle, "Robustness and the Internet: 867 Design and Evolution", 2002, URL 868 "http://netlab.caltech.edu/internet/". 870 [WIDE] WIDE Project, URL "http://www.wide.ad.jp/". 872 7. Security Considerations 874 This document does not itself create any new security issues for the 875 Internet community. Security issues within the Internet Architecture 876 primarily are discussed in Section 3.4 above. 878 8. IANA Considerations 880 There are no IANA considerations regarding this document. 882 9. AUTHORS' ADDRESSES 884 Internet Architecture Board 885 EMail: iab@iab.org 886 IAB Membership at time this document was completed: 888 Harald Alvestrand (IETF chair) 889 Ran Atkinson 890 Rob Austein 891 Fred Baker 892 Leslie Daigle (IAB chair) 893 Sally Floyd 894 Ted Hardie 895 Geoff Huston 896 Charlie Kaufman 897 James Kempf 898 Vern Paxson (IRTF chair) 899 Eric Rescorla 900 Mike St. Johns 902 This draft was created in November 2002 and revised January 2003 903 and February 2003.