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