idnits 2.17.1 draft-iab-research-funding-01.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 26 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 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 June 2003) is 7606 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 447, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Missing Reference: 'RFC2082' is mentioned on line 447, but not defined ** Obsolete undefined reference: RFC 2082 (Obsoleted by RFC 4822) == Missing Reference: 'RFC2154' is mentioned on line 453, but not defined == Missing Reference: 'RFC2501' is mentioned on line 497, but not defined == Missing Reference: 'D00' is mentioned on line 716, but not defined == Missing Reference: 'RFC-1633' is mentioned on line 740, but not defined == Missing Reference: 'RFC-2474' is mentioned on line 740, but not defined == Missing Reference: 'RFC-3260' is mentioned on line 740, but not defined == Missing Reference: 'RFC-2205' is mentioned on line 740, but not defined == Missing Reference: 'RFC-2210' is mentioned on line 740, but not defined == Unused Reference: 'Diot00' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'Handley02' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'ResearchQuestions' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: 'RFC-2082' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: 'RFC-2154' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'RFC-2385' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'RFC-2407' is defined on line 1124, but no explicit reference was found in the text == Unused Reference: 'RFC-2501' is defined on line 1127, 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: 5 errors (**), 0 flaws (~~), 21 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-01.txt Internet Architecture Board 5 29 June 2003 7 IAB Concerns & Recommendations Regarding Internet Research & Evolution 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document discusses IAB concerns that ongoing research is needed 33 to further the evolution of the Internet infrastructure, and that 34 consistent, sufficient non-commercial funding is needed to enable 35 such research. 37 Feedback can be sent to the IAB mailing list at iab@ietf.org, or to 38 the editors at rja@extremenetworks.com and floyd@icir.org. Feedback 39 can also be sent to the mailing list set up for feedback at research- 40 funding@ietf.org. Requests to join can be sent to research-funding- 41 request@ietf.org, with "subscribe research-funding" in the body of 42 the request. 44 Table of Contents 45 1. Introduction 46 1.1. Document Organization 47 1.2. IAB Concerns 48 1.3. Contributions to this Document 49 2. History of Internet Research & Research Funding 50 2.1. Prior to 1980 51 2.2. 1980s and early 1990s 52 2.3. Mid-1990s to 2003 53 2.4. Current Status 54 3. Open Internet Research Topics 55 3.1. Scope & Limitations 56 3.2. Naming 57 3.2.1. Domain Name System (DNS) 58 3.2.2. New Namespaces 59 3.3. Routing 60 3.3.1. Inter-domain Routing 61 3.3.2. Routing Integrity 62 3.3.3. Routing Algorithms 63 3.3.4. Mobile & Ad-Hoc Routing 64 3.4. Security 65 3.4.1. Freely Distributable Prototypes 66 3.4.2. Formal Methods 67 3.4.3. Key Management 68 3.4.4 Cryptography 69 3.4.5 Security for Distributed Computing 70 3.4.6. Deployment Considerations in Security 71 3.4.7. Denial of Service Protection 72 3.5. Network Management 73 3.5.1. Configuration Management 74 3.5.1. Enhanced Monitoring Capabilities 75 3.5.2. Managing Networks, Not Devices 76 3.5.3. Improving the Scalability of Network Management 77 3.6. Quality of Service 78 3.6.1. Inter-Domain QoS Architecture 79 3.6.2. New Queuing Disciplines 80 3.7. Congestion control. 81 3.8. Studying the Evolution of the Internet Infrastructure 82 3.9. Middleboxes 83 3.10. Internet Measurement 84 3.11. Meeting the Needs of the Future 85 3.12. Additional topics 86 4. Conclusions 87 5. Acknowledgements 88 6. Security Considerations 89 7. IANA Considerations 90 9. AUTHORS' ADDRESSES 92 1. Introduction 94 This document discusses the history of funding for Internet research, 95 expresses concern about the current state of such funding, and 96 outlines several specific areas that the IAB believes merit 97 additional research. Current funding levels for Internet research 98 are not generally adequate, and several important research areas are 99 significantly underfunded. This situation needs to be rectified for 100 the Internet to continue its evolution and development. 102 1.1. Document Organization 104 The first part of the document is a high-level discussion of the 105 history of funding for Internet research to provide some historical 106 context to this document. The early funding of Internet research was 107 largely from the U.S. government, followed by a period in the second 108 half of the 1990s of commercial funding and of funding from several 109 governments. [Add a citation.] However, the commercial funding for 110 Internet research has been reduced due to the recent economic 111 downturn. 113 The second part of the document provides an incomplete set of open 114 Internet research topics. These are only examples, intended to 115 illustrate the breadth of open research topics. This second section 116 supports the general thesis that ongoing research is needed to 117 further the evolution of the Internet infrastructure. This includes 118 research on the medium-time-scale evolution of the Internet 119 infrastructure as well as research on longer-time-scale grand 120 challenges. This also includes many research issues that are already 121 being actively investigated in the Internet research community. 123 Areas that are discussed in this section include the following: 124 naming, routing, security, network management, and transport. Issues 125 that require more research also include more general architectural 126 issues such as layering and communication between layers. In 127 addition, general topics discussed in this section include modeling, 128 measurement, simulation, test-beds, etc. We are focusing on topics 129 that are related to the IETF and IRTF (Internet Research Task Force) 130 agendas. (E.g., issues related to the global grid are not discussed 131 in this document because these issues are addressed through the 132 Global Grid Forum and other grid-specific organizations, not in the 133 IETF.) 135 Where at all possible, the examples in the paper point to separate 136 documents on these issues, and only give a high-level summary of the 137 issues raised in those documents. 139 1.2. IAB Concerns 141 Recently, in the aftermath of September 11 2001, there seems to be a 142 renewed interest by governments in funding research for Internet- 143 related security issues. From [J02]: "It is generally agreed that 144 the security and reliability of the basic protocols underlying the 145 Internet have not received enough attention because no one has a 146 proprietary interest in them". 148 That quote brings out a key issue in funding for Internet research, 149 which is that because no single organization (e.g., no single 150 government, software company, equipment vendor, or network operator) 151 has a sense of ownership of the global Internet infrastructure, 152 research on the general issues of the Internet infrastructure are 153 often not adequately funded. In our current challenging economic 154 climate, it is not surprising that commercial funding sources are 155 more likely to fund that research that leads to a direct competitive 156 advantage. 158 The principal thesis of this document is that if commercial funding 159 is the main source of funding for future Internet research, the 160 future of the Internet infrastructure could be in trouble. In 161 addition to issues about which projects were funded, the funding 162 source can also affect the content of the research, for example, 163 towards or against the development of open standards, or taking 164 varying degrees of care about the effect of the developed protocols 165 on the other traffic on the Internet. 167 At the same time, many significant research contributions in 168 networking have come from commercial funding. However, for most of 169 the topics in this document, relying solely on commercially-funded 170 research would not be adequate. Much of today's commercial funding 171 is focused on technology transition, taking results from non- 172 commercial research and putting them into shipping commercial 173 products. We have not tried to delve into each of the research 174 issues below to discuss, for each issue, what are the potentials and 175 limitations of commercial funding for research in that area. 177 On a more practical note, if there was no commercial funding for 178 Internet research, then few research projects would be taken to 179 completion with implementations, deployment, and follow-up 180 evaluation. 182 While it is theoretically possible for there to be too much funding 183 for Internet research, that is far from the current problem. There 184 is also much that could be done within the network research community 185 to make Internet research more focused and productive, but that would 186 belong in a separate document. 188 1.3. Contributions to this Document 190 A number of people have directly contributed text for this document, 191 even though, following current conventions, the official RFC author 192 list includes only the key editors of the document. The 193 Acknowledgements section at the end of the document thanks other 194 people who contributed to this document in some form. 196 2. History of Internet Research & Research Funding 198 2.1. Prior to 1980 200 Most of the early research into packet-switched networks was 201 sponsored by the U.S. Defense Advanced Research Projects Agency 202 (DARPA) [CSTB99]. This includes the initial design, implementation, 203 and deployment of the ARPAnet connecting several universities and 204 other DARPA contractors. The ARPAnet originally came online in the 205 late 1960s. It grew in size during the 1970s, still chiefly with 206 DARPA funding, and demonstrated the utility of packet-switched 207 networking. 209 2.2. 1980s and early 1990s 211 The ARPAnet converted to the Internet Protocol on January 1, 1983, 212 approximately 20 years before this document was written. Throughout 213 the 1980s, the U.S. Government continued strong research and 214 development funding for Internet technology. DARPA continued to be 215 the key funding source, but was supplemented by other DoD (US 216 Department of Defense) funding (e.g. via DCA's Defense Data Network 217 (DDN) program) and other U.S. Government funding (e.g. US Department 218 of Energy (DoE) funding for research networks at DoE national 219 laboratories, (US) National Science Foundation (NSF) funding for 220 academic institutions). This funding included basic research, 221 applied research (including freely distributable prototypes), the 222 purchase of IP-capable products, and operating support for the IP- 223 based government networks such as ARPAnet, ESnet, MILnet, and NSFnet. 225 In the late 1980s, the U.S. DoD desired to leave the business of 226 providing operational network services to academic institutions, so 227 funding for many academic activities moved over to the NSF. NSF 228 funding included research projects into networking, as well as 229 creating the NSFnet backbone and sponsoring the creation of several 230 NSF regional networks (e.g. SURAnet) and interconnections with 231 several international research networks. 233 Most research funding outside the U.S. during the 1980s and early 234 1990s was focused on the ISO OSI networking project or on then-new 235 forms of network media (e.g. wireless, broadband access). The 236 European Union was a significant source of research funding for the 237 networking community in Europe during this period. Some of the best 238 early work in gigabit networking was undertaken in the UK and Sweden. 240 2.3. Mid-1990s to 2003 242 Starting in the middle 1990s, U.S. Government funding for Internet 243 research and development was significantly reduced. The premise for 244 this was that the growing Internet industry would pay for whatever 245 research and development that was needed. Some funding for Internet 246 research and development has continued in this period from European 247 and Asian organizations (e.g., the WIDE Project in Japan [WIDE]). 248 Reseaux IP Europeens [RIPE] is an example of market-funded networking 249 research in Europe during this period. 251 Experience during this period has been that commercial firms have 252 often focused on donating equipment to academic institutions and 253 promoting somewhat vocationally-focused educational projects. Many 254 of the commercially-funded research and development projects appear 255 to have been selected because they appeared likely to give the 256 funding source a specific short-term economic advantage over its 257 competitors. Higher risk, more innovative research proposals 258 generally have not been funded by industry. A common view in Silicon 259 Valley has been that established commercial firms are not very good 260 at transitioning cutting edge research into products, but were 261 instead good at buying small startup firms who had successfully 262 transitioned such cutting edge research into products. 263 Unfortunately, small startup companies are generally unable 264 financially to fund any research themselves. 266 2.4. Current Status 268 The result of reduced U.S. Government funding and profit-focused, 269 low-risk, short-term industry funding has been a decline in higher- 270 risk but more innovative research activities. Industry has also been 271 less interested in research to evolve the overall Internet 272 architecture, because such work does not translate into a competitive 273 advantage for the firm funding such work. 275 The IAB believes that it would be helpful for governments and other 276 non-commercial sponsors to increase their funding of both basic 277 research and applied research relating to the Internet. Furthermore, 278 those increased funding levels should be sustained and protected 279 against inflation going forward. 281 3. Open Internet Research Topics 283 This section primarily discusses some specific topics that the IAB 284 believes merit additional research. Research, of course, includes 285 not just devising a theory, algorithm, or mechanism to accomplish a 286 goal, but also evaluating the general efficacy of the approach and 287 then the benefits vs. the costs of deploying that algorithm or 288 mechanism. Important cautionary notes about this discussion are 289 given in the next sub-section. This particular set of topics is not 290 intended to be comprehensive, but instead is intended to demonstrate 291 the breadth of open Internet research questions. 293 3.1. Scope & Limitations 295 This document is NOT intended as a guide for funding organizations as 296 to exactly which projects or proposals should or should not be 297 funded. 299 In particular, this document is NOT intended to be a comprehensive 300 list of *all* of the research questions that are important to further 301 the evolution of the Internet; that would be a daunting task, and 302 would presuppose a wider and more intensive effort than we have 303 undertaken in this document. 305 Similarly, this document is not intended to list the research 306 questions that are judged to be only of peripheral importance, or to 307 survey the current (global; governmental, commercial, and academic) 308 avenues for funding for Internet research, or to make specific 309 recommendations about which areas need additional funding. The 310 purpose of the document is to persuade the reader that ongoing 311 research is needed towards the continued evolution of the Internet 312 infrastructure; the purpose is not to make binding pronouncements 313 about which specific areas are and are not worthy of future funding. 315 For some research clearly relevant to the future evolution of the 316 Internet, there are grand controversies between competing proposals 317 or competing schools of thought; it is not the purpose of this 318 document to take positions in these controversies, or to take 319 positions on the nature of the solutions for areas needing further 320 research. 322 That all carefully noted, the remainder of this section discusses a 323 broad set of research areas, noting a subset of particular topics of 324 interest in each of those research areas. Again, this list is NOT 325 comprehensive, but rather is intended to suggest that a broad range 326 of ongoing research is needed, and to propose some candidate topics. 328 3.2. Naming 330 The Internet currently has several different namespaces, including IP 331 addresses, sockets (specified by the IP address, upper-layer 332 protocol, and upper-layer port number), and the Fully-Qualified 333 Domain Name (FQDN). Many of the Internet's namespaces are supported 334 by the widely deployed Domain Name System [RFC refs] or by various 335 Internet applications [RFC-2407, Section 4.6.2.1] 337 3.2.1. Domain Name System (DNS) 339 The DNS system, while it works well given its current constraints, 340 has several stress points. 342 The current DNS system relies on UDP for transport, rather than SCTP 343 or TCP. Given the very large number of clients using a typical DNS 344 server, it is desirable to minimise the state on the DNS server side 345 of the connection. UDP does this well, so is a reasonable choice, 346 though this has other implications, for example a reliance on UDP 347 fragmentation. With IPv6, intermediate fragmentation is not allowed 348 and Path MTU Discovery is mandated. However, the amount of state 349 required to deploy Path MTU Discovery for IPv6 on a DNS server might 350 be a significant practical problem. 352 One implication of this is that research into alternative transport 353 protocols, designed more for DNS-like applications where there are 354 very many clients using each server, might be useful. Of particular 355 interest would be transport protocols with little burden for the DNS 356 server, even if that increased the burden somewhat for the DNS 357 client. 359 Additional study of DNS caching, both currently available caching 360 techniques and also of potential new caching techniques, might be 361 helpful in finding ways to reduce the offered load for a typical DNS 362 server. In particular, examination of DNS caching through typical 363 commercial firewalls might be interesting if it lead to alternative 364 firewall implementations that were less of an obstacle to DNS 365 caching. 367 The community lacks a widely agreed upon set of metrics for measuring 368 DNS server performance. It would be helpful if people would 369 seriously consider what characteristics of the DNS system should be 370 measured. 372 Some in the community would advocate replacing the current DNS system 373 with something better. Past attempts to devise a better approach 374 have not yielded results that persuaded the community to change. 375 Proposed work in this are could be very useful, but might require 376 careful scrutiny to avoid falling into historic design pitfalls. 378 With regards to DNS security, major technical concerns include 379 finding practical methods for signing very large DNS zones (e.g. 380 .COM), practical methods for incremental deployment of DNS security, 381 and tools to make it easier to manage secure DNS infrastructure. 383 3.2.2. New Namespaces 385 Additionally, the Namespace Research Group (NSRG) of the Internet 386 Research Task Force (IRTF) studied adding one or more additional 387 namespaces to the Internet Architecture [LD2002]. Many participants 388 in the IRTF NSRG membership believe that there would be significant 389 architectural benefit to adding one or more additional namespaces to 390 the Internet Architecture. Because smooth consensus on that question 391 or on the properties of a new namespace was not obtained, the IRTF 392 NSRG did not make a formal recommendation to the IETF community 393 regarding namespaces. The IAB believes that this is an open research 394 question worth examining further. 396 Finally, we believe that future research into the evolution of 397 Internet-based distributed computing might well benefit from studying 398 adding additional namespaces as part of a new approach to distributed 399 computing. 401 3.3. Routing 403 The currently deployed unicast routing system works reasonably well 404 for most users. However, the current unicast routing architecture is 405 suboptimal in several areas, including the following: end-to-end 406 convergence times in global-scale catenets (a system of networks 407 interconnected via gateways); the ability of the existing inter- 408 domain path-vector algorithm to scale well beyond 200K prefixes; the 409 ability of both intra-domain and inter-domain routing to use multiple 410 metrics and multiple kinds of metrics concurrently; and the ability 411 of IPv4 and IPv6 to support widespread site multi-homing without 412 undue adverse impact on the inter-domain routing system. Integrating 413 policy into routing is also a general concern, both for intra-domain 414 and inter-domain routing. In many cases, routing policy is directly 415 tied to economic issues for the network operators, so applied 416 research into routing ideally would consider economic considerations 417 as well as technical considerations.. 419 3.3.1. Inter-domain Routing 421 The current operational inter-domain routing system has between 422 150,000 and 200,000 routing prefixes in the default-free zone (DFZ) 424 [RFC-3221]. ASIC technology obviates concerns about the ability to 425 forward packets at very high speeds. ASIC technology also obviates 426 concerns about the time required to perform longest-prefix-match 427 computations. However, some senior members of the Internet routing 428 community have concerns that the end-to-end convergence properties of 429 the global Internet might hit algorithmic limitations (i.e. not 430 hardware limitations) when the DFZ is somewhere between 200,000 and 431 300,000 prefixes. Research into whether this concern is well-founded 432 in scientific terms seems very timely. 434 The current approach to site multi-homing has the highly undesirable 435 side-effect of significantly increasing the growth rate of prefix 436 entries in the DFZ (by impairing the deployment of prefix 437 aggregation). Research is needed into new routing architectures that 438 can support large-scale site multi-homing without the undesirable 439 impacts on inter-domain routing of the current multi-homing 440 technique. 442 3.3.2. Routing Integrity 444 Recently there has been increased awareness of the longstanding issue 445 of deploying strong authentication into the Internet inter-domain 446 routing system. Currently deployed mechanisms (e.g. BGP TCP MD5 447 [RFC2385], OSPF MD5, RIP MD5 [RFC2082]) provide cryptographic 448 authentication of routing protocol messages, but no authentication of 449 the actual routing data. Current proposals (e.g. S-BGP [KLMS2000]) 450 for improving this in inter-domain routing are unduly challenging to 451 deploy across the Internet because of their reliance on a single 452 trust hierarchy (e.g., a single PKI). Similar proposals (e.g. OSPF 453 with Digital Signatures, [RFC2154]) for intra-domain routing are 454 argued to be computationally infeasible to deploy in a large network. 456 Alternative approaches to authentication of data in the routing 457 system need to be developed. In particular, the ability to perform 458 partial authentication of routing data would facilitate incremental 459 deployment of routing authentication mechanisms. Also, the ability 460 to use non-hierarchical trust models (e.g. the web of trust used in 461 the PGP application) might facilitate incremental deployment and 462 might resolve existing concerns about centralized administration of 463 the routing system, hence merits additional study and consideration. 465 3.3.3. Routing Algorithms 467 The current Internet routing system relies primarily on only three 468 algorithms. Link-state routing uses the Dijkstra algorithm 469 [Dijkstra59]. The Distance-Vector and Path-Vector algorithms use the 470 Bellman-Ford algorithm [Bellman1957, FF1962]. Additional ongoing 471 basic research into graph theory as applied to routing is worthwhile 472 and might yield algorithms that would enable a new routing 473 architecture or otherwise provide improvements to the routing system. 475 Currently deployed multicast routing relies on the Deering RPF 476 algorithm [Deering1988]. Ongoing research into alternative multicast 477 routing algorithms and protocols might help alleviate current 478 concerns with the scalability of multicast routing. 480 The deployed Internet routing system assumes that the shortest path 481 is always the best path. This is provably false, however it is a 482 reasonable compromise given the routing protocols currently 483 available. The Internet lacks deployable approaches for policy-based 484 routing or routing with alternative metrics (i.e. some metric other 485 than the number of hops to the destination). Examples of alternative 486 policies include: the path with lowest monetary cost; the path with 487 the lowest probability of packet loss; the path with minimized 488 jitter; and the path with minimized latency. Policy metrics also 489 need to take business relationships into account. Historic work on 490 QoS-based routing has tended to be unsuccessful in part because it 491 did not adequately consider economic/commercial considerations of the 492 routing system and in part because of inadequate consideration of 493 security implications. 495 3.3.4. Mobile & Ad-Hoc Routing 497 Mobile routing [IM1993] and mobile ad-hoc routing [RFC2501] are 498 relatively recent arrivals in the Internet, and are not yet widely 499 deployed. The current approaches are not the last word in either of 500 those arenas. We believe that additional research into routing 501 support for mobile hosts and mobile networks is needed. Additional 502 research for ad-hoc mobile hosts and mobile networks is also 503 worthwhile. Ideally, mobile routing and mobile ad-hoc routing 504 capabilities should be native inherent capabilities of the Internet 505 routing architecture. This probably will require a significant 506 evolution from the existing Internet routing architecture. (NB: The 507 term "mobility" as used here is not limited to mobile telephones, but 508 instead is very broadly defined, including laptops that people carry, 509 cars/trains/aircraft, and so forth.) 511 Included in this topic are a wide variety of issues. The more 512 distributed and dynamic nature of partially or completely self- 513 organizing routing systems (including the associated end nodes) 514 creates unique security challenges (especially relating to AAA and 515 key management). Scalability of wireless networks can be difficult 516 to measure or to achieve. Enforced hierarchy is one approach, but 517 can be very limiting. Alternative, less constraining approaches to 518 wireless scalability are desired. Because wireless link-layer 519 protocols usually have some knowledge of current link characteristics 520 such as link quality, sublayer congestion conditions, or transient 521 channel behavior, it is desirable to find ways to let network-layer 522 routing use such data. This raises architectural questions of what 523 the proper layering should be, which functions should be in which 524 layer, and also practical considerations of how and when such 525 information sharing should occur in real implementations. 527 3.4. Security 529 The Internet has a reputation for not having sufficient security. In 530 fact, the Internet has a number of security mechanisms standardized, 531 some of which are widely deployed. However, there are a number of 532 open research questions relating to Internet security. In 533 particular, security mechanisms need to be incrementally deployable 534 and easy to use. "[Security] technology must be easy to use, or it 535 will not be configured correctly. If mis-configured, security will 536 be lost, but things will `work'" [S03]. 538 3.4.1. Freely Distributable Prototypes 540 U.S.'s DARPA has historically funded development of freely 541 distributable implementations of various security technologies, such 542 as IP security, in a variety of operating systems. Experience has 543 shown that a good way to speed deployment of a new technology is to 544 provide an unencumbered, freely-distributable prototype. We believe 545 that applied research projects in Internet security will have an 546 increased probability of success if the research project teams make 547 their resulting software implementations freely available for both 548 commercial and non-commercial uses. Examples of successes here 549 include the DARPA funding of TCP/IPv4 integration into the 4.x BSD 550 operating system [MBKQ96] and DARPA/USN funding of ESP/AH design and 551 integration into 4.4 BSD [Atk96]. 553 3.4.2. Formal Methods 555 There is an ongoing need for funding of basic research relating to 556 Internet security, including funding of formal methods research that 557 relates to security algorithms, protocols, and systems. For example, 558 while there has been significant work into hierarchical security 559 models (e.g. Bell-Lapadula) [BL1976], there has not been adequate 560 formal study of alternative security models (e.g. PGP's Web-of-Trust 561 model). Use of a hierarchical trust model creates significant 562 limitations in how one might approach securing components of the 563 Internet, for example the DNS, or the inter-domain routing system. 564 So research to develop new trust models or on the applicability of 565 existing non-hierarchical trust models to existing problems would be 566 worthwhile. 568 While there has been some work on the application of formal methods 569 to cryptographic algorithms and cryptographic protocols, existing 570 techniques for formal evaluation of algorithms and protocols lack 571 sufficient automation. This lack of automation means that many 572 protocols aren't formally evaluated in a timely manner. This is 573 problematic for the Internet because formal evaluation has often 574 uncovered serious anomalies in cryptographic protocols. The creation 575 of automated tools for applying formal methods to cryptographic 576 algorithms and/or protocols would be very helpful. 578 3.4.3. Key Management 580 A recurring challenge to the Internet community is how to design, 581 implement, and deploy key management appropriate to the myriad 582 security contexts existing in the global Internet. Most current work 583 in unicast key management has focused on hierarchical trust models, 584 because much of the existing work has been driven by corporate or 585 military "top-down" operating models. 587 The absence of key management methods applicable to non-hierarchical 588 trust models (see above) is a significant constraint on the 589 approaches that might be taken to secure components of the Internet. 590 Research focused on removing those constraints by developing 591 practical key management methods applicable to non-hierarchical trust 592 models would be very helpful. 594 Topics worthy of additional research include key management 595 techniques, such as non-hierarchical key management architectures 596 (e.g. to support non-hierarchical trust models; see above), that are 597 useful by ad-hoc groups in mobile networks and/or distributed 598 computing. 600 Although some progress has been made in recent years, scalable 601 multicast key management is far from being a solved problem. 602 Existing approaches to scalable multicast key management add 603 significant constraints on the problem scope in order to come up with 604 a deployable technical solution. Having a more general approach to 605 scalable multicast key management (i.e. one having broader 606 applicability and fewer constraints) would enhance the Internet's 607 capabilities. 609 In many cases, attribute negotiation is an important capability of a 610 key management protocol. Experience with the Internet Key Exchange 611 (IKE) to date has been that it is unduly complex. Much of IKE's 612 complexity derives from its very general attribute negotiation 613 capabilities. A new key management approach that supported 614 significant attribute negotiation without creating challenging levels 615 of deployment and operations complexity would be helpful. 617 3.4.4 Cryptography 619 There is an ongoing need to continue the open-world research funding 620 into both cryptography and cryptanalysis. Most governments focus 621 their cryptographic research in the military-sector. While this is 622 understandable, those efforts often have limited (or no) publications 623 in the open literature. Since the Internet engineering community 624 must work from the open literature, it is important that open-world 625 research continues in the future. 627 3.4.5 Security for Distributed Computing 629 MIT's Project Athena was an important and broadly successful research 630 project into distributed computing. Project Athena developed the 631 Kerberos [RFC-1510] security system, which has significant deployment 632 today in campus environments. However, inter-realm Kerberos is 633 neither as widely deployed nor perceived as widely successful as 634 single-realm Kerberos. The need for scalable inter-domain user 635 authentication is increasingly acute as ad-hoc computing and mobile 636 computing become more widely deployed. Thus, work on scalable 637 mechanisms for mobile, ad-hoc, and non-hierarchical inter-domain 638 authentication would be very helpful. 640 3.4.6. Deployment Considerations in Security 642 Lots of work has been done on theoretically perfect security that is 643 impossible to deploy. Unfortunately, Kent's S-BGP proposal is an 644 example of a good research product that has significant unresolved 645 deployment challenges. It is far from obvious how one could widely 646 deploy S-BGP without previously deploying a large-scale inter-domain 647 public-key infrastructure and also centralising route advertisement 648 policy enforcement in the Routing Information Registries or some 649 similiar body. Historically, public-key infrastructures have been 650 either very difficult or impossible to deploy at large scale. Some 651 have recently suggested that the PGP web-of-trust authentication 652 model should be applied to inter-domain advertisement of routing 653 prefixes [Schiller03]. Security mechanisms that need additional 654 infrastructure have not been deployed well. We desperately need 655 security that is general, easy to install, and easy to manage. 657 3.4.7. Denial of Service Protection 659 Historically, the Internet community has mostly ignored pure Denial 660 of Service (DoS) attacks. This was appropriate at one time since 661 such attacks were rare and are hard to defend against. However, one 662 of the recent trends in malware (viruses, worms, etc.) has been the 663 incorporation of features that turn the infected host into a 664 "zombie". Such zombies can be remotely controlled to mount a 665 distributed denial of service attack on some victim machine. This 666 makes the design of anti-DoS measures of high importance to the 667 Internet. Some work has been done on this front [Sav00], [MBFIPS01], 668 but more is needed. 670 3.5. Network Management 672 The Internet had early success in network device monitoring with the 673 Simple Network Management Protocol (SNMP) and its associated 674 Management Information Base (MIB). There has been comparatively less 675 success in managing networks, in contrast to the hierarchical 676 monitoring of individual devices. 678 Unfortunately, network management research has historically been very 679 underfunded, because it is difficult to get funding bodies to 680 recognize this as legitimate networking research. 682 3.5.1. Configuration Management 684 Operators at the IAB Network Management Workshop [RFC-3535] held in 685 2002 reported that scalable distributed configuration management for 686 sets of network devices is a significant challenge today. An 687 enhanced network management architecture that more fully supports 688 real operational needs is desirable. Even individual improvements in 689 configuration management for sets of networked devices would be very 690 welcome. Such improvements would need to include an integrated 691 approach to security for the configuration data. 693 3.5.1. Enhanced Monitoring Capabilities 695 SNMP does not scale very well to monitoring large numbers of objects 696 in many devices in different parts of the network. An alternative 697 approach worth exploring is how to provide scalable and distributed 698 monitoring, not on individual devices, but instead on groups of 699 devices and networks-as-a-whole. 701 3.5.2. Managing Networks, Not Devices 703 In particular, at present there are few or no good tools for managing 704 a whole network of devices, though SNMP (Simple Network Management 705 Protocol) and CMIP (Common Management Information Protocol) are fine 706 for reading status of well-defined objects from individual boxes. 707 Applied research into methods of managing sets of networked devices 708 seems worthwhile. Ideally this configuration management approach 709 would support distributed management, rather than being strictly 710 hierarchical. 712 As an example, the current set of network management tools for 713 managing multimedia (voice and video) IP networks is inadequate, and 714 research would be useful in this area. The lack of appropriate 715 network management tools has also been cited as one of the major 716 barriers to the deployment of IP multicast [D00, SP03]. 718 3.5.3. Improving the Scalability of Network Management 720 An open issue related to network management is helping users and 721 others to identify and resolve problems in the network. If a user 722 can't access a web page, it would be useful if the user could find 723 out, easily, without having to run ping and traceroute, whether the 724 problem was that the web server was down, that the network was 725 partitioned due to a link failure, that there was heavy congestion 726 along the path, that the DNS name couldn't be resolved, that the 727 firewall prohibited the access, or something else. Current 728 approaches to network management do not scale sufficiently, so 729 network service providers and enterprises often have difficulty 730 operating their network(s) as successfully and economically as 731 desired. Hence, more work is needed to improve the scalability of 732 network management systems. This might involve application of 733 artificial intelligence, expert systems technology, or other 734 mechanisms, for example. 736 3.6. Quality of Service 738 There has been an intensive body of research and development work on 739 adding QoS to the Internet architecture for more than ten years now 740 [RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210], yet we still 741 don't have end-to-end QoS in the Internet [RFC-2990]. The IETF is 742 good at defining individual QoS mechanisms, but poor at work on 743 deployable QoS architectures. Thus, while Differentiated Services 744 (DiffServ) mechanisms have been standardized as per-hop behaviors, 745 there is still much to be learned about the deployment of that or 746 other QoS mechanisms for end-to-end QoS. In addition to work on 747 purely technical issues, this includes close attention to the 748 economic models and deployment strategies that would enable an 749 increased deployment of QoS in the network. 751 In many cases, deployment of QoS mechanisms would significantly 752 increase operational security risks [RFC-2990], so any new research 753 on QoS mechanisms or architectures ought to specifically discuss the 754 potential security issues associated with the new proposal(s) and how 755 to mitigate those security issues. 757 One of the factors that has blunted the demand for QoS has been the 758 transition of the Internet infrastructure from heavy congestion in 759 the early 1990s, to overprovisioning in backbones and in many 760 international links now. Thus, research in QoS mechanisms also has 761 to include some careful attention to the relative costs and benefits 762 of QoS in different places in the network. Applied research into QoS 763 should include explicit consideration of economic issues of deploying 764 and operating a QoS-enabled IP network [Clark02]. 766 3.6.1. Inter-Domain QoS Architecture 768 Deploying existing Quality-of-Service (QoS) mechanisms, for example 769 Differentiated Services or Integrated Services, across an inter- 770 domain boundary creates a significant and easily exploited denial-of- 771 service vulnerability for any network that provides inter-domain QoS 772 support. This has caused network operators to refrain from 773 supporting inter-domain QoS. The Internet would benefit from 774 additional research into alternative approaches to QoS, approaches 775 that do not create such vulnerabilities and can be deployed end-to- 776 end [RFC-2990]. 778 Also, current business models are not consistent with inter-domain 779 QoS, in large part because it is impractical or impossible to 780 authenticate the identity of the sender of would-be preferred traffic 781 while still forwarding traffic at line-rate. Absent such an ability, 782 it is unclear how a network operator could bill or otherwise recover 783 costs associated with providing that preferred service. So any new 784 work on inter-domain QoS mechanisms and architectures needs to 785 carefully consider the economic and security implications of such 786 proposals. 788 3.6.2. New Queuing Disciplines 790 The overall Quality-of-Service for traffic is in part determined by 791 the scheduling and queue management mechanisms at the routers. While 792 there are a number of existing mechanisms (e.g. RED) that work 793 reasonably well, it is possible that improved queuing strategies 794 might be devised. Mechanisms that lowered the implementation cost in 795 IP routers might help increase deployment of active queue management, 796 for example. 798 3.7. Congestion control. 800 TCP's congestion control mechanisms, from 1988 [J88], have been a key 801 factor in maintaining the stability of the Internet, and are used by 802 the bulk of the Internet's traffic. However, the congestion control 803 mechanisms of the Internet need to be expanded and modified to meet a 804 wide range of new stresses, from new applications such as streaming 805 media and multicast to new environments such as wireless networks or 806 very high bandwidth paths, and new requirements for minimizing 807 queueing delay. While there are significant bodies of work in 808 several of these issues, considerably more needs to be done. (We 809 would note that research on TCP congestion control is also not yet 810 "done", with much still to be accomplished in high-speed TCP, or in 811 adding robust performance over paths with significant reordering, 812 intermittent connectivity, non-congestive packet loss, and the like.) 814 Several of these issues bring up difficult fundamental questions 815 about the potential costs and benefits of increased communication 816 between layers. Would it help transport to receive hints or other 817 information from routing, from link layers, or from other transport- 818 level connections? If so, what would be the cost to robust operation 819 across diverse environments? 821 For congestion control mechanisms in routers, active queue management 822 and Explicit Congestion Notification are generally not yet deployed, 823 and there are a range of proposals, in various states of maturity, in 824 this area. At the same time, there is a great deal that we still do 825 not understand about the interactions of queue management mechanisms 826 with other factors in the network. Router-based congestion control 827 mechanisms are also needed for detecting and responding to aggregate 828 congestion such as in Distributed Denial of Service attacks and flash 829 crowds. 831 As more applications have the need to transfer very large files over 832 high delay-bandwidth-product paths, the stresses on current 833 congestion control mechanisms raise the question of whether we need 834 more fine-grained feedback from routers. This includes the challenge 835 of allowing connections to avoid the delays of slow-start, and to 836 rapidly make use of newly-available bandwidth. 838 There is also a need for long-term research in congestion control 839 that is separate from specific functional requirements like the ones 840 listed above. We know very little about congestion control dynamics 841 or traffic dynamics a large, complex network like the global 842 Internet, with its heterogeneous and changing traffic mixes, link- 843 level technologies, network protocols and router mechanisms, patterns 844 of congestion, pricing models, and the like. Expanding our knowledge 845 in this area seems likely to require a rich mix of measurement, 846 analysis, simulations, and experimentation. 848 3.8. Studying the Evolution of the Internet Infrastructure 850 The evolution of the Internet infrastructure has been frustratingly 851 slow and difficult, with long stories about the difficulties in 852 adding IPv6, QoS, multicast, and other functionality to the Internet. 853 We need a more scientific understanding of the evolutionary 854 potentials and evolutionary difficulties of the Internet 855 infrastructure. 857 This evolutionary potential is affected not only by the technical 858 issues of the layered IP architecture, but by other factors as well. 859 These factors include the changes in the environment over time (e.g., 860 the recent overprovisioning of backbones, the deployment of 861 firewalls), and the role of standardization process. Economic and 862 public policy factors are also critical, including the central fact 863 of the Internet as a decentralized system, with key players being not 864 only individuals, but also ISPs, companies, and entire industries. 865 Deployment issues are also key factors in the evolution of the 866 Internet, including the continual chicken-and-egg problem of having 867 enough customers to merit rolling out a service whose utility depends 868 on the size of the customer base in the first place. 870 Overlay networks might serve as a transition technology for new 871 functionality, with an initial deployment in overlay networks, and 872 with the new functionality moving later into the core if it seems 873 warranted. 875 There are also increased obstacles to the evolution of the Internet 876 in the form of increased complexity [WD02], unanticipated feature 877 interactions [K00], interactions between layers [CWWS92], 878 interventions by middleboxes [RFC-3424], and the like. Because 879 increasing complexity appears inevitable, research is needed to 880 understand architectural mechanisms that can accommodate increased 881 complexity without decreasing robustness of performance in unknown 882 environments, and without closing off future possibilities for 883 evolution. 885 3.9. Middleboxes 887 Research is needed to address the challenges posed by middleboxes. 888 This includes issues of security, control, and data integrity, and on 889 the general impact of middleboxes on the architecture. 891 In many ways middleboxes are a direct outgrowth of commercial 892 interests, but there is a need to look beyond the near-term needs for 893 the technology, to research its broader implications and to explore 894 ways to improve how middleboxes are integrated into the architecture. 896 3.10. Internet Measurement 898 A recurring challenge is measuring the Internet; there have been many 899 discussions about the need for measurement studies as an integral 900 part of Internet research [Claffy03]. In this discussion, we define 901 measurement quite broadly. For example, there are numerous 902 challenges in measuring performance along any substantial Internet 903 path, particularly when the path crosses administrative domain 904 boundaries. There are also challenges in measuring 905 protocol/application usage on any high speed Internet link. Many of 906 the problems discussed above would benefit from increased frequency 907 of measurement as well as improved quality of measurement on the 908 deployed Internet. 910 A key issue in network measurement is that most commercial Internet 911 Service Providers consider the particular characteristics of their 912 production IP network(s) to be trade secrets. Ways need to be found 913 for legitimate non-commercial researchers to be able to measure 914 relevant network parameters while also protecting the privacy rights 915 of the measured ISPs. 917 Absent measured data, there is possibly an over-reliance on network 918 simulations in some parts of the Internet research community and 919 probably insufficient validation that existing network simulation 920 models are reasonably good representations of the deployed Internet 921 (or of some plausible future Internet) [FK02]. 923 Without solid measurement of the current Internet behaviour, it is 924 very difficult to know what otherwise unknown operational problems 925 exist that require attention, and it is equally difficult to fully 926 understand the impact of changes (past or future) upon the Internet's 927 actual behavioural characteristics. 929 3.11. Meeting the Needs of the Future 931 As network size, link bandwidth, CPU capacity, and the number of 932 users all increase, research will be needed to ensure that the 933 Internet of the future scales to meet these increasing demands. We 934 have discussed some of these scaling issues in specific sections 935 above. 937 However, for all of the research questions discussed in this 938 document, the goal of the research must be not only to meet the 939 challenges already experienced today, but also to meet the challenges 940 that can be expected to emerge in the future. 942 3.12. Additional topics 944 We have not included in this document discussions about the need for 945 additional research in providing tools for researchers (e.g., 946 modeling, simulations, test-beds). 948 Any new sections in this document should be focused on the problems 949 that need to be addressed, rather than focused on the new approaches 950 or technologies that might be promising answers to those problems. 952 4. Conclusions 954 This document has summarized the history of research funding for the 955 Internet and highlighted examples of open research questions. The 956 IAB believes that more research is required to further the evolution 957 of the Internet infrastructure, and that consistent, sufficient non- 958 commercial funding is needed to enable such research. 960 In case there is any confusion, we are not in this document 961 suggesting any direct or indirect role for the IAB, the IETF, or the 962 IRTF in handling any funding for Internet research. 964 5. Acknowledgements 966 The people who directly contributed to this document in some form 967 include the following: Ran Atkinson, Rob Austein, Jon Crowcroft, 968 Sally Floyd, James Kempf, Craig Partridge, Vern Paxson, and Mike St. 969 Johns. We are also grateful to Kim Claffy, Andrei Gurtov, Hilarie 970 Orman for feedback. 972 We have also drawn widely on the following sources: [CIPB02], 973 [IST02], [NV02], [NSF02], [NSF03], [NSF03a]. 975 Upcoming workshops include the following: [COST-NSF03]. 977 6. Security Considerations 979 This document does not itself create any new security issues for the 980 Internet community. Security issues within the Internet Architecture 981 primarily are discussed in Section 3.4 above. 983 7. IANA Considerations 985 There are no IANA considerations regarding this document. 987 Normative References 989 There are no Normative References because this is an Informational 990 document. 992 Informative References 994 [Atk96] R. Atkinson et alia, "Implementation of IPv6 in 4.4 BSD", 995 Proceedings of USENIX 1996 Annual Technical Conference, USENIX 996 Association, Berkeley, CA, January 1996. 998 [Bellman1957] R.E. Bellman, "Dynamic Programming", Princeton 999 University Press, Princeton, NJ, 1957. 1001 [BL1976] D. E. Bell & L. J. LaPadula, "Secure Computer Systems: 1002 Unified Exposition and Multics Interpretation", MITRE Technical 1003 Report NMTR-1997 (ESD-TR-75-306), The Mitre Corporation, March 1976. 1005 [Claffy03] K. Claffy, "Priorities and Challenges in Internet 1006 Measurement, Simulation, and Analysis", NSF PI meeting, January 2003. 1007 URL "http://www.caida.org/outreach/presentations/2003/nsfpi0301/". 1009 [Clark02] D. D. Clark, "Deploying the Internet - why does it take so 1010 long and, can research help ?", Large-Scale Networking Distinguished 1011 Lecture Series, (US) National Science Foundation, Arlington, VA, 8 1012 January 2002. URL: http://www.ngi-supernet.org/conferences.html 1014 [CSTB99] Computer Science & Telecommunications Board, (US) National 1015 Research Council, "Funding a Revolution: Government Support for 1016 Computing Research", National Academy Press, Washington, DC, 1999. 1017 URL "http://www7.nationalacademies.org/cstb/pub_revolution.html". 1019 [CIPB02] Critical Infrastructure Protection Board, "National Strategy 1020 to Secure Cyberspace", The White House, Washington, DC, September 1021 2002, URL "http://www.whitehouse.gov/pcipb". 1023 [COST-NSF03] COST-IST(EU)--NSF(USA) Workshop on Networking, June, 1024 2003. URL "http://cgi.di.uoa.gr/~istavrak/costnsf/". 1026 [CWWS92] J. Crowcroft, I Wakeman, Z. Wang, & D. Sirovica, "Is 1027 Layering Harmful ?", IEEE Networks, January 1992. 1029 [Diot00] C. Diot, et alia, "Deployment Issues for the IP Multicast 1030 Service and Architecture", IEEE Network, January/February 2000. 1032 [Deering1988] S. Deering, "Multicast Routing in Internetworks and 1033 LANs", ACM Computer Communications Review, Volume 18, Issue 4, August 1034 1988. 1036 [Dijkstra59] E. Dijkstra, "A note on two problems in connexion with 1037 graphs", Numerishe Mathematik, 1, 1959, pp.269-271. 1039 [FF1962] L.R. Ford Jr. & D.R. Fulkerson, "Flows in Networks", 1040 Princeton University Press, Princeton, NJ, 1962. 1042 [FK02] S. Floyd and E. Kohler, Internet Research Needs Better Models, 1043 Hotnets-I. October 2002. URL 1044 "http://www.icir.org/models/bettermodels.html". 1046 [Handley02] Mark Handley's viewgraphs to an NSF meeting, 2002. 1048 [IM1993] J. Ioannidis & G. Maguire Jr., "The Design and 1049 Implementation of a Mobile Internetworking Architecture", Proceedings 1050 of the Winter USENIX Technical Conference, pages 489-500, January 1051 1993. 1053 [IST02] Research Networking in Europe - Striving for Global 1054 Leadership, Information Society Technologies, 2002. URL 1055 "http://www.cordis.lu/ist/rn/rn-brochure.htm". 1057 [J88] Van Jacobson, Congestion Avoidance and Control, SIGCOMM, 1988. 1058 URL "http://citeseer.nj.nec.com/jacobson88congestion.html". 1060 [J02] William Jackson, "U.S. should fund R&D for secure Internet 1061 protocols, Clarke says", 10/31/02, URL 1062 "http://www.gcn.com/vol1_no1/security/20382-1.html". 1064 [K00] Hans Kruse, The Pitfalls of Distributed Protocol Development: 1065 Unintentional Interactions between Network Operations and 1066 Applications Protocols, 8th International Conference on 1067 Telecommunication Systems Design, Nashville, March 2000. URL 1068 "http://www.csm.ohiou.edu/kruse/publications/TSYS2000.pdf". 1070 [KLMS2000] S. Kent, C. Lynn, J. Mikkelson, & K. Seo, "Secure Border 1071 Gateway Protocol (S-BGP)", Proceedings of ISoc Network & Distributed 1072 Systems Security Symposium, Internet Society, Reston, VA, February 1073 2000. 1075 [LD2002] E. Lear & R. Droms, "What's in a Name: Thoughts from the 1076 NSRG", Internet-Draft, December 2002. 1078 [MBFIPS01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John 1079 Ioannidis, Vern Paxson, and Scott Shenker, Controlling High Bandwidth 1080 Aggregates in the Network (Extended Version), July, 2001. URL 1081 "http://www.icir.org/pushback/". 1083 [MBKQ96] M. McKusick, K. Bostic, M. Karels, & J. Quarterman, "Design 1084 and Implementation of the 4.4 BSD Operating System", Addison-Wesley, 1085 Reading, MA, 1996. 1087 [S03] J. I. Schiller, "Interception Technology: The Good, The Bad, 1088 and The Ugly!", NANOG, June 2003. URL 1089 "http://www.nanog.org/mtg-0306/schiller.html". 1091 [Schiller03] J. I. Schiller, Private Communication, MIT, Cambridge, 1092 MA. 2003. 1094 [NV02] NetVision 2012 Committee,"DARPA's Ten-Year Strategic Plan for 1095 Networking Research", (US) Defence Advanced Research Projects Agency, 1096 October 2002. Citation for acknowledgement purposes only. 1098 [NSF02] NSF Workshop on Network Research Testbeds, October 2002. URL 1099 "http://www-net.cs.umass.edu/testbed_workshop/". 1101 [NSF03] NSF ANIR Principal Investigator meeting, January 9-10, 2003, 1102 URL "http://www.ncne.org/training/nsf-pi/2003/nsfpimain.html". 1104 [NSF03a] Revolutionizing Science and Engineering Through 1105 Cyberinfrastructure, NSF Report, January 2003. URL 1106 "http://www.cise.nsf.gov/evnt/reports/atkins_annc_020303.htm". 1108 [ResearchQuestions] Web Page on "Papers about Research Questions for 1109 the Internet", URL 1110 "http://www.icir.org/floyd/research_questions.html". 1112 [RFC-1510] J. Kohl & C. Neuman, "The Kerberos Network Authentication 1113 Service (V5)", RFC 1510, September 1993. 1115 [RFC-2082] F. Baker & R. Atkinson, "RIPv2 MD5 Authentication", 1116 RFC-2082, January 1997. 1118 [RFC-2154] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital 1119 Signatures", RFC-2154, June 1997. 1121 [RFC-2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 1122 Signature Option", RFC-2385, August 1998. 1124 [RFC-2407] D. Piper, "The Internet IP Security Domain of 1125 Interpretation for ISAKMP", RFC-2407, November 1998. 1127 [RFC-2501] S. Corson & J. Macker, "Mobile Ad Hoc Networking (MANET): 1128 Routing Protocol Performance Issues and Evaluation Considerations", 1129 RFC-2501, January 1999. 1131 [RFC-2990] G. Huston, "Next Steps for the IP QoS Architecture", 1132 RFC-1990, November 2000. 1134 [RFC-3221] G. Huston, "Commentary on Inter-Domain Routing in the 1135 Internet", RFC-3221, December 2001. 1137 [RFC-3424] L. Daigle (Ed.), "IAB Considerations for Unilateral Self- 1138 Address Fixing (UNSAF) Across Network Address Translation", RFC-3424, 1139 Internet Architecture Board, November 2002. 1141 [RFC-3535] J. Schoenwalder, Editor, "Overfiew of the 2002 IAB Network 1142 Management Workshop", RFC-3535, May 2003. 1144 [RIPE] RIPE (Reseaux IP Europeens), URL "http://www.ripe.net/ripe/". 1146 [Sav00] Savage, S., Wetherall, D., Karlink, A. R., and Anderson, T., 1147 Practical Network Support for IP Traceback, SIGCOMM 2000. 1149 [SP03] P. Sharma & R. Malpani, "IP Multicast Operational Network 1150 Management: Design, Challenges, and Experiences", IEEE Network, March 1151 2003. 1153 [WD02] Walter Willinger and John Doyle, "Robustness and the Internet: 1154 Design and Evolution", 2002, URL 1155 "http://netlab.caltech.edu/internet/". 1157 [WIDE] WIDE Project, URL "http://www.wide.ad.jp/". 1159 9. AUTHORS' ADDRESSES 1161 Internet Architecture Board 1162 EMail: iab@iab.org 1164 Internet Architecture Board Members 1165 at the time this document was published were: 1167 Bernard Aboba 1168 Harald Alvestrand (IETF chair) 1169 Rob Austein 1170 Leslie Daigle (IAB chair) 1171 Patrik Faltstrom 1172 Sally Floyd 1173 Jun-ichiro Itojun Hagino 1174 Mark Handley 1175 Geoff Huston (IAB Executive Director) 1176 Charlie Kaufman 1177 James Kempf 1178 Eric Rescorla 1179 Mike St. Johns 1181 We note that Ran Atkinson, one of the editors of the document, 1182 was an IAB member at the time that this document was created, 1183 and that Vern Paxson, the IRTF chair, is an ex-officio member 1184 of the IAB. 1186 This draft was created in November 2002 and revised January 2003, 1187 February 2003, and June 2003.