idnits 2.17.1 draft-iab-research-funding-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 1370. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1415. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1390), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 32. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 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 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 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 -- 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 (May 2004) is 7285 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 515, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Missing Reference: 'RFC2082' is mentioned on line 515, but not defined ** Obsolete undefined reference: RFC 2082 (Obsoleted by RFC 4822) == Missing Reference: 'RFC2154' is mentioned on line 521, but not defined == Missing Reference: 'RFC2501' is mentioned on line 585, but not defined == Missing Reference: 'RFC-1633' is mentioned on line 818, but not defined == Missing Reference: 'RFC-2474' is mentioned on line 818, but not defined == Missing Reference: 'RFC-3260' is mentioned on line 818, but not defined == Missing Reference: 'RFC-2205' is mentioned on line 818, but not defined == Missing Reference: 'RFC-2210' is mentioned on line 818, but not defined == Unused Reference: 'Bellman1957' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: 'BL1976' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'Claffy03a' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'Diot00' is defined on line 1170, but no explicit reference was found in the text == Unused Reference: 'FF1962' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'NSF03b' is defined on line 1255, but no explicit reference was found in the text == Unused Reference: 'Floyd' is defined on line 1260, but no explicit reference was found in the text == Unused Reference: 'RFC-2082' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'RFC-2154' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'RFC-2385' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'RFC-2407' is defined on line 1276, but no explicit reference was found in the text == Unused Reference: 'RFC-2501' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'RFC-3535' is defined on line 1299, but no explicit reference was found in the text == Unused Reference: 'SM03' is defined on line 1319, 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: 14 errors (**), 0 flaws (~~), 27 warnings (==), 8 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-03.txt Internet Architecture Board 5 May 2004 7 IAB Concerns and Recommendations Regarding Internet Research and 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 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This document discusses IAB concerns that ongoing research is needed 37 to further the evolution of the Internet infrastructure, and that 38 consistent, sufficient non-commercial funding is needed to enable 39 such research. 41 Table of Contents 42 1. Introduction 43 1.1. Document Organization 44 1.2. IAB Concerns 45 1.3. Contributions to this Document 46 2. History of Internet Research and Research Funding 47 2.1. Prior to 1980 48 2.2. 1980s and early 1990s 49 2.3. Mid-1990s to 2003 50 2.4. Current Status 51 3. Open Internet Research Topics 52 3.1. Scope and Limitations 53 3.2. Naming 54 3.2.1. Domain Name System (DNS) 55 3.2.2. New Namespaces 56 3.3. Routing 57 3.3.1. Inter-domain Routing 58 3.3.2. Routing Integrity 59 3.3.3. Routing Algorithms 60 3.3.4. Mobile and Ad-Hoc Routing 61 3.4. Security 62 3.4.1. Formal Methods 63 3.4.2. Key Management 64 3.4.3 Cryptography 65 3.4.4 Security for Distributed Computing 66 3.4.5. Deployment Considerations in Security 67 3.4.6. Denial of Service Protection 68 3.5. Network Management 69 3.5.1. Managing Networks, Not Devices 70 3.5.2. Enhanced Monitoring Capabilities 71 3.5.3. Customer Network Management 72 3.5.4. Autonomous Network Management 73 3.6. Quality of Service 74 3.6.1. Inter-Domain QoS Architecture 75 3.6.2. New Queuing Disciplines 76 3.7. Congestion control. 77 3.8. Studying the Evolution of the Internet Infrastructure 78 3.9. Middleboxes 79 3.10. Internet Measurement 80 3.11. Applications 81 3.12. Meeting the Needs of the Future 82 3.13. Freely Distributable Prototypes 83 3.14. Additional topics 84 4. Conclusions 85 5. Acknowledgements 86 6. Security Considerations 87 7. IANA Considerations 88 9. AUTHORS' ADDRESSES 90 1. Introduction 92 This document discusses the history of funding for Internet research, 93 expresses concern about the current state of such funding, and 94 outlines several specific areas that the IAB believes merit 95 additional research. Current funding levels for Internet research 96 are not generally adequate, and several important research areas are 97 significantly underfunded. This situation needs to be rectified for 98 the Internet to continue its evolution and development. 100 1.1. Document Organization 102 The first part of the document is a high-level discussion of the 103 history of funding for Internet research to provide some historical 104 context to this document. The early funding of Internet research was 105 largely from the U.S. government, followed by a period in the second 106 half of the 1990s of commercial funding and of funding from several 107 governments. However, the commercial funding for Internet research 108 has been reduced due to the recent economic downturn. 110 The second part of the document provides an incomplete set of open 111 Internet research topics. These are only examples, intended to 112 illustrate the breadth of open research topics. This second section 113 supports the general thesis that ongoing research is needed to 114 further the evolution of the Internet infrastructure. This includes 115 research on the medium-time-scale evolution of the Internet 116 infrastructure as well as research on longer-time-scale grand 117 challenges. This also includes many research issues that are already 118 being actively investigated in the Internet research community. 120 Areas that are discussed in this section include the following: 121 naming, routing, security, network management, and transport. Issues 122 that require more research also include more general architectural 123 issues such as layering and communication between layers. In 124 addition, general topics discussed in this section include modeling, 125 measurement, simulation, test-beds, etc. We are focusing on topics 126 that are related to the IETF and IRTF (Internet Research Task Force) 127 agendas. (E.g., Grid issues are not discussed in this document 128 because they are addressed through the Global Grid Forum and other 129 Grid-specific organizations, not in the IETF.) 131 Where possible, the examples in this document point to separate 132 documents on these issues, and only give a high-level summary of the 133 issues raised in those documents. 135 1.2. IAB Concerns 137 Recently, in the aftermath of September 11 2001, there seems to be a 138 renewed interest by governments in funding research for Internet- 139 related security issues. From [Jackson02]: "It is generally agreed 140 that the security and reliability of the basic protocols underlying 141 the Internet have not received enough attention because no one has a 142 proprietary interest in them". 144 That quote brings out a key issue in funding for Internet research, 145 which is that because no single organization (e.g., no single 146 government, software company, equipment vendor, or network operator) 147 has a sense of ownership of the global Internet infrastructure, 148 research on the general issues of the Internet infrastructure are 149 often not adequately funded. In our current challenging economic 150 climate, it is not surprising that commercial funding sources are 151 more likely to fund that research that leads to a direct competitive 152 advantage. 154 The principal thesis of this document is that if commercial funding 155 is the main source of funding for future Internet research, the 156 future of the Internet infrastructure could be in trouble. In 157 addition to issues about which projects were funded, the funding 158 source can also affect the content of the research, for example, 159 towards or against the development of open standards, or taking 160 varying degrees of care about the effect of the developed protocols 161 on the other traffic on the Internet. 163 At the same time, many significant research contributions in 164 networking have come from commercial funding. However, for most of 165 the topics in this document, relying solely on commercially-funded 166 research would not be adequate. Much of today's commercial funding 167 is focused on technology transition, taking results from non- 168 commercial research and putting them into shipping commercial 169 products. We have not tried to delve into each of the research 170 issues below to discuss, for each issue, what are the potentials and 171 limitations of commercial funding for research in that area. 173 On a more practical note, if there was no commercial funding for 174 Internet research, then few research projects would be taken to 175 completion with implementations, deployment, and follow-up 176 evaluation. 178 While it is theoretically possible for there to be too much funding 179 for Internet research, that is far from the current problem. There 180 is also much that could be done within the network research community 181 to make Internet research more focused and productive, but that would 182 belong in a separate document. 184 1.3. Contributions to this Document 186 A number of people have directly contributed text for this document, 187 even though, following current conventions, the official RFC author 188 list includes only the key editors of the document. The 189 Acknowledgements section at the end of the document thanks other 190 people who contributed to this document in some form. 192 2. History of Internet Research and Research Funding 194 2.1. Prior to 1980 196 Most of the early research into packet-switched networks was 197 sponsored by the U.S. Defense Advanced Research Projects Agency 198 (DARPA) [CSTB99]. This includes the initial design, implementation, 199 and deployment of the ARPAnet connecting several universities and 200 other DARPA contractors. The ARPAnet originally came online in the 201 late 1960s. It grew in size during the 1970s, still chiefly with 202 DARPA funding, and demonstrated the utility of packet-switched 203 networking. 205 DARPA funding for Internet design started in 1973, just four years 206 after the initial ARPAnet deployment. The support for Internet 207 design was one result of prior DARPA funding for packet radio and 208 packet satellite research. The existence of multiple networks 209 (ARPAnet, packet radio, and packet satellite) drove the need for 210 internetworking research. The Internet arose in large measure as a 211 consequence of DARPA research funding for these three networks -- and 212 arise only incidentally from the commercially-funded work at Xerox 213 PARC on Ethernet. 215 2.2. 1980s and early 1990s 217 The ARPAnet converted to the Internet Protocol (IP) on January 1, 218 1983, approximately 20 years before this document was written. 219 Throughout the 1980s, the U.S. Government continued strong research 220 and development funding for Internet technology. DARPA continued to 221 be the key funding source, but was supplemented by other DoD (U.S. 222 Department of Defense) funding (e.g., via the Defense Data Network 223 (DDN) program of the Defense Communication Agency (DCA)) and other 224 U.S. Government funding (e.g., U.S. Department of Energy (DoE) 225 funding for research networks at DoE national laboratories, (U.S.) 226 National Science Foundation (NSF) funding for academic institutions). 227 This funding included basic research, applied research (including 228 freely distributable prototypes), the purchase of IP-capable 229 products, and operating support for the IP-based government networks 230 such as ARPAnet, ESnet, MILnet, the NASA Science Internet, and 231 NSFnet. 233 During the 1980s, the U.S. DoD desired to leave the business of 234 providing operational network services to academic institutions, so 235 funding for most academic activities moved over to the NSF during the 236 decade. NSF's initial work included sponsorship of CSnet in 1981. 237 By the 1986, NSF was also sponsoring various research projects into 238 networking (e.g., Mills' work on Fuzzballs). In the late 1980s, NSF 239 created the NSFnet backbone and sponsored the creation of several NSF 240 regional networks (e.g., SURAnet) and interconnections with several 241 international research networks. NSF also funded gigabit networking 242 research, through the Corporation for National Research Initiatives 243 (CNRI), starting in the late 1980s. It is important to note that the 244 NSF sponsorship was focused on achieving core NSF goals, such as 245 connecting scientists at leading universities to NSF supercomputing 246 centers. The needs of high-performance remote access to 247 supercomputers drove the overall NSFnet performance. As a side 248 effect, this meant that students and faculty at those universities 249 enjoyed a relatively high-performance Internet environment. As those 250 students graduated, they drove both commercial use of the Internet 251 and the nascent residential market. It is no accident that this was 252 the environment from which the world wide web emerged. 254 Most research funding outside the U.S. during the 1980s and early 255 1990s was focused on the ISO OSI networking project or on then-new 256 forms of network media (e.g., wireless, broadband access). The 257 European Union was a significant source of research funding for the 258 networking community in Europe during this period. Some of the best 259 early work in gigabit networking was undertaken in the UK and Sweden. 261 2.3. Mid-1990s to 2003 263 Starting in the middle 1990s, U.S. Government funding for Internet 264 research and development was significantly reduced. The premise for 265 this was that the growing Internet industry would pay for whatever 266 research and development that was needed. Some funding for Internet 267 research and development has continued in this period from European 268 and Asian organizations (e.g., the WIDE Project in Japan [WIDE]). 269 Reseaux IP Europeens [RIPE] is an example of market-funded networking 270 research in Europe during this period. 272 Experience during this period has been that commercial firms have 273 often focused on donating equipment to academic institutions and 274 promoting somewhat vocationally-focused educational projects. Many 275 of the commercially-funded research and development projects appear 276 to have been selected because they appeared likely to give the 277 funding source a specific short-term economic advantage over its 278 competitors. Higher risk, more innovative research proposals 279 generally have not been funded by industry. A common view in Silicon 280 Valley has been that established commercial firms are not very good 281 at transitioning cutting edge research into products, but were 282 instead good at buying small startup firms who had successfully 283 transitioned such cutting edge research into products. 284 Unfortunately, small startup companies are generally unable 285 financially to fund any research themselves. 287 2.4. Current Status 289 The result of reduced U.S. Government funding and profit-focused, 290 low-risk, short-term industry funding has been a decline in higher- 291 risk but more innovative research activities. Industry has also been 292 less interested in research to evolve the overall Internet 293 architecture, because such work does not translate into a competitive 294 advantage for the firm funding such work. 296 The IAB believes that it would be helpful for governments and other 297 non-commercial sponsors to increase their funding of both basic 298 research and applied research relating to the Internet, and to 299 sustain these funding levels going forward. 301 3. Open Internet Research Topics 303 This section primarily discusses some specific topics that the IAB 304 believes merit additional research. Research, of course, includes 305 not just devising a theory, algorithm, or mechanism to accomplish a 306 goal, but also evaluating the general efficacy of the approach and 307 then the benefits vs. the costs of deploying that algorithm or 308 mechanism. Important cautionary notes about this discussion are 309 given in the next sub-section. This particular set of topics is not 310 intended to be comprehensive, but instead is intended to demonstrate 311 the breadth of open Internet research questions. 313 Other discussions of problems of the Internet that merit further 314 research include the following: [CIPB02,Claffy03a,,NSF03a,NSF03b]. 316 3.1. Scope and Limitations 318 This document is NOT intended as a guide for public funding agencies 319 as to exactly which projects or proposals should or should not be 320 funded. 322 In particular, this document is NOT intended to be a comprehensive 323 list of *all* of the research questions that are important to further 324 the evolution of the Internet; that would be a daunting task, and 325 would presuppose a wider and more intensive effort than we have 326 undertaken in this document. 328 Similarly, this document is not intended to list the research 329 questions that are judged to be only of peripheral importance, or to 330 survey the current (global; governmental, commercial, and academic) 331 avenues for funding for Internet research, or to make specific 332 recommendations about which areas need additional funding. The 333 purpose of the document is to persuade the reader that ongoing 334 research is needed towards the continued evolution of the Internet 335 infrastructure; the purpose is not to make binding pronouncements 336 about which specific areas are and are not worthy of future funding. 338 For some research clearly relevant to the future evolution of the 339 Internet, there are grand controversies between competing proposals 340 or competing schools of thought; it is not the purpose of this 341 document to take positions in these controversies, or to take 342 positions on the nature of the solutions for areas needing further 343 research. 345 That all carefully noted, the remainder of this section discusses a 346 broad set of research areas, noting a subset of particular topics of 347 interest in each of those research areas. Again, this list is NOT 348 comprehensive, but rather is intended to suggest that a broad range 349 of ongoing research is needed, and to propose some candidate topics. 351 3.1.1 Terminology 353 Several places in this document refer to 'network operators'. By 354 that term, we intend to include anyone or any organization that 355 operates an IP-based network; we are not using that term in the 356 narrow meaning of commercial network service providers. 358 3.2. Naming 360 The Internet currently has several different namespaces, including IP 361 addresses, sockets (specified by the IP address, upper-layer 362 protocol, and upper-layer port number), Autonomous System (AS) 363 number, and the Fully-Qualified Domain Name (FQDN). Many of the 364 Internet's namespaces are supported by the widely deployed Domain 365 Name System [RFC-3467] or by various Internet applications [RFC-2407, 366 Section 4.6.2.1] 368 3.2.1. Domain Name System (DNS) 370 The DNS system, while it works well given its current constraints, 371 has several stress points. 373 The current DNS system relies on UDP for transport, rather than SCTP 374 or TCP. Given the very large number of clients using a typical DNS 375 server, it is desirable to minimize the state on the DNS server side 376 of the connection. UDP does this well, so is a reasonable choice, 377 though this has other implications, for example a reliance on UDP 378 fragmentation. With IPv6, intermediate fragmentation is not allowed 379 and Path MTU Discovery is mandated. However, the amount of state 380 required to deploy Path MTU Discovery for IPv6 on a DNS server might 381 be a significant practical problem. 383 One implication of this is that research into alternative transport 384 protocols, designed more for DNS-like applications where there are 385 very many clients using each server, might be useful. Of particular 386 interest would be transport protocols with little burden for the DNS 387 server, even if that increased the burden somewhat for the DNS 388 client. 390 Additional study of DNS caching, both currently available caching 391 techniques and also of potential new caching techniques, might be 392 helpful in finding ways to reduce the offered load for a typical DNS 393 server. In particular, examination of DNS caching through typical 394 commercial firewalls might be interesting if it lead to alternative 395 firewall implementations that were less of an obstacle to DNS 396 caching. 398 The community lacks a widely-agreed-upon set of metrics for measuring 399 DNS server performance. It would be helpful if people would 400 seriously consider what characteristics of the DNS system should be 401 measured. 403 Some in the community would advocate replacing the current DNS system 404 with something better. Past attempts to devise a better approach 405 have not yielded results that persuaded the community to change. 406 Proposed work in this are could be very useful, but might require 407 careful scrutiny to avoid falling into historic design pitfalls. 409 With regards to DNS security, major technical concerns include 410 finding practical methods for signing very large DNS zones (e.g., 411 .COM), practical methods for incremental deployment of DNS security, 412 and tools to make it easier to manage secure DNS infrastructure. 414 Most users are unable to distinguish a DNS-related failure from a 415 more general network failure. Hence, maintaining the integrity and 416 availability of the Domain Name System is very important for the 417 future health of the Internet. 419 3.2.2. New Namespaces 421 Additionally, the Namespace Research Group (NSRG) of the Internet 422 Research Task Force (IRTF) studied adding one or more additional 423 namespaces to the Internet Architecture [LD2002]. Many members of the 424 IRTF NSRG believe that there would be significant architectural 425 benefit to adding one or more additional namespaces to the Internet 426 Architecture. Because smooth consensus on that question or on the 427 properties of a new namespace was not obtained, the IRTF NSRG did not 428 make a formal recommendation to the IETF community regarding 429 namespaces. The IAB believes that this is an open research question 430 worth examining further. 432 Finally, we believe that future research into the evolution of 433 Internet-based distributed computing might well benefit from studying 434 adding additional namespaces as part of a new approach to distributed 435 computing. 437 3.3. Routing 439 The currently deployed unicast routing system works reasonably well 440 for most users. However, the current unicast routing architecture is 441 suboptimal in several areas, including the following: end-to-end 442 convergence times in global-scale catenets (a system of networks 443 interconnected via gateways); the ability of the existing inter- 444 domain path-vector algorithm to scale well beyond 200K prefixes; the 445 ability of both intra-domain and inter-domain routing to use multiple 446 metrics and multiple kinds of metrics concurrently; and the ability 447 of IPv4 and IPv6 to support widespread site multi-homing without 448 undue adverse impact on the inter-domain routing system. Integrating 449 policy into routing is also a general concern, both for intra-domain 450 and inter-domain routing. In many cases, routing policy is directly 451 tied to economic issues for the network operators, so applied 452 research into routing ideally would consider economic considerations 453 as well as technical considerations. 455 This is an issue for which the commercial interest is clear, but that 456 seems unlikely to be solved through commercial funding for research, 457 in the absence of a consortium of some type. 459 3.3.1. Inter-domain Routing 461 The current operational inter-domain routing system has between 462 150,000 and 200,000 routing prefixes in the default-free zone (DFZ) 463 [RFC-3221]. ASIC technology obviates concerns about the ability to 464 forward packets at very high speeds. ASIC technology also obviates 465 concerns about the time required to perform longest-prefix-match 466 computations. However, some senior members of the Internet routing 467 community have concerns that the end-to-end convergence properties of 468 the global Internet might hit fundamental algorithmic limitations 469 (i.e. not hardware limitations) when the DFZ is somewhere between 470 200,000 and 300,000 prefixes. Research into whether this concern is 471 well-founded in scientific terms seems very timely. 473 Separately from the above concern, recent work has shown that there 474 can be significant BGP convergence issues today. At present, it 475 appears that the currently observed convergence issues relate to how 476 BGP has been configured by network operators, rather than being any 477 sort of fundamental algorithmic limitation [MGVK02]. This convergence 478 time issue makes the duration of the apparent network outage much 479 longer than it should be. Additional applied research into which 480 aspects of a BGP configuration have the strongest impact on 481 convergence times would help mitigate the currently observed 482 operational issues. 484 Also, inter-domain routing currently requires significant human 485 engineering of specific inter-AS paths to ensure that reasonably 486 optimal paths are used by actual traffic. Ideally, the inter-domain 487 routing system would automatically cause reasonably optimal paths to 488 be chosen. Recent work indicates that improved BGP policy mechanisms 489 might help ensure that reasonably optimal paths are normally used for 490 inter-domain IP traffic. [SMA03] Continued applied research in this 491 area might lead to substantially better technical approaches. 493 The current approach to site multi-homing has the highly undesirable 494 side-effect of significantly increasing the growth rate of prefix 495 entries in the DFZ (by impairing the deployment of prefix 496 aggregation). Research is needed into new routing architectures that 497 can support large-scale site multi-homing without the undesirable 498 impacts on inter-domain routing of the current multi-homing 499 technique. 501 The original application for BGP was in inter-domain routing, 502 primarily within service provider networks but also with some use by 503 multi-homed sites. However, some are now trying to use BGP in other 504 contexts, for example highly mobile environments, where it is less 505 obviously well suited. Research into inter-domain routing and/or 506 intra-domain policy routing might lead to other approaches for any 507 emerging environments where the current BGP approach is not the 508 optimal one. 510 3.3.2. Routing Integrity 512 Recently there has been increased awareness of the longstanding issue 513 of deploying strong authentication into the Internet inter-domain 514 routing system. Currently deployed mechanisms (e.g., BGP TCP MD5 515 [RFC2385], OSPF MD5, RIP MD5 [RFC2082]) provide cryptographic 516 authentication of routing protocol messages, but no authentication of 517 the actual routing data. Recent proposals (e.g., S-BGP [KLMS2000]) 518 for improving this in inter-domain routing appear difficult to deploy 519 across the Internet, in part because of their reliance on a single 520 trust hierarchy (e.g., a single PKI). Similar proposals (e.g., OSPF 521 with Digital Signatures, [RFC2154]) for intra-domain routing are 522 argued to be computationally infeasible to deploy in a large network. 524 A recurring challenge with any form of inter-domain routing 525 authentication is that there is no single completely accurate source 526 of truth about which organizations have the authority to advertise 527 which address blocks. Alternative approaches to authentication of 528 data in the routing system need to be developed. In particular, the 529 ability to perform partial authentication of routing data would 530 facilitate incremental deployment of routing authentication 531 mechanisms. Also, the ability to use non-hierarchical trust models 532 (e.g., the web of trust used in the PGP application) might facilitate 533 incremental deployment and might resolve existing concerns about 534 centralized administration of the routing system, hence merits 535 additional study and consideration. 537 3.3.3. Routing Algorithms 539 The current Internet routing system relies primarily on two 540 algorithms. Link-state routing uses the Dijkstra algorithm 541 [Dijkstra59]. Distance-Vector routing (e.g., RIP) and Path-Vector 542 routing (e.g., BGP) use the Bellman-Ford algorithm [Bellman1957, 543 FF1962]. Additional ongoing basic research into graph theory as 544 applied to routing is worthwhile and might yield algorithms that 545 would enable a new routing architecture or otherwise provide 546 improvements to the routing system. 548 Currently deployed multicast routing relies on the Deering RPF 549 algorithm [Deering1988]. Ongoing research into alternative multicast 550 routing algorithms and protocols might help alleviate current 551 concerns with the scalability of multicast routing. 553 The deployed Internet routing system assumes that the shortest path 554 is always the best path. This is provably false, however it is a 555 reasonable compromise given the routing protocols currently 556 available. The Internet lacks deployable approaches for policy-based 557 routing or routing with alternative metrics (i.e. some metric other 558 than the number of hops to the destination). Examples of alternative 559 policies include: the path with lowest monetary cost; the path with 560 the lowest probability of packet loss; the path with minimized 561 jitter; and the path with minimized latency. Policy metrics also 562 need to take business relationships into account. Historic work on 563 QoS-based routing has tended to be unsuccessful in part because it 564 did not adequately consider economic and commercial considerations of 565 the routing system and in part because of inadequate consideration of 566 security implications. 568 Transitioning from the current inter-domain routing system to any new 569 inter-domain routing system is unlikely to be a trivial exercise. So 570 any proposal for a new routing system needs to carefully consider and 571 document deployment strategies, transition mechanisms, and other 572 operational considerations. Because of the cross-domain 573 interoperability aspect of inter-domain routing, smooth transitions 574 from one inter-domain routing system are likely to be difficult to 575 accomplish. Separately, the inter-domain routing system lacks strong 576 market forces that would encourage migration to better technical 577 approaches. Hence, it appears unlikely that the commercial sector 578 will be the source of a significantly improved inter-domain routing 579 system. 581 3.3.4. Mobile and Ad-Hoc Routing 583 While some of the earliest DARPA-sponsored networking research 584 involved packet radio networks, mobile routing [IM1993] and mobile 585 ad-hoc routing [RFC2501] are relatively recent arrivals in the 586 Internet, and are not yet widely deployed. The current approaches 587 are not the last word in either of those arenas. We believe that 588 additional research into routing support for mobile hosts and mobile 589 networks is needed. Additional research for ad-hoc mobile hosts and 590 mobile networks is also worthwhile. Ideally, mobile routing and 591 mobile ad-hoc routing capabilities should be native inherent 592 capabilities of the Internet routing architecture. This probably 593 will require a significant evolution from the existing Internet 594 routing architecture. (NB: The term "mobility" as used here is not 595 limited to mobile telephones, but instead is very broadly defined, 596 including laptops that people carry, cars/trains/aircraft, and so 597 forth.) 599 Included in this topic are a wide variety of issues. The more 600 distributed and dynamic nature of partially or completely self- 601 organizing routing systems (including the associated end nodes) 602 creates unique security challenges (especially relating to 603 Authorization, Authentication and Accounting, and relating to key 604 management). Scalability of wireless networks can be difficult to 605 measure or to achieve. Enforced hierarchy is one approach, but can 606 be very limiting. Alternative, less constraining approaches to 607 wireless scalability are desired. Because wireless link-layer 608 protocols usually have some knowledge of current link characteristics 609 such as link quality, sublayer congestion conditions, or transient 610 channel behavior, it is desirable to find ways to let network-layer 611 routing use such data. This raises architectural questions of what 612 the proper layering should be, which functions should be in which 613 layer, and also practical considerations of how and when such 614 information sharing should occur in real implementations. 616 3.4. Security 618 The Internet has a reputation for not having sufficient security. In 619 fact, the Internet has a number of security mechanisms standardized, 620 some of which are widely deployed. However, there are a number of 621 open research questions relating to Internet security. In 622 particular, security mechanisms need to be incrementally deployable 623 and easy to use. "[Security] technology must be easy to use, or it 624 will not be configured correctly. If mis-configured, security will 625 be lost, but things will `work'" [Schiller03]. 627 3.4.1. Formal Methods 629 There is an ongoing need for funding of basic research relating to 630 Internet security, including funding of formal methods research that 631 relates to security algorithms, protocols, and systems. 633 For example, it would be beneficial to have more formal study of non- 634 hierarchical trust models (e.g., PGP's Web-of-Trust model). Use of a 635 hierarchical trust model can create significant limitations in how 636 one might approach securing components of the Internet, for example 637 the inter-domain routing system. So research to develop new trust 638 models suited for the Internet or on the applicability of existing 639 non-hierarchical trust models to existing Internet problems would be 640 worthwhile. 642 While there has been some work on the application of formal methods 643 to cryptographic algorithms and cryptographic protocols, existing 644 techniques for formal evaluation of algorithms and protocols lack 645 sufficient automation. This lack of automation means that many 646 protocols aren't formally evaluated in a timely manner. This is 647 problematic for the Internet because formal evaluation has often 648 uncovered serious anomalies in cryptographic protocols. The creation 649 of automated tools for applying formal methods to cryptographic 650 algorithms and/or protocols would be very helpful. 652 3.4.2. Key Management 654 A recurring challenge to the Internet community is how to design, 655 implement, and deploy key management appropriate to the myriad 656 security contexts existing in the global Internet. Most current work 657 in unicast key management has focused on hierarchical trust models, 658 because much of the existing work has been driven by corporate or 659 military "top-down" operating models. 661 The paucity of key management methods applicable to non-hierarchical 662 trust models (see above) is a significant constraint on the 663 approaches that might be taken to secure components of the Internet. 665 Research focused on removing those constraints by developing 666 practical key management methods applicable to non-hierarchical trust 667 models would be very helpful. 669 Topics worthy of additional research include key management 670 techniques, such as non-hierarchical key management architectures 671 (e.g., to support non-hierarchical trust models; see above), that are 672 useful by ad-hoc groups in mobile networks and/or distributed 673 computing. 675 Although some progress has been made in recent years, scalable 676 multicast key management is far from being a solved problem. 677 Existing approaches to scalable multicast key management add 678 significant constraints on the problem scope in order to come up with 679 a deployable technical solution. Having a more general approach to 680 scalable multicast key management (i.e. one having broader 681 applicability and fewer constraints) would enhance the Internet's 682 capabilities. 684 In many cases, attribute negotiation is an important capability of a 685 key management protocol. Experience with the Internet Key Exchange 686 (IKE) to date has been that it is unduly complex. Much of IKE's 687 complexity derives from its very general attribute negotiation 688 capabilities. A new key management approach that supported 689 significant attribute negotiation without creating challenging levels 690 of deployment and operations complexity would be helpful. 692 3.4.3 Cryptography 694 There is an ongoing need to continue the open-world research funding 695 into both cryptography and cryptanalysis. Most governments focus 696 their cryptographic research in the military-sector. While this is 697 understandable, those efforts often have limited (or no) publications 698 in the open literature. Since the Internet engineering community 699 must work from the open literature, it is important that open-world 700 research continues in the future. 702 3.4.4 Security for Distributed Computing 704 MIT's Project Athena was an important and broadly successful research 705 project into distributed computing. Project Athena developed the 706 Kerberos [RFC-1510] security system, which has significant deployment 707 today in campus environments. However, inter-realm Kerberos is 708 neither as widely deployed nor perceived as widely successful as 709 single-realm Kerberos. The need for scalable inter-domain user 710 authentication is increasingly acute as ad-hoc computing and mobile 711 computing become more widely deployed. Thus, work on scalable 712 mechanisms for mobile, ad-hoc, and non-hierarchical inter-domain 713 authentication would be very helpful. 715 3.4.5. Deployment Considerations in Security 717 Lots of work has been done on theoretically perfect security that is 718 impossible to deploy. Unfortunately, the S-BGP proposal is an 719 example of a good research product that has significant unresolved 720 deployment challenges. It is far from obvious how one could widely 721 deploy S-BGP without previously deploying a large-scale inter-domain 722 public-key infrastructure and also centralizing route advertisement 723 policy enforcement in the Routing Information Registries or some 724 similar body. Historically, public-key infrastructures have been 725 either very difficult or impossible to deploy at large scale. 726 Security mechanisms that need additional infrastructure have not been 727 deployed well. We desperately need security that is general, easy to 728 install, and easy to manage. 730 3.4.6. Denial of Service Protection 732 Historically, the Internet community has mostly ignored pure Denial 733 of Service (DoS) attacks. This was appropriate at one time since 734 such attacks were rare and are hard to defend against. However, one 735 of the recent trends in adversarial software (e.g., viruses, worms) 736 has been the incorporation of features that turn the infected host 737 into a "zombie". Such zombies can be remotely controlled to mount a 738 distributed denial of service attack on some victim machine. In many 739 cases, the authorized operators of systems are not aware that some or 740 all of their systems have become zombies. It appears that the 741 presence of non-trivial numbers of zombies in the global Internet is 742 now endemic, which makes distributed denial of service attacks a much 743 larger concern. So Internet threat models need to assume the 744 presence of such zombies in significant numbers. This makes the 745 design of protocols resilient in the presence of distributed denial 746 of service attacks very important to the health of the Internet. 747 Some work has been done on this front [Savage00], [MBFIPS01], but 748 more is needed. 750 3.5. Network Management 752 The Internet had early success in network device monitoring with the 753 Simple Network Management Protocol (SNMP) and its associated 754 Management Information Base (MIB). There has been comparatively less 755 success in managing networks, in contrast to the monitoring of 756 individual devices. Furthermore, there are a number of operator 757 requirements not well supported by the current Internet management 758 framework. It is desirable to enhance the current Internet network 759 management architecture to more fully support operational needs. 761 Unfortunately, network management research has historically been very 762 underfunded. Operators have complained that existing solutions are 763 inadequate. Research is needed to find better solutions. 765 3.5.1. Managing Networks, Not Devices 767 At present there are few or no good tools for managing a whole 768 network instead of isolated devices. For example, the lack of 769 appropriate network management tools has been cited as one of the 770 major barriers to the widespread deployment of IP multicast [Diot00, 771 SM03]. Current network management protocols, such as the Simple 772 Network Management Protocol (SNMP), are fine for reading status of 773 well-defined objects from individual boxes. Managing networks 774 instead of isolated devices requires the ability to view the network 775 as a large distributed system. Research is needed on scalable 776 distributed data aggregation mechanisms, scalable distributed event 777 correlation mechanisms, and distributed and dependable control 778 mechanisms. 780 Applied research into methods of managing sets of networked devices 781 seems worthwhile. Ideally, such a management approach would support 782 distributed management, rather than being strictly centralized. 784 3.5.2. Enhanced Monitoring Capabilities 786 SNMP does not always scale well to monitoring large numbers of 787 objects in many devices in different parts of the network. An 788 alternative approach worth exploring is how to provide scalable and 789 distributed monitoring, not on individual devices, but instead on 790 groups of devices and the network-as-a-whole. This requires scalable 791 techniques for data aggregation and event correlation of network 792 status data originating from numerous locations in the network. 794 3.5.3. Customer Network Management 796 An open issue related to network management is helping users and 797 others to identify and resolve problems in the network. If a user 798 can't access a web page, it would be useful if the user could find 799 out, easily, without having to run ping and traceroute, whether the 800 problem was that the web server was down, that the network was 801 partitioned due to a link failure, that there was heavy congestion 802 along the path, that the DNS name couldn't be resolved, that the 803 firewall prohibited the access, or that some other specific event 804 occurred. 806 3.5.4. Autonomous Network Management 808 More research is needed to improve the degree of automation achieved 809 by network management systems and to localize management. Autonomous 810 network management might involve the application of control theory, 811 artificial intelligence or expert system technologies to network 812 management problems. 814 3.6. Quality of Service 816 There has been an intensive body of research and development work on 817 adding QoS to the Internet architecture for more than ten years now 818 [RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210], yet we still 819 don't have end-to-end QoS in the Internet [RFC-2990, RFC-3387]. The 820 IETF is good at defining individual QoS mechanisms, but poor at work 821 on deployable QoS architectures. Thus, while Differentiated Services 822 (DiffServ) mechanisms have been standardized as per-hop behaviors, 823 there is still much to be learned about the deployment of that or 824 other QoS mechanisms for end-to-end QoS. In addition to work on 825 purely technical issues, this includes close attention to the 826 economic models and deployment strategies that would enable an 827 increased deployment of QoS in the network. 829 In many cases, deployment of QoS mechanisms would significantly 830 increase operational security risks [RFC-2990], so any new research 831 on QoS mechanisms or architectures ought to specifically discuss the 832 potential security issues associated with the new proposal(s) and how 833 to mitigate those security issues. 835 In some cases, the demand for QoS mechanisms has been diminished by 836 the development of more resilient voice/video coding techniques that 837 are better suited for the best-effort Internet than the older coding 838 techniques that were originally designed for circuit-switched 839 networks. 841 One of the factors that has blunted the demand for QoS has been the 842 transition of the Internet infrastructure from heavy congestion in 843 the early 1990s, to overprovisioning in backbones and in many 844 international links now. Thus, research in QoS mechanisms also has 845 to include some careful attention to the relative costs and benefits 846 of QoS in different places in the network. Applied research into QoS 847 should include explicit consideration of economic issues of deploying 848 and operating a QoS-enabled IP network [Clark02]. 850 3.6.1. Inter-Domain QoS Architecture 852 Typically, a router in the deployed inter-domain Internet provides 853 best-effort forwarding of IP packets, without regard for whether the 854 source or destination of the packet is a direct customer of the 855 operator of the router. This property is a significant contributor 856 to the current scalability of the global Internet and contributes to 857 the difficulty of deploying inter-domain Quality of Service (QoS) 858 mechanisms. 860 Deploying existing Quality-of-Service (QoS) mechanisms, for example 861 Differentiated Services or Integrated Services, across an inter- 862 domain boundary creates a significant and easily exploited denial-of- 863 service vulnerability for any network that provides inter-domain QoS 864 support. This has caused network operators to refrain from 865 supporting inter-domain QoS. The Internet would benefit from 866 additional research into alternative approaches to QoS, particularly 867 into approaches that do not create such vulnerabilities and can be 868 deployed end-to-end [RFC-2990]. 870 Also, current business models are not consistent with inter-domain 871 QoS, in large part because it is impractical or impossible to 872 authenticate the identity of the sender of would-be preferred traffic 873 while still forwarding traffic at line-rate. Absent such an ability, 874 it is unclear how a network operator could bill or otherwise recover 875 costs associated with providing that preferred service. So any new 876 work on inter-domain QoS mechanisms and architectures needs to 877 carefully consider the economic and security implications of such 878 proposals. 880 3.6.2. New Queuing Disciplines 882 The overall Quality-of-Service for traffic is in part determined by 883 the scheduling and queue management mechanisms at the routers. While 884 there are a number of existing mechanisms (e.g., RED) that work well, 885 it is possible that improved active queuing strategies might be 886 devised. Mechanisms that lowered the implementation cost in IP 887 routers might help increase deployment of active queue management, 888 for example. 890 3.7. Congestion control. 892 TCP's congestion avoidance and control mechanisms, from 1988 893 [Jacobson88], have been a key factor in maintaining the stability of 894 the Internet, and are used by the bulk of the Internet's traffic. 895 However, the congestion control mechanisms of the Internet need to be 896 expanded and modified to meet a wide range of new requirements, from 897 new applications such as streaming media and multicast to new 898 environments such as wireless networks or very high bandwidth paths, 899 and new requirements for minimizing queueing delay. While there are 900 significant bodies of work in several of these issues, considerably 901 more needs to be done. 903 We would note that research on TCP congestion control is also not yet 904 "done", with much still to be accomplished in high-speed TCP, or in 905 adding robust performance over paths with significant reordering, 906 intermittent connectivity, non-congestive packet loss, and the like. 908 Several of these issues bring up difficult fundamental questions 909 about the potential costs and benefits of increased communication 910 between layers. Would it help transport to receive hints or other 911 information from routing, from link layers, or from other transport- 912 level connections? If so, what would be the cost to robust operation 913 across diverse environments? 915 For congestion control mechanisms in routers, active queue management 916 and Explicit Congestion Notification are generally not yet deployed, 917 and there are a range of proposals, in various states of maturity, in 918 this area. At the same time, there is a great deal that we still do 919 not understand about the interactions of queue management mechanisms 920 with other factors in the network. Router-based congestion control 921 mechanisms are also needed for detecting and responding to aggregate 922 congestion such as in Distributed Denial of Service attacks and flash 923 crowds. 925 As more applications have the need to transfer very large files over 926 high delay-bandwidth-product paths, the stresses on current 927 congestion control mechanisms raise the question of whether we need 928 more fine-grained feedback from routers. This includes the challenge 929 of allowing connections to avoid the delays of slow-start, and to 930 rapidly make use of newly-available bandwidth. On a more general 931 level, we don't understand the potential and limitations for best- 932 effort traffic over high delay-bandwidth-product paths, given the 933 current feedback from routers, or the range of possibilities for more 934 explicit feedback from routers. 936 There is also a need for long-term research in congestion control 937 that is separate from specific functional requirements like the ones 938 listed above. We know very little about congestion control dynamics 939 or traffic dynamics of a large, complex network like the global 940 Internet, with its heterogeneous and changing traffic mixes, link- 941 level technologies, network protocols and router mechanisms, patterns 942 of congestion, pricing models, and the like. Expanding our knowledge 943 in this area seems likely to require a rich mix of measurement, 944 analysis, simulations, and experimentation. 946 3.8. Studying the Evolution of the Internet Infrastructure 948 The evolution of the Internet infrastructure has been frustratingly 949 slow and difficult, with long stories about the difficulties in 950 adding IPv6, QoS, multicast, and other functionality to the Internet. 951 We need a more scientific understanding of the evolutionary 952 potentials and evolutionary difficulties of the Internet 953 infrastructure. 955 This evolutionary potential is affected not only by the technical 956 issues of the layered IP architecture, but by other factors as well. 957 These factors include the changes in the environment over time (e.g., 958 the recent overprovisioning of backbones, the deployment of 959 firewalls), and the role of the standardization process. Economic 960 and public policy factors are also critical, including the central 961 fact of the Internet as a decentralized system, with key players 962 being not only individuals, but also ISPs, companies, and entire 963 industries. Deployment issues are also key factors in the evolution 964 of the Internet, including the continual chicken-and-egg problem of 965 having enough customers to merit rolling out a service whose utility 966 depends on the size of the customer base in the first place. 968 Overlay networks might serve as a transition technology for some new 969 functionality, with an initial deployment in overlay networks, and 970 with the new functionality moving later into the core if it seems 971 warranted. 973 There are also increased obstacles to the evolution of the Internet 974 in the form of increased complexity [WD02], unanticipated feature 975 interactions [Kruse00], interactions between layers [CWWS92], 976 interventions by middleboxes [RFC-3424], and the like. Because 977 increasing complexity appears inevitable, research is needed to 978 understand architectural mechanisms that can accommodate increased 979 complexity without decreasing robustness of performance in unknown 980 environments, and without closing off future possibilities for 981 evolution. More concretely, research is needed on how to evolve the 982 Internet will still maintaining its core strengths, such as the 983 current degree of global addressability of hosts, end-to-end 984 transparency of packet forwarding, and good performance for best- 985 effort traffic. 987 3.9. Middleboxes 989 Research is needed to address the challenges posed by the wide range 990 of middleboxes [RFC-3234]. This includes issues of security, 991 control, and data integrity, and on the general impact of middleboxes 992 on the architecture. 994 In many ways middleboxes are a direct outgrowth of commercial 995 interests, but there is a need to look beyond the near-term needs for 996 the technology, to research its broader implications and to explore 997 ways to improve how middleboxes are integrated into the architecture. 999 3.10. Internet Measurement 1001 A recurring challenge is measuring the Internet; there have been many 1002 discussions about the need for measurement studies as an integral 1003 part of Internet research [Claffy03]. In this discussion, we define 1004 measurement quite broadly. For example, there are numerous 1005 challenges in measuring performance along any substantial Internet 1006 path, particularly when the path crosses administrative domain 1007 boundaries. There are also challenges in measuring 1008 protocol/application usage on any high-speed Internet link. Many of 1009 the problems discussed above would benefit from increased frequency 1010 of measurement as well as improved quality of measurement on the 1011 deployed Internet. 1013 A key issue in network measurement is that most commercial Internet 1014 Service Providers consider the particular characteristics of their 1015 production IP network(s) to be trade secrets. Ways need to be found 1016 for cooperative measurement studies, e.g., to allow legitimate non- 1017 commercial researchers to be able to measure relevant network 1018 parameters while also protecting the privacy rights of the measured 1019 ISPs. 1021 Absent measured data, there is possibly an over-reliance on network 1022 simulations in some parts of the Internet research community and 1023 probably insufficient validation that existing network simulation 1024 models are reasonably good representations of the deployed Internet 1025 (or of some plausible future Internet) [FK02]. 1027 Without solid measurement of the current Internet behavior, it is 1028 very difficult to know what otherwise unknown operational problems 1029 exist that require attention, and it is equally difficult to fully 1030 understand the impact of changes (past or future) upon the Internet's 1031 actual behavioral characteristics. 1033 3.11. Applications 1035 Research is needed on a wide range of issues related to Internet 1036 applications. 1038 Taking email as one example application, research is needed on 1039 understanding the spam problem, and on investigating tools and 1040 techniques to mitigate the effects of spam, including tools and 1041 techniques that aid the implementation of legal and other non- 1042 technical anti-spam measures [ASRG]. "Spam" is a generic term for a 1043 range of significantly different types of unwanted bulk email, with 1044 many types of senders, content and traffic-generating techniques. As 1045 one part of controlling spam, we need to develop a much better 1046 understanding of its many, different characteristics and their 1047 interactions with each other. 1049 3.12. Meeting the Needs of the Future 1051 As network size, link bandwidth, CPU capacity, and the number of 1052 users all increase, research will be needed to ensure that the 1053 Internet of the future scales to meet these increasing demands. We 1054 have discussed some of these scaling issues in specific sections 1055 above. 1057 However, for all of the research questions discussed in this 1058 document, the goal of the research must be not only to meet the 1059 challenges already experienced today, but also to meet the challenges 1060 that can be expected to emerge in the future. 1062 3.13. Freely Distributable Prototypes 1064 U.S.'s DARPA has historically funded development of freely 1065 distributable implementations of various Internet technologies (e.g., 1066 TCP/IPv4, RSVP, IPv6, and IP security) in a variety of operating 1067 systems (e.g. 4.2 BSD, 4.3 BSD, 4.4 BSD, Tenex). Experience has 1068 shown that a good way to speed deployment of a new technology is to 1069 provide an unencumbered, freely-distributable prototype that can be 1070 incorporated into commercial products as well as non-commercial 1071 prototypes. Japan's WIDE Project has also funded some such work, 1072 primarily focused on IPv6 implementation for 4.4 BSD and Linux. 1073 [WIDE] We believe that applied research projects in networking will 1074 have an increased probability of success if the research project 1075 teams make their resulting software implementations freely available 1076 for both commercial and non-commercial uses. Examples of successes 1077 here include the DARPA funding of TCP/IPv4 integration into the 4.x 1078 BSD operating system [MBKQ96], DARPA/USN funding of ESP/AH design and 1079 integration into 4.4 BSD [Atk96], as well as separate DARPA/USN and 1080 WIDE funding of freely distributable IPv6 prototypes [Atk96, WIDE]. 1082 4. Conclusions 1084 This document has summarized the history of research funding for the 1085 Internet and highlighted examples of open research questions. The 1086 IAB believes that more research is required to further the evolution 1087 of the Internet infrastructure, and that consistent, sufficient non- 1088 commercial funding is needed to enable such research. 1090 In case there is any confusion, we are not in this document 1091 suggesting any direct or indirect role for the IAB, the IETF, or the 1092 IRTF in handling any funding for Internet research. 1094 5. Acknowledgements 1096 The people who directly contributed to this document in some form 1097 include the following: Ran Atkinson, Guy Almes, Rob Austein, Vint 1098 Cerf, Jon Crowcroft, Sally Floyd, James Kempf, Joe Macker, Craig 1099 Partridge, Vern Paxson, Juergen Schoenwaelder, and Mike St. Johns. 1101 We are also grateful to Kim Claffy, Dave Crocker, Michael Eder, Eric 1102 Fleischman, Andrei Gurtov, Stephen Kent, J.P. Martin-Flatin, and 1103 Hilarie Orman for feedback on earlier drafts of this document. 1105 We have also drawn from the following reports: 1106 [CIPB02,IST02,NV02,NSF02,NSF03,NSF03a]. 1108 6. Security Considerations 1110 This document does not itself create any new security issues for the 1111 Internet community. Security issues within the Internet Architecture 1112 primarily are discussed in Section 3.4 above. 1114 7. IANA Considerations 1116 There are no IANA considerations regarding this document. 1118 Normative References 1120 There are no Normative References because this is an Informational 1121 document. 1123 Informative References 1125 [ASRG] Anti-Spam Research Group (ASRG) of the IRTF. URL 1126 "http://asrg.sp.am/". 1128 [Atk96] R. Atkinson et al., "Implementation of IPv6 in 4.4 BSD", 1129 Proceedings of USENIX 1996 Annual Technical Conference, USENIX 1130 Association, Berkeley, CA, USA. January 1996. URL 1131 http://www.chacs.itd.nrl.navy.mil/publications/CHACS/1996/ 1132 1996atkinson-USENIX.pdf 1134 [Bellman1957] R.E. Bellman, "Dynamic Programming", Princeton 1135 University Press, Princeton, NJ, 1957. 1137 [BL1976] D. E. Bell and L. J. LaPadula, "Secure Computer Systems: 1138 Unified Exposition and Multics Interpretation", MITRE Technical 1139 Report NMTR-1997 (ESD-TR-75-306), The Mitre Corporation, March 1976. 1141 [Claffy03] K. Claffy, "Priorities and Challenges in Internet 1142 Measurement, Simulation, and Analysis", Large Scale Network meeting, 1143 (US) National Science Foundation, Arlington, VA, USA. 10 June 2003. 1144 URL "http://www.caida.org/outreach/presentations/2003/lsn20030610/". 1146 [Claffy03a] K. Claffy, "Top Problems of the Internet and What 1147 Sysadmins and Researchers Can Do To Help", plenary talk at LISA'03, 1148 October 2003. URL 1149 "http://www.caida.org/outreach/presentations/2003/netproblems_lisa03/". 1151 [Clark02] D. D. Clark, "Deploying the Internet - why does it take so 1152 long and, can research help?", Large-Scale Networking Distinguished 1153 Lecture Series, (U.S.) National Science Foundation, Arlington, VA, 8 1154 January 2002. URL: http://www.ngi-supernet.org/conferences.html 1156 [CSTB99] Computer Science and Telecommunications Board, (U.S.) 1157 National Research Council, "Funding a Revolution: Government Support 1158 for Computing Research", National Academy Press, Washington, DC, 1159 1999. URL 1160 "http://www7.nationalacademies.org/cstb/pub_revolution.html". 1162 [CIPB02] Critical Infrastructure Protection Board, "National Strategy 1163 to Secure Cyberspace", The White House, Washington, DC, USA. 1164 September 2002, URL "http://www.whitehouse.gov/pcipb". 1166 [CWWS92] J. Crowcroft, I. Wakeman, Z. Wang, and D. Sirovica, "Is 1167 Layering Harmful?", IEEE Networks, Vol. 6, Issue 1, pp 20-24, January 1168 1992. 1170 [Diot00] C. Diot, et al., "Deployment Issues for the IP Multicast 1171 Service and Architecture", IEEE Network, January/February 2000. 1173 [Deering1988] S. Deering, "Multicast Routing in Internetworks and 1174 LANs", ACM Computer Communications Review, Volume 18, Issue 4, August 1175 1988. 1177 [Dijkstra59] E. Dijkstra, "A Note on Two Problems in Connexion with 1178 Graphs", Numerische Mathematik, 1, 1959, pp.269-271. 1180 [FF1962] L. R. Ford Jr. and D.R. Fulkerson, "Flows in Networks", 1181 Princeton University Press, Princeton, NJ, 1962. 1183 [FK02] S. Floyd and E. Kohler, "Internet Research Needs Better 1184 Models", Proceedings of 1st Workshop on Hot Topics in Networks 1185 (Hotnets-I), Princeton, NJ, USA. October 2002. URL 1186 "http://www.icir.org/models/bettermodels.html". 1188 [IM1993] J. Ioannidis and G. Maguire Jr., "The Design and 1189 Implementation of a Mobile Internetworking Architecture", Proceedings 1190 of the Winter USENIX Technical Conference, pages 489-500, Berkeley, 1191 CA, USA, January 1993. 1193 [IST02] Research Networking in Europe - Striving for Global 1194 Leadership, Information Society Technologies, 2002. URL 1195 "http://www.cordis.lu/ist/rn/rn-brochure.htm". 1197 [Jacobson88] Van Jacobson, "Congestion Avoidance and Control", 1198 Proceedings of ACM SIGCOMM 1988 Symposium, ACM SIGCOMM, Stanford, CA, 1199 August 1988. URL 1200 "http://citeseer.nj.nec.com/jacobson88congestion.html". 1202 [Jackson02] William Jackson, "U.S. should fund R&D for secure 1203 Internet protocols, Clarke says", Government Computer News, 31 1204 October 2002. URL 1205 "http://www.gcn.com/vol1_no1/security/20382-1.html". 1207 [Kruse00] Hans Kruse, "The Pitfalls of Distributed Protocol 1208 Development: Unintentional Interactions between Network Operations 1209 and Applications Protocols", Proceedings of the 8th International 1210 Conference on Telecommunication Systems Design, Nashville, TN, USA, 1211 March 2000. URL 1212 "http://www.csm.ohiou.edu/kruse/publications/TSYS2000.pdf". 1214 [KLMS2000] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure Border 1215 Gateway Protocol (S-BGP)", Proceedings of ISOC Network and 1216 Distributed Systems Security Symposium, Internet Society, Reston, VA, 1217 February 2000. 1219 [LD2002] E. Lear and R. Droms, "What's in a Name: Thoughts from the 1220 NSRG", expired Internet-Draft, December 2002. 1222 [MBFIPS01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John 1223 Ioannidis, Vern Paxson, and Scott Shenker, "Controlling High 1224 Bandwidth Aggregates in the Network", ACM Computer Communications 1225 Review, Vol. 32, No. 3, July 2002. URL 1226 "http://www.icir.org/pushback/". 1228 [MBKQ96] M. McKusick, K. Bostic, M. Karels, and J. Quarterman, 1229 "Design and Implementation of the 4.4 BSD Operating System", Addison- 1230 Wesley, Reading, MA, 1996. 1232 [MGVK02] Z. Mao, R. Govindan, G. Varghese, & R. Katz, "Route Flap 1233 Dampening Exacerbates Internet Routing Convergence", Proceedings of 1234 ACM SIGCOMM 2002, ACM, Pittsburgh, PA, USA, August 2002. 1236 [NV02] NetVision 2012 Committee,"DARPA's Ten-Year Strategic Plan for 1237 Networking Research", (U.S.) Defense Advanced Research Projects 1238 Agency, October 2002. Citation for acknowledgement purposes only. 1240 [NSF02] NSF Workshop on Network Research Testbeds, National Science 1241 Foundation, Directorate for Computer and Information Science & 1242 Engineering, Advanced Networking Infrastructure & Research Division, 1243 Arlington, VA, USA, October 2002. URL "http://www- 1244 net.cs.umass.edu/testbed_workshop/". 1246 [NSF03] NSF ANIR Principal Investigator meeting, National Science 1247 Foundation, Arlington, VA, USA. January 9-10, 2003, URL 1248 "http://www.ncne.org/training/nsf-pi/2003/nsfpimain.html". 1250 [NSF03a] D. E. Atkins, et al., "Revolutionizing Science and 1251 Engineering Through Cyberinfrastructure", Report of NSF Advisory 1252 Panel on Cyberinfrastructure, January 2003. URL 1253 "http://www.cise.nsf.gov/evnt/reports/atkins_annc_020303.htm". 1255 [NSF03b] Report of the National Science Foundation Workshop on 1256 Fundamental Research in Networking. April 24-25, 2003. URL 1257 "http://www.cs.virginia.edu/~jorg/workshop1/NSF- 1258 NetWorkshop-2003.pdf". 1260 [Floyd] S. Floyd, "Papers about Research Questions for the Internet", 1261 web page, ICSI Center for Internet Research (ICIR), Berkeley, CA, 1262 2003 URL "http://www.icir.org/floyd/research_questions.html". 1264 [RFC-1510] J. Kohl and C. Neuman, "The Kerberos Network 1265 Authentication Service (V5)", RFC 1510, September 1993. 1267 [RFC-2082] F. Baker and R. Atkinson, "RIPv2 MD5 Authentication", 1268 RFC-2082, January 1997. 1270 [RFC-2154] S. Murphy, M. Badger, and B. Wellington, "OSPF with 1271 Digital Signatures", RFC-2154, June 1997. 1273 [RFC-2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 1274 Signature Option", RFC-2385, August 1998. 1276 [RFC-2407] D. Piper, "The Internet IP Security Domain of 1277 Interpretation for ISAKMP", RFC-2407, November 1998. 1279 [RFC-2501] S. Corson and J. Macker, "Mobile Ad Hoc Networking 1280 (MANET): Routing Protocol Performance Issues and Evaluation 1281 Considerations", RFC-2501, January 1999. 1283 [RFC-2990] G. Huston, "Next Steps for the IP QoS Architecture", 1284 RFC-1990, November 2000. 1286 [RFC-3221] G. Huston, "Commentary on Inter-Domain Routing in the 1287 Internet", RFC-3221, December 2001. 1289 [RFC-3234] B. Carpenter and S. Brim, "Middleboxes: Taxonomy and 1290 Issues", RFC 3234, February 2002. 1292 [RFC-3424] L. Daigle, Editor, "IAB Considerations for Unilateral 1293 Self-Address Fixing (UNSAF) Across Network Address Translation", 1294 RFC-3424, Internet Architecture Board, November 2002. 1296 [RFC-3467] J. Klensin, "Role of the Domain Name System (DNS)", RFC 1297 3467, February 2003. 1299 [RFC-3535] J. Schoenwalder, Editor, "Overview of the 2002 IAB Network 1300 Management Workshop", RFC-3535, May 2003. 1302 [RFC-3387] M. Eder, H. Chaskar, and S. Nag, "Considerations from the 1303 Service Management Research Group (SMRG) on Quality of Service (QoS) 1304 in the IP Network", RFC 3387, September 2002. 1306 [RIPE] RIPE (Reseaux IP Europeens), Amsterdam, NL. URL 1307 "http://www.ripe.net/ripe/". 1309 [Savage00] Savage, S., Wetherall, D., Karlink, A. R., and Anderson, 1310 T., "Practical Network Support for IP Traceback", Proceedings of 2000 1311 ACM SIGCOMM Conference, ACM SIGCOMM, Stockholm, SE, pp. 295-306. 1312 August 2000. 1314 [Schiller03] J. I. Schiller, "Interception Technology: The Good, The 1315 Bad, and The Ugly!", Presentation at 28th NANOG Meeting, North 1316 American Network Operators Group (NANOG), Ann Arbor, MI, USA, June 1317 2003. URL "http://www.nanog.org/mtg-0306/schiller.html". 1319 [SM03] P. Sharma and R. Malpani, "IP Multicast Operational Network 1320 Management: Design, Challenges, and Experiences", IEEE Network, Vol. 1321 17, No. 2, March 2003. 1323 [SMA03] N. Spring, R. Mahajan, & T. Anderson, "Quantifying the Causes 1324 of Path Inflation", Proceedings of ACM SIGCOMM 2003, ACM, Karlsruhe, 1325 Germany, August 2003. 1327 [WD02] Walter Willinger and John Doyle, "Robustness and the Internet: 1328 Design and Evolution", Unpublished/Preprint, 1 March 2002, URL 1329 "http://netlab.caltech.edu/internet/". 1331 [WIDE] WIDE Project, Japan. URL "http://www.wide.ad.jp/". 1333 9. AUTHORS' ADDRESSES 1335 Internet Architecture Board 1336 EMail: iab@iab.org 1338 Internet Architecture Board Members 1339 at the time this document was published were: 1341 Bernard Aboba 1342 Harald Alvestrand (IETF chair) 1343 Rob Austein 1344 Leslie Daigle (IAB chair) 1345 Patrik Faltstrom 1346 Sally Floyd 1347 Mark Handley 1348 Bob Hinden 1349 Geoff Huston (IAB Executive Director) 1350 Jun-ichiro Itojun Hagino 1351 Eric Rescorla 1352 Pete Resnick 1353 Jonathan Rosenberg 1355 We note that Ran Atkinson, one of the editors of the document, was an 1356 IAB member at the time that this document was first created, in 1357 November 2002, and that Vern Paxson, the IRTF chair, is an ex-officio 1358 member of the IAB. 1360 Intellectual Property Notice 1362 The IETF has been notified of intellectual property rights claimed in 1363 regard to some or all of the specification contained in this 1364 document, particularly regarding support for mobility. For more 1365 information consult the online list of claimed rights. 1367 By submitting this Internet-Draft, we certify that any applicable 1368 patent or other IPR claims of which we are aware have been disclosed, 1369 and any of which we become aware will be disclosed, in accordance 1370 with RFC 3668. 1372 The IETF takes no position regarding the validity or scope of any 1373 intellectual property or other rights that might be claimed to 1374 pertain to the implementation or use of the technology described in 1375 this document or the extent to which any license under such rights 1376 might or might not be available; neither does it represent that it 1377 has made any effort to identify any such rights. Information on the 1378 IETF's procedures with respect to rights in standards-track and 1379 standards-related documentation can be found in BCP-11. Copies of 1380 claims of rights made available for publication and any assurances of 1381 licenses to be made available, or the result of an attempt made to 1382 obtain a general license or permission for the use of such 1383 proprietary rights by implementors or users of this specification can 1384 be obtained from the IETF Secretariat. 1386 Full Copyright Statement 1388 Copyright (C) The Internet Society 2004. This document is subject to 1389 the rights, licenses and restrictions contained in BCP 78, and except 1390 as set forth therein, the authors retain all their rights. 1392 This document and translations of it may be copied and furnished to 1393 others, and derivative works that comment on or otherwise explain it 1394 or assist in its implementation may be prepared, copied, published 1395 and distributed, in whole or in part, without restriction of any 1396 kind, provided that the above copyright notice and this paragraph are 1397 included on all such copies and derivative works. However, this 1398 document itself may not be modified in any way, such as by removing 1399 the copyright notice or references to the Internet Society or other 1400 Internet organizations, except as needed for the purpose of 1401 developing Internet standards in which case the procedures for 1402 copyrights defined in the Internet Standards process must be 1403 followed, or as required to translate it into languages other than 1404 English. 1406 The limited permissions granted above are perpetual and will not be 1407 revoked by the Internet Society or its successors or assigns. 1409 This document and the information contained herein are provided on an 1410 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1411 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1412 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1413 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1414 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1415 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.