diff options
Diffstat (limited to 'doc/rfc/rfc3869.txt')
| -rw-r--r-- | doc/rfc/rfc3869.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc3869.txt b/doc/rfc/rfc3869.txt new file mode 100644 index 0000000..9572a7f --- /dev/null +++ b/doc/rfc/rfc3869.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group R. Atkinson, Ed. +Request for Comments: 3869 S. Floyd, Ed. +Category: Informational Internet Architecture Board + August 2004 + + + IAB Concerns and Recommendations + Regarding Internet Research and Evolution + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document discusses IAB concerns that ongoing research is needed + to further the evolution of the Internet infrastructure, and that + consistent, sufficient non-commercial funding is needed to enable + such research. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Document Organization. . . . . . . . . . . . . . . . . . 2 + 1.2. IAB Concerns . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Contributions to this Document . . . . . . . . . . . . . 4 + 2. History of Internet Research and Research Funding. . . . . . . 4 + 2.1. Prior to 1980. . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. 1980s and early 1990s. . . . . . . . . . . . . . . . . . 5 + 2.3. Mid-1990s to 2003. . . . . . . . . . . . . . . . . . . . 6 + 2.4. Current Status . . . . . . . . . . . . . . . . . . . . . 6 + 3. Open Internet Research Topics. . . . . . . . . . . . . . . . . 7 + 3.1. Scope and Limitations. . . . . . . . . . . . . . . . . . 7 + 3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.1. Domain Name System (DNS). . . . . . . . . . . . 8 + 3.2.2. New Namespaces. . . . . . . . . . . . . . . . . 9 + 3.3. Routing. . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3.1. Inter-domain Routing. . . . . . . . . . . . . . 10 + 3.3.2. Routing Integrity . . . . . . . . . . . . . . . 11 + 3.3.3. Routing Algorithms. . . . . . . . . . . . . . . 12 + 3.3.4. Mobile and Ad-Hoc Routing . . . . . . . . . . . 13 + 3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 13 + + + +Atkinson & Floyd Informational [Page 1] + +RFC 3869 Research Funding Recommendations August 2004 + + + 3.4.1. Formal Methods. . . . . . . . . . . . . . . . . 14 + 3.4.2. Key Management. . . . . . . . . . . . . . . . . 14 + 3.4.3. Cryptography. . . . . . . . . . . . . . . . . . 15 + 3.4.4. Security for Distributed Computing. . . . . . . 15 + 3.4.5. Deployment Considerations in Security . . . . . 15 + 3.4.6. Denial of Service Protection. . . . . . . . . . 16 + 3.5. Network Management . . . . . . . . . . . . . . . . . . . 16 + 3.5.1. Managing Networks, Not Devices. . . . . . . . . 16 + 3.5.2. Enhanced Monitoring Capabilities. . . . . . . . 17 + 3.5.3. Customer Network Management . . . . . . . . . . 17 + 3.5.4. Autonomous Network Management . . . . . . . . . 17 + 3.6. Quality of Service . . . . . . . . . . . . . . . . . . . 17 + 3.6.1. Inter-Domain QoS Architecture . . . . . . . . . 18 + 3.6.2. New Queuing Disciplines . . . . . . . . . . . . 19 + 3.7. Congestion Control . . . . . . . . . . . . . . . . . . . 19 + 3.8. Studying the Evolution of the Internet Infrastructure. . 20 + 3.9. Middleboxes. . . . . . . . . . . . . . . . . . . . . . . 21 + 3.10. Internet Measurement . . . . . . . . . . . . . . . . . . 21 + 3.11. Applications . . . . . . . . . . . . . . . . . . . . . . 22 + 3.12. Meeting the Needs of the Future. . . . . . . . . . . . . 22 + 3.13. Freely Distributable Prototypes. . . . . . . . . . . . . 23 + 4. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24 + 7. Informative References . . . . . . . . . . . . . . . . . . . . 24 + 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 + 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 + +1. Introduction + + This document discusses the history of funding for Internet research, + expresses concern about the current state of such funding, and + outlines several specific areas that the IAB believes merit + additional research. Current funding levels for Internet research + are not generally adequate, and several important research areas are + significantly underfunded. This situation needs to be rectified for + the Internet to continue its evolution and development. + +1.1. Document Organization + + The first part of the document is a high-level discussion of the + history of funding for Internet research to provide some historical + context to this document. The early funding of Internet research was + largely from the U.S. government, followed by a period in the second + half of the 1990s of commercial funding and of funding from several + governments. However, the commercial funding for Internet research + has been reduced due to the recent economic downturn. + + + + +Atkinson & Floyd Informational [Page 2] + +RFC 3869 Research Funding Recommendations August 2004 + + + The second part of the document provides an incomplete set of open + Internet research topics. These are only examples, intended to + illustrate the breadth of open research topics. This second section + supports the general thesis that ongoing research is needed to + further the evolution of the Internet infrastructure. This includes + research on the medium-time-scale evolution of the Internet + infrastructure as well as research on longer-time-scale grand + challenges. This also includes many research issues that are already + being actively investigated in the Internet research community. + + Areas that are discussed in this section include the following: + naming, routing, security, network management, and transport. Issues + that require more research also include more general architectural + issues such as layering and communication between layers. In + addition, general topics discussed in this section include modeling, + measurement, simulation, test-beds, etc. We are focusing on topics + that are related to the IETF and IRTF (Internet Research Task Force) + agendas. (For example, Grid issues are not discussed in this + document because they are addressed through the Global Grid Forum and + other Grid-specific organizations, not in the IETF.) + + Where possible, the examples in this document point to separate + documents on these issues, and only give a high-level summary of the + issues raised in those documents. + +1.2. IAB Concerns + + In the aftermath of September 11 2001, there seems to be a renewed + interest by governments in funding research for Internet-related + security issues. From [Jackson02]: "It is generally agreed that the + security and reliability of the basic protocols underlying the + Internet have not received enough attention because no one has a + proprietary interest in them". + + That quote brings out a key issue in funding for Internet research, + which is that because no single organization (e.g., no single + government, software company, equipment vendor, or network operator) + has a sense of ownership of the global Internet infrastructure, + research on the general issues of the Internet infrastructure are + often not adequately funded. In our current challenging economic + climate, it is not surprising that commercial funding sources are + more likely to fund that research that leads to a direct competitive + advantage. + + The principal thesis of this document is that if commercial funding + is the main source of funding for future Internet research, the + future of the Internet infrastructure could be in trouble. In + addition to issues about which projects are funded, the funding + + + +Atkinson & Floyd Informational [Page 3] + +RFC 3869 Research Funding Recommendations August 2004 + + + source can also affect the content of the research, for example, + towards or against the development of open standards, or taking + varying degrees of care about the effect of the developed protocols + on the other traffic on the Internet. + + At the same time, many significant research contributions in + networking have come from commercial funding. However, for most of + the topics in this document, relying solely on commercially-funded + research would not be adequate. Much of today's commercial funding + is focused on technology transition, taking results from non- + commercial research and putting them into shipping commercial + products. We have not tried to delve into each of the research + issues below to discuss, for each issue, what are the potentials and + limitations of commercial funding for research in that area. + + On a more practical note, if there was no commercial funding for + Internet research, then few research projects would be taken to + completion with implementations, deployment, and follow-up + evaluation. + + While it is theoretically possible for there to be too much funding + for Internet research, that is far from the current problem. There + is also much that could be done within the network research community + to make Internet research more focused and productive, but that would + belong in a separate document. + +1.3. Contributions to this Document + + A number of people have directly contributed text for this document, + even though, following current conventions, the official RFC author + list includes only the key editors of the document. The + Acknowledgements section at the end of the document thanks other + people who contributed to this document in some form. + +2. History of Internet Research and Research Funding + +2.1. Prior to 1980 + + Most of the early research into packet-switched networks was + sponsored by the U.S. Defense Advanced Research Projects Agency + (DARPA) [CSTB99]. This includes the initial design, implementation, + and deployment of the ARPAnet connecting several universities and + other DARPA contractors. The ARPAnet originally came online in the + late 1960s. It grew in size during the 1970s, still chiefly with + DARPA funding, and demonstrated the utility of packet-switched + networking. + + + + + +Atkinson & Floyd Informational [Page 4] + +RFC 3869 Research Funding Recommendations August 2004 + + + DARPA funding for Internet design started in 1973, just four years + after the initial ARPAnet deployment. The support for Internet + design was one result of prior DARPA funding for packet radio and + packet satellite research. The existence of multiple networks + (ARPAnet, packet radio, and packet satellite) drove the need for + internetworking research. The Internet arose in large measure as a + consequence of DARPA research funding for these three networks -- and + arise only incidentally from the commercially-funded work at Xerox + PARC on Ethernet. + +2.2. 1980s and early 1990s + + The ARPAnet converted to the Internet Protocol (IP) on January 1, + 1983, approximately 20 years before this document was written. + Throughout the 1980s, the U.S. Government continued strong research + and development funding for Internet technology. DARPA continued to + be the key funding source, but was supplemented by other DoD (U.S. + Department of Defense) funding (e.g., via the Defense Data Network + (DDN) program of the Defense Communication Agency (DCA)) and other + U.S. Government funding (e.g., U.S. Department of Energy (DoE) + funding for research networks at DoE national laboratories, (U.S.) + National Science Foundation (NSF) funding for academic institutions). + This funding included basic research, applied research (including + freely distributable prototypes), the purchase of IP-capable + products, and operating support for the IP-based government networks + such as ARPAnet, ESnet, MILnet, the NASA Science Internet, and + NSFnet. + + During the 1980s, the U.S. DoD desired to leave the business of + providing operational network services to academic institutions, so + funding for most academic activities moved over to the NSF during the + decade. NSF's initial work included sponsorship of CSnet in 1981. + By 1986, NSF was also sponsoring various research projects into + networking (e.g., Mills' work on Fuzzballs). In the late 1980s, NSF + created the NSFnet backbone and sponsored the creation of several NSF + regional networks (e.g., SURAnet) and interconnections with several + international research networks. NSF also funded gigabit networking + research, through the Corporation for National Research Initiatives + (CNRI), starting in the late 1980s. It is important to note that the + NSF sponsorship was focused on achieving core NSF goals, such as + connecting scientists at leading universities to NSF supercomputing + centers. The needs of high-performance remote access to + supercomputers drove the overall NSFnet performance. As a side + effect, this meant that students and faculty at those universities + enjoyed a relatively high-performance Internet environment. As those + students graduated, they drove both commercial use of the Internet + and the nascent residential market. It is no accident that this was + the environment from which the world wide web emerged. + + + +Atkinson & Floyd Informational [Page 5] + +RFC 3869 Research Funding Recommendations August 2004 + + + Most research funding outside the U.S. during the 1980s and early + 1990s was focused on the ISO OSI networking project or on then-new + forms of network media (e.g., wireless, broadband access). The + European Union was a significant source of research funding for the + networking community in Europe during this period. Some of the best + early work in gigabit networking was undertaken in the UK and Sweden. + +2.3. Mid-1990s to 2003 + + Starting in the middle 1990s, U.S. Government funding for Internet + research and development was significantly reduced. The premise for + this was that the growing Internet industry would pay for whatever + research and development that was needed. Some funding for Internet + research and development has continued in this period from European + and Asian organizations (e.g., the WIDE Project in Japan [WIDE]). + Reseaux IP Europeens [RIPE] is an example of market-funded networking + research in Europe during this period. + + Experience during this period has been that commercial firms have + often focused on donating equipment to academic institutions and + promoting somewhat vocationally-focused educational projects. Many + of the commercially-funded research and development projects appear + to have been selected because they appeared likely to give the + funding source a specific short-term economic advantage over its + competitors. Higher risk, more innovative research proposals + generally have not been funded by industry. A common view in Silicon + Valley has been that established commercial firms are not very good + at transitioning cutting edge research into products, but were + instead good at buying small startup firms who had successfully + transitioned such cutting edge research into products. + Unfortunately, small startup companies are generally unable + financially to fund any research themselves. + +2.4. Current Status + + The result of reduced U.S. Government funding and profit-focused, + low-risk, short-term industry funding has been a decline in higher- + risk but more innovative research activities. Industry has also been + less interested in research to evolve the overall Internet + architecture, because such work does not translate into a competitive + advantage for the firm funding such work. + + The IAB believes that it would be helpful for governments and other + non-commercial sponsors to increase their funding of both basic + research and applied research relating to the Internet, and to + sustain these funding levels going forward. + + + + + +Atkinson & Floyd Informational [Page 6] + +RFC 3869 Research Funding Recommendations August 2004 + + +3. Open Internet Research Topics + + This section primarily discusses some specific topics that the IAB + believes merit additional research. Research, of course, includes + not just devising a theory, algorithm, or mechanism to accomplish a + goal, but also evaluating the general efficacy of the approach and + then the benefits vs. the costs of deploying that algorithm or + mechanism. Important cautionary notes about this discussion are + given in the next sub-section. This particular set of topics is not + intended to be comprehensive, but instead is intended to demonstrate + the breadth of open Internet research questions. + + Other discussions of problems of the Internet that merit further + research include the following: + [CIPB02,Claffy03a,Floyd,NSF03a,NSF03b]. + +3.1. Scope and Limitations + + This document is NOT intended as a guide for public funding agencies + as to exactly which projects or proposals should or should not be + funded. + + In particular, this document is NOT intended to be a comprehensive + list of *all* of the research questions that are important to further + the evolution of the Internet; that would be a daunting task, and + would presuppose a wider and more intensive effort than we have + undertaken in this document. + + Similarly, this document is not intended to list the research + questions that are judged to be only of peripheral importance, or to + survey the current (global; governmental, commercial, and academic) + avenues for funding for Internet research, or to make specific + recommendations about which areas need additional funding. The + purpose of the document is to persuade the reader that ongoing + research is needed towards the continued evolution of the Internet + infrastructure; the purpose is not to make binding pronouncements + about which specific areas are and are not worthy of future funding. + + For some research clearly relevant to the future evolution of the + Internet, there are grand controversies between competing proposals + or competing schools of thought; it is not the purpose of this + document to take positions in these controversies, or to take + positions on the nature of the solutions for areas needing further + research. + + + + + + + +Atkinson & Floyd Informational [Page 7] + +RFC 3869 Research Funding Recommendations August 2004 + + + That all carefully noted, the remainder of this section discusses a + broad set of research areas, noting a subset of particular topics of + interest in each of those research areas. Again, this list is NOT + comprehensive, but rather is intended to suggest that a broad range + of ongoing research is needed, and to propose some candidate topics. + +3.1.1. Terminology + + Several places in this document refer to 'network operators'. By + that term, we intend to include anyone or any organization that + operates an IP-based network; we are not using that term in the + narrow meaning of commercial network service providers. + +3.2. Naming + + The Internet currently has several different namespaces, including IP + addresses, sockets (specified by the IP address, upper-layer + protocol, and upper-layer port number), Autonomous System (AS) + number, and the Fully-Qualified Domain Name (FQDN). Many of the + Internet's namespaces are supported by the widely deployed Domain + Name System [RFC-3467] or by various Internet applications [RFC-2407, + Section 4.6.2.1] + +3.2.1. Domain Name System (DNS) + + The DNS system, while it works well given its current constraints, + has several stress points. + + The current DNS system relies on UDP for transport, rather than SCTP + or TCP. Given the very large number of clients using a typical DNS + server, it is desirable to minimize the state on the DNS server side + of the connection. UDP does this well, so it is a reasonable choice, + though this has other implications, for example a reliance on UDP + fragmentation. With IPv6, intermediate fragmentation is not allowed + and Path MTU Discovery is mandated. However, the amount of state + required to deploy Path MTU Discovery for IPv6 on a DNS server might + be a significant practical problem. + + One implication of this is that research into alternative transport + protocols, designed more for DNS-like applications where there are + very many clients using each server, might be useful. Of particular + interest would be transport protocols with little burden for the DNS + server, even if that increased the burden somewhat for the DNS + client. + + Additional study of DNS caching, both currently available caching + techniques and also of potential new caching techniques, might be + helpful in finding ways to reduce the offered load for a typical DNS + + + +Atkinson & Floyd Informational [Page 8] + +RFC 3869 Research Funding Recommendations August 2004 + + + server. In particular, examination of DNS caching through typical + commercial firewalls might be interesting if it lead to alternative + firewall implementations that were less of an obstacle to DNS + caching. + + The community lacks a widely-agreed-upon set of metrics for measuring + DNS server performance. It would be helpful if people would + seriously consider what characteristics of the DNS system should be + measured. + + Some in the community would advocate replacing the current DNS system + with something better. Past attempts to devise a better approach + have not yielded results that persuaded the community to change. + Proposed work in this area could be very useful, but might require + careful scrutiny to avoid falling into historic design pitfalls. + + With regards to DNS security, major technical concerns include + finding practical methods for signing very large DNS zones (e.g., and + tools to make it easier to manage secure DNS infrastructure. + + Most users are unable to distinguish a DNS-related failure from a + more general network failure. Hence, maintaining the integrity and + availability of the Domain Name System is very important for the + future health of the Internet. + +3.2.2. New Namespaces + + Additionally, the Namespace Research Group (NSRG) of the Internet + Research Task Force (IRTF) studied adding one or more additional + namespaces to the Internet Architecture [LD2002]. Many members of + the IRTF NSRG believe that there would be significant architectural + benefit to adding one or more additional namespaces to the Internet + Architecture. Because smooth consensus on that question or on the + properties of a new namespace was not obtained, the IRTF NSRG did not + make a formal recommendation to the IETF community regarding + namespaces. The IAB believes that this is an open research question + worth examining further. + + Finally, we believe that future research into the evolution of + Internet-based distributed computing might well benefit from studying + adding additional namespaces as part of a new approach to distributed + computing. + +3.3. Routing + + The currently deployed unicast routing system works reasonably well + for most users. However, the current unicast routing architecture is + suboptimal in several areas, including the following: end-to-end + + + +Atkinson & Floyd Informational [Page 9] + +RFC 3869 Research Funding Recommendations August 2004 + + + convergence times in global-scale catenets (a system of networks + interconnected via gateways); the ability of the existing inter- + domain path-vector algorithm to scale well beyond 200K prefixes; the + ability of both intra-domain and inter-domain routing to use multiple + metrics and multiple kinds of metrics concurrently; and the ability + of IPv4 and IPv6 to support widespread site multi-homing without + undue adverse impact on the inter-domain routing system. Integrating + policy into routing is also a general concern, both for intra-domain + and inter-domain routing. In many cases, routing policy is directly + tied to economic issues for the network operators, so applied + research into routing ideally would consider economic considerations + as well as technical considerations. + + This is an issue for which the commercial interest is clear, but that + seems unlikely to be solved through commercial funding for research, + in the absence of a consortium of some type. + +3.3.1. Inter-domain Routing + + The current operational inter-domain routing system has between + 150,000 and 200,000 routing prefixes in the default-free zone (DFZ) + [RFC-3221]. ASIC technology obviates concerns about the ability to + forward packets at very high speeds. ASIC technology also obviates + concerns about the time required to perform longest-prefix-match + computations. However, some senior members of the Internet routing + community have concerns that the end-to-end convergence properties of + the global Internet might hit fundamental algorithmic limitations + (i.e., not hardware limitations) when the DFZ is somewhere between + 200,000 and 300,000 prefixes. Research into whether this concern is + well-founded in scientific terms seems very timely. + + Separately from the above concern, recent work has shown that there + can be significant BGP convergence issues today. At present, it + appears that the currently observed convergence issues relate to how + BGP has been configured by network operators, rather than being any + sort of fundamental algorithmic limitation [MGVK02]. This + convergence time issue makes the duration of the apparent network + outage much longer than it should be. Additional applied research + into which aspects of a BGP configuration have the strongest impact + on convergence times would help mitigate the currently observed + operational issues. + + Also, inter-domain routing currently requires significant human + engineering of specific inter-AS paths to ensure that reasonably + optimal paths are used by actual traffic. Ideally, the inter-domain + routing system would automatically cause reasonably optimal paths to + be chosen. Recent work indicates that improved BGP policy mechanisms + + + + +Atkinson & Floyd Informational [Page 10] + +RFC 3869 Research Funding Recommendations August 2004 + + + might help ensure that reasonably optimal paths are normally used for + inter-domain IP traffic. [SMA03] Continued applied research in this + area might lead to substantially better technical approaches. + + The current approach to site multi-homing has the highly undesirable + side-effect of significantly increasing the growth rate of prefix + entries in the DFZ (by impairing the deployment of prefix + aggregation). Research is needed into new routing architectures that + can support large-scale site multi-homing without the undesirable + impacts on inter-domain routing of the current multi-homing + technique. + + The original application for BGP was in inter-domain routing, + primarily within service provider networks but also with some use by + multi-homed sites. However, some are now trying to use BGP in other + contexts, for example highly mobile environments, where it is less + obviously well suited. Research into inter-domain routing and/or + intra-domain policy routing might lead to other approaches for any + emerging environments where the current BGP approach is not the + optimal one. + +3.3.2. Routing Integrity + + Recently there has been increased awareness of the longstanding issue + of deploying strong authentication into the Internet inter-domain + routing system. Currently deployed mechanisms (e.g., BGP TCP MD5 + [RFC-2385], OSPF MD5, RIP MD5 [RFC-2082]) provide cryptographic + authentication of routing protocol messages, but no authentication of + the actual routing data. Recent proposals (e.g., S-BGP [KLMS2000]) + for improving this in inter-domain routing appear difficult to deploy + across the Internet, in part because of their reliance on a single + trust hierarchy (e.g., a single PKI). Similar proposals (e.g., OSPF + with Digital Signatures, [RFC-2154]) for intra-domain routing are + argued to be computationally infeasible to deploy in a large network. + + A recurring challenge with any form of inter-domain routing + authentication is that there is no single completely accurate source + of truth about which organizations have the authority to advertise + which address blocks. Alternative approaches to authentication of + data in the routing system need to be developed. In particular, the + ability to perform partial authentication of routing data would + facilitate incremental deployment of routing authentication + mechanisms. Also, the ability to use non-hierarchical trust models + (e.g., the web of trust used in the PGP application) might facilitate + incremental deployment and might resolve existing concerns about + centralized administration of the routing system, hence it merits + additional study and consideration. + + + + +Atkinson & Floyd Informational [Page 11] + +RFC 3869 Research Funding Recommendations August 2004 + + +3.3.3. Routing Algorithms + + The current Internet routing system relies primarily on two + algorithms. Link-state routing uses the Dijkstra algorithm + [Dijkstra59]. Distance-Vector routing (e.g., RIP) and Path-Vector + routing (e.g., BGP) use the Bellman-Ford algorithm [Bellman1957, + FF1962]. Additional ongoing basic research into graph theory as + applied to routing is worthwhile and might yield algorithms that + would enable a new routing architecture or otherwise provide + improvements to the routing system. + + Currently deployed multicast routing relies on the Deering RPF + algorithm [Deering1988]. Ongoing research into alternative multicast + routing algorithms and protocols might help alleviate current + concerns with the scalability of multicast routing. + + The deployed Internet routing system assumes that the shortest path + is always the best path. This is provably false, however it is a + reasonable compromise given the routing protocols currently + available. The Internet lacks deployable approaches for policy-based + routing or routing with alternative metrics (i.e., some metric other + than the number of hops to the destination). Examples of alternative + policies include: the path with lowest monetary cost; the path with + the lowest probability of packet loss; the path with minimized + jitter; and the path with minimized latency. Policy metrics also + need to take business relationships into account. Historic work on + QoS-based routing has tended to be unsuccessful in part because it + did not adequately consider economic and commercial considerations of + the routing system and in part because of inadequate consideration of + security implications. + + Transitioning from the current inter-domain routing system to any new + inter-domain routing system is unlikely to be a trivial exercise. So + any proposal for a new routing system needs to carefully consider and + document deployment strategies, transition mechanisms, and other + operational considerations. Because of the cross-domain + interoperability aspect of inter-domain routing, smooth transitions + from one inter-domain routing system are likely to be difficult to + accomplish. Separately, the inter-domain routing system lacks strong + market forces that would encourage migration to better technical + approaches. Hence, it appears unlikely that the commercial sector + will be the source of a significantly improved inter-domain routing + system. + + + + + + + + +Atkinson & Floyd Informational [Page 12] + +RFC 3869 Research Funding Recommendations August 2004 + + +3.3.4. Mobile and Ad-Hoc Routing + + While some of the earliest DARPA-sponsored networking research + involved packet radio networks, mobile routing [IM1993] and mobile + ad-hoc routing [RFC-2501] are relatively recent arrivals in the + Internet, and are not yet widely deployed. The current approaches + are not the last word in either of those arenas. We believe that + additional research into routing support for mobile hosts and mobile + networks is needed. Additional research for ad-hoc mobile hosts and + mobile networks is also worthwhile. Ideally, mobile routing and + mobile ad-hoc routing capabilities should be native inherent + capabilities of the Internet routing architecture. This probably + will require a significant evolution from the existing Internet + routing architecture. (NB: The term "mobility" as used here is not + limited to mobile telephones, but instead is very broadly defined, + including laptops that people carry, cars/trains/aircraft, and so + forth.) + + Included in this topic are a wide variety of issues. The more + distributed and dynamic nature of partially or completely self- + organizing routing systems (including the associated end nodes) + creates unique security challenges (especially relating to + Authorization, Authentication, and Accounting, and relating to key + management). Scalability of wireless networks can be difficult to + measure or to achieve. Enforced hierarchy is one approach, but can + be very limiting. Alternative, less constraining approaches to + wireless scalability are desired. Because wireless link-layer + protocols usually have some knowledge of current link characteristics + such as link quality, sublayer congestion conditions, or transient + channel behavior, it is desirable to find ways to let network-layer + routing use such data. This raises architectural questions of what + the proper layering should be, which functions should be in which + layer, and also practical considerations of how and when such + information sharing should occur in real implementations. + +3.4. Security + + The Internet has a reputation for not having sufficient security. In + fact, the Internet has a number of security mechanisms standardized, + some of which are widely deployed. However, there are a number of + open research questions relating to Internet security. In + particular, security mechanisms need to be incrementally deployable + and easy to use. "[Security] technology must be easy to use, or it + will not be configured correctly. If mis-configured, security will + be lost, but things will `work'" [Schiller03]. + + + + + + +Atkinson & Floyd Informational [Page 13] + +RFC 3869 Research Funding Recommendations August 2004 + + +3.4.1. Formal Methods + + There is an ongoing need for funding of basic research relating to + Internet security, including funding of formal methods research that + relates to security algorithms, protocols, and systems. + + For example, it would be beneficial to have more formal study of + non-hierarchical trust models (e.g., PGP's Web-of-Trust model). Use + of a hierarchical trust model can create significant limitations in + how one might approach securing components of the Internet, for + example the inter-domain routing system. So research to develop new + trust models suited for the Internet or on the applicability of + existing non-hierarchical trust models to existing Internet problems + would be worthwhile. + + While there has been some work on the application of formal methods + to cryptographic algorithms and cryptographic protocols, existing + techniques for formal evaluation of algorithms and protocols lack + sufficient automation. This lack of automation means that many + protocols aren't formally evaluated in a timely manner. This is + problematic for the Internet because formal evaluation has often + uncovered serious anomalies in cryptographic protocols. The creation + of automated tools for applying formal methods to cryptographic + algorithms and/or protocols would be very helpful. + +3.4.2. Key Management + + A recurring challenge to the Internet community is how to design, + implement, and deploy key management appropriate to the myriad of + security contexts existing in the global Internet. Most current work + in unicast key management has focused on hierarchical trust models, + because much of the existing work has been driven by corporate or + military "top-down" operating models. + + The paucity of key management methods applicable to non-hierarchical + trust models (see above) is a significant constraint on the + approaches that might be taken to secure components of the Internet. + + Research focused on removing those constraints by developing + practical key management methods applicable to non-hierarchical trust + models would be very helpful. + + Topics worthy of additional research include key management + techniques, such as non-hierarchical key management architectures + (e.g., to support non-hierarchical trust models; see above), that are + useful by ad-hoc groups in mobile networks and/or distributed + computing. + + + + +Atkinson & Floyd Informational [Page 14] + +RFC 3869 Research Funding Recommendations August 2004 + + + Although some progress has been made in recent years, scalable + multicast key management is far from being a solved problem. + Existing approaches to scalable multicast key management add + significant constraints on the problem scope in order to come up with + a deployable technical solution. Having a more general approach to + scalable multicast key management (i.e., one having broader + applicability and fewer constraints) would enhance the Internet's + capabilities. + + In many cases, attribute negotiation is an important capability of a + key management protocol. Experience with the Internet Key Exchange + (IKE) to date has been that it is unduly complex. Much of IKE's + complexity derives from its very general attribute negotiation + capabilities. A new key management approach that supported + significant attribute negotiation without creating challenging levels + of deployment and operations complexity would be helpful. + +3.4.3. Cryptography + + There is an ongoing need to continue the open-world research funding + into both cryptography and cryptanalysis. Most governments focus + their cryptographic research in the military-sector. While this is + understandable, those efforts often have limited (or no) publications + in the open literature. Since the Internet engineering community + must work from the open literature, it is important that open-world + research continues in the future. + +3.4.4. Security for Distributed Computing + + MIT's Project Athena was an important and broadly successful research + project into distributed computing. Project Athena developed the + Kerberos [RFC-1510] security system, which has significant deployment + today in campus environments. However, inter-realm Kerberos is + neither as widely deployed nor perceived as widely successful as + single-realm Kerberos. The need for scalable inter-domain user + authentication is increasingly acute as ad-hoc computing and mobile + computing become more widely deployed. Thus, work on scalable + mechanisms for mobile, ad-hoc, and non-hierarchical inter-domain + authentication would be very helpful. + +3.4.5. Deployment Considerations in Security + + Lots of work has been done on theoretically perfect security that is + impossible to deploy. Unfortunately, the S-BGP proposal is an + example of a good research product that has significant unresolved + deployment challenges. It is far from obvious how one could widely + deploy S-BGP without previously deploying a large-scale inter-domain + public-key infrastructure and also centralizing route advertisement + + + +Atkinson & Floyd Informational [Page 15] + +RFC 3869 Research Funding Recommendations August 2004 + + + policy enforcement in the Routing Information Registries or some + similar body. Historically, public-key infrastructures have been + either very difficult or impossible to deploy at large scale. + Security mechanisms that need additional infrastructure have not been + deployed well. We desperately need security that is general, easy to + install, and easy to manage. + +3.4.6. Denial of Service Protection + + Historically, the Internet community has mostly ignored pure Denial + of Service (DoS) attacks. This was appropriate at one time since + such attacks were rare and are hard to defend against. However, one + of the recent trends in adversarial software (e.g., viruses, worms) + has been the incorporation of features that turn the infected host + into a "zombie". Such zombies can be remotely controlled to mount a + distributed denial of service attack on some victim machine. In many + cases, the authorized operators of systems are not aware that some or + all of their systems have become zombies. It appears that the + presence of non-trivial numbers of zombies in the global Internet is + now endemic, which makes distributed denial of service attacks a much + larger concern. So Internet threat models need to assume the + presence of such zombies in significant numbers. This makes the + design of protocols resilient in the presence of distributed denial + of service attacks very important to the health of the Internet. + Some work has been done on this front [Savage00], [MBFIPS01], but + more is needed. + +3.5. Network Management + + The Internet had early success in network device monitoring with the + Simple Network Management Protocol (SNMP) and its associated + Management Information Base (MIB). There has been comparatively less + success in managing networks, in contrast to the monitoring of + individual devices. Furthermore, there are a number of operator + requirements not well supported by the current Internet management + framework. It is desirable to enhance the current Internet network + management architecture to more fully support operational needs. + + Unfortunately, network management research has historically been very + underfunded. Operators have complained that existing solutions are + inadequate. Research is needed to find better solutions. + +3.5.1. Managing Networks, Not Devices + + At present there are few or no good tools for managing a whole + network instead of isolated devices. For example, the lack of + appropriate network management tools has been cited as one of the + major barriers to the widespread deployment of IP multicast [Diot00, + + + +Atkinson & Floyd Informational [Page 16] + +RFC 3869 Research Funding Recommendations August 2004 + + + SM03]. Current network management protocols, such as the Simple + Network Management Protocol (SNMP), are fine for reading status of + well-defined objects from individual boxes. Managing networks + instead of isolated devices requires the ability to view the network + as a large distributed system. Research is needed on scalable + distributed data aggregation mechanisms, scalable distributed event + correlation mechanisms, and distributed and dependable control + mechanisms. + + Applied research into methods of managing sets of networked devices + seems worthwhile. Ideally, such a management approach would support + distributed management, rather than being strictly centralized. + +3.5.2. Enhanced Monitoring Capabilities + + SNMP does not always scale well to monitoring large numbers of + objects in many devices in different parts of the network. An + alternative approach worth exploring is how to provide scalable and + distributed monitoring, not on individual devices, but instead on + groups of devices and the network-as-a-whole. This requires scalable + techniques for data aggregation and event correlation of network + status data originating from numerous locations in the network. + +3.5.3. Customer Network Management + + An open issue related to network management is helping users and + others to identify and resolve problems in the network. If a user + can't access a web page, it would be useful if the user could find + out, easily, without having to run ping and traceroute, whether the + problem was that the web server was down, that the network was + partitioned due to a link failure, that there was heavy congestion + along the path, that the DNS name couldn't be resolved, that the + firewall prohibited the access, or that some other specific event + occurred. + +3.5.4. Autonomous Network Management + + More research is needed to improve the degree of automation achieved + by network management systems and to localize management. Autonomous + network management might involve the application of control theory, + artificial intelligence or expert system technologies to network + management problems. + +3.6. Quality of Service + + There has been an intensive body of research and development work on + adding QoS to the Internet architecture for more than ten years now + [RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210], yet we still + + + +Atkinson & Floyd Informational [Page 17] + +RFC 3869 Research Funding Recommendations August 2004 + + + don't have end-to-end QoS in the Internet [RFC-2990, RFC-3387]. The + IETF is good at defining individual QoS mechanisms, but poor at work + on deployable QoS architectures. Thus, while Differentiated Services + (DiffServ) mechanisms have been standardized as per-hop behaviors, + there is still much to be learned about the deployment of that or + other QoS mechanisms for end-to-end QoS. In addition to work on + purely technical issues, this includes close attention to the + economic models and deployment strategies that would enable an + increased deployment of QoS in the network. + + In many cases, deployment of QoS mechanisms would significantly + increase operational security risks [RFC-2990], so any new research + on QoS mechanisms or architectures ought to specifically discuss the + potential security issues associated with the new proposal(s) and how + to mitigate those security issues. + + In some cases, the demand for QoS mechanisms has been diminished by + the development of more resilient voice/video coding techniques that + are better suited for the best-effort Internet than the older coding + techniques that were originally designed for circuit-switched + networks. + + One of the factors that has blunted the demand for QoS has been the + transition of the Internet infrastructure from heavy congestion in + the early 1990s, to overprovisioning in backbones and in many + international links now. Thus, research in QoS mechanisms also has + to include some careful attention to the relative costs and benefits + of QoS in different places in the network. Applied research into QoS + should include explicit consideration of economic issues of deploying + and operating a QoS-enabled IP network [Clark02]. + +3.6.1. Inter-Domain QoS Architecture + + Typically, a router in the deployed inter-domain Internet provides + best-effort forwarding of IP packets, without regard for whether the + source or destination of the packet is a direct customer of the + operator of the router. This property is a significant contributor + to the current scalability of the global Internet and contributes to + the difficulty of deploying inter-domain Quality of Service (QoS) + mechanisms. + + Deploying existing Quality-of-Service (QoS) mechanisms, for example + Differentiated Services or Integrated Services, across an inter- + domain boundary creates a significant and easily exploited denial-of- + service vulnerability for any network that provides inter-domain QoS + support. This has caused network operators to refrain from + supporting inter-domain QoS. The Internet would benefit from + + + + +Atkinson & Floyd Informational [Page 18] + +RFC 3869 Research Funding Recommendations August 2004 + + + additional research into alternative approaches to QoS, particularly + into approaches that do not create such vulnerabilities and can be + deployed end-to-end [RFC-2990]. + + Also, current business models are not consistent with inter-domain + QoS, in large part because it is impractical or impossible to + authenticate the identity of the sender of would-be preferred traffic + while still forwarding traffic at line-rate. Absent such an ability, + it is unclear how a network operator could bill or otherwise recover + costs associated with providing that preferred service. So any new + work on inter-domain QoS mechanisms and architectures needs to + carefully consider the economic and security implications of such + proposals. + +3.6.2. New Queuing Disciplines + + The overall Quality-of-Service for traffic is in part determined by + the scheduling and queue management mechanisms at the routers. While + there are a number of existing mechanisms (e.g., RED) that work well, + it is possible that improved active queuing strategies might be + devised. Mechanisms that lowered the implementation cost in IP + routers might help increase deployment of active queue management, + for example. + +3.7. Congestion Control. + + TCP's congestion avoidance and control mechanisms, from 1988 + [Jacobson88], have been a key factor in maintaining the stability of + the Internet, and are used by the bulk of the Internet's traffic. + However, the congestion control mechanisms of the Internet need to be + expanded and modified to meet a wide range of new requirements, from + new applications such as streaming media and multicast to new + environments such as wireless networks or very high bandwidth paths, + and new requirements for minimizing queueing delay. While there are + significant bodies of work in several of these issues, considerably + more needs to be done. + + We would note that research on TCP congestion control is also not yet + "done", with much still to be accomplished in high-speed TCP, or in + adding robust performance over paths with significant reordering, + intermittent connectivity, non-congestive packet loss, and the like. + + Several of these issues bring up difficult fundamental questions + about the potential costs and benefits of increased communication + between layers. Would it help transport to receive hints or other + information from routing, from link layers, or from other transport- + level connections? If so, what would be the cost to robust operation + across diverse environments? + + + +Atkinson & Floyd Informational [Page 19] + +RFC 3869 Research Funding Recommendations August 2004 + + + For congestion control mechanisms in routers, active queue management + and Explicit Congestion Notification are generally not yet deployed, + and there are a range of proposals, in various states of maturity, in + this area. At the same time, there is a great deal that we still do + not understand about the interactions of queue management mechanisms + with other factors in the network. Router-based congestion control + mechanisms are also needed for detecting and responding to aggregate + congestion such as in Distributed Denial of Service attacks and flash + crowds. + + As more applications have the need to transfer very large files over + high delay-bandwidth-product paths, the stresses on current + congestion control mechanisms raise the question of whether we need + more fine-grained feedback from routers. This includes the challenge + of allowing connections to avoid the delays of slow-start, and to + rapidly make use of newly-available bandwidth. On a more general + level, we don't understand the potential and limitations for best- + effort traffic over high delay-bandwidth-product paths, given the + current feedback from routers, or the range of possibilities for more + explicit feedback from routers. + + There is also a need for long-term research in congestion control + that is separate from specific functional requirements like the ones + listed above. We know very little about congestion control dynamics + or traffic dynamics of a large, complex network like the global + Internet, with its heterogeneous and changing traffic mixes, link- + level technologies, network protocols and router mechanisms, patterns + of congestion, pricing models, and the like. Expanding our knowledge + in this area seems likely to require a rich mix of measurement, + analysis, simulations, and experimentation. + +3.8. Studying the Evolution of the Internet Infrastructure + + The evolution of the Internet infrastructure has been frustratingly + slow and difficult, with long stories about the difficulties in + adding IPv6, QoS, multicast, and other functionality to the Internet. + We need a more scientific understanding of the evolutionary + potentials and evolutionary difficulties of the Internet + infrastructure. + + This evolutionary potential is affected not only by the technical + issues of the layered IP architecture, but by other factors as well. + These factors include the changes in the environment over time (e.g., + the recent overprovisioning of backbones, the deployment of + firewalls), and the role of the standardization process. Economic + and public policy factors are also critical, including the central + fact of the Internet as a decentralized system, with key players + being not only individuals, but also ISPs, companies, and entire + + + +Atkinson & Floyd Informational [Page 20] + +RFC 3869 Research Funding Recommendations August 2004 + + + industries. Deployment issues are also key factors in the evolution + of the Internet, including the continual chicken-and-egg problem of + having enough customers to merit rolling out a service whose utility + depends on the size of the customer base in the first place. + + Overlay networks might serve as a transition technology for some new + functionality, with an initial deployment in overlay networks, and + with the new functionality moving later into the core if it seems + warranted. + + There are also increased obstacles to the evolution of the Internet + in the form of increased complexity [WD02], unanticipated feature + interactions [Kruse00], interactions between layers [CWWS92], + interventions by middleboxes [RFC-3424], and the like. Because + increasing complexity appears inevitable, research is needed to + understand architectural mechanisms that can accommodate increased + complexity without decreasing robustness of performance in unknown + environments, and without closing off future possibilities for + evolution. More concretely, research is needed on how to evolve the + Internet will still maintaining its core strengths, such as the + current degree of global addressability of hosts, end-to-end + transparency of packet forwarding, and good performance for best- + effort traffic. + +3.9. Middleboxes + + Research is needed to address the challenges posed by the wide range + of middleboxes [RFC-3234]. This includes issues of security, + control, data integrity, and on the general impact of middleboxes on + the architecture. + + In many ways middleboxes are a direct outgrowth of commercial + interests, but there is a need to look beyond the near-term needs for + the technology, to research its broader implications and to explore + ways to improve how middleboxes are integrated into the architecture. + +3.10. Internet Measurement + + A recurring challenge is measuring the Internet; there have been many + discussions about the need for measurement studies as an integral + part of Internet research [Claffy03]. In this discussion, we define + measurement quite broadly. For example, there are numerous + challenges in measuring performance along any substantial Internet + path, particularly when the path crosses administrative domain + boundaries. There are also challenges in measuring + protocol/application usage on any high-speed Internet link. Many of + + + + + +Atkinson & Floyd Informational [Page 21] + +RFC 3869 Research Funding Recommendations August 2004 + + + the problems discussed above would benefit from increased frequency + of measurement as well as improved quality of measurement on the + deployed Internet. + + A key issue in network measurement is that most commercial Internet + Service Providers consider the particular characteristics of their + production IP network(s) to be trade secrets. Ways need to be found + for cooperative measurement studies, e.g., to allow legitimate non- + commercial researchers to be able to measure relevant network + parameters while also protecting the privacy rights of the measured + ISPs. + + Absent measured data, there is possibly an over-reliance on network + simulations in some parts of the Internet research community and + probably insufficient validation that existing network simulation + models are reasonably good representations of the deployed Internet + (or of some plausible future Internet) [FK02]. + + Without solid measurement of the current Internet behavior, it is + very difficult to know what otherwise unknown operational problems + exist that require attention, and it is equally difficult to fully + understand the impact of changes (past or future) upon the Internet's + actual behavioral characteristics. + +3.11. Applications + + Research is needed on a wide range of issues related to Internet + applications. + + Taking email as one example application, research is needed on + understanding the spam problem, and on investigating tools and + techniques to mitigate the effects of spam, including tools and + techniques that aid the implementation of legal and other non- + technical anti-spam measures [ASRG]. "Spam" is a generic term for a + range of significantly different types of unwanted bulk email, with + many types of senders, content and traffic-generating techniques. As + one part of controlling spam, we need to develop a much better + understanding of its many, different characteristics and their + interactions with each other. + +3.12. Meeting the Needs of the Future + + As network size, link bandwidth, CPU capacity, and the number of + users all increase, research will be needed to ensure that the + Internet of the future scales to meet these increasing demands. We + have discussed some of these scaling issues in specific sections + above. + + + + +Atkinson & Floyd Informational [Page 22] + +RFC 3869 Research Funding Recommendations August 2004 + + + However, for all of the research questions discussed in this + document, the goal of the research must be not only to meet the + challenges already experienced today, but also to meet the challenges + that can be expected to emerge in the future. + +3.13. Freely Distributable Prototypes + + U.S.'s DARPA has historically funded development of freely + distributable implementations of various Internet technologies (e.g., + TCP/IPv4, RSVP, IPv6, and IP security) in a variety of operating + systems (e.g., 4.2 BSD, 4.3 BSD, 4.4 BSD, Tenex). Experience has + shown that a good way to speed deployment of a new technology is to + provide an unencumbered, freely-distributable prototype that can be + incorporated into commercial products as well as non-commercial + prototypes. Japan's WIDE Project has also funded some such work, + primarily focused on IPv6 implementation for 4.4 BSD and Linux. + [WIDE] We believe that applied research projects in networking will + have an increased probability of success if the research project + teams make their resulting software implementations freely available + for both commercial and non-commercial uses. Examples of successes + here include the DARPA funding of TCP/IPv4 integration into the 4.x + BSD operating system [MBKQ96], DARPA/USN funding of ESP/AH design and + integration into 4.4 BSD [Atk96], as well as separate DARPA/USN and + WIDE funding of freely distributable IPv6 prototypes [Atk96, WIDE]. + +4. Conclusions + + This document has summarized the history of research funding for the + Internet and highlighted examples of open research questions. The + IAB believes that more research is required to further the evolution + of the Internet infrastructure, and that consistent, sufficient non- + commercial funding is needed to enable such research. + + In case there is any confusion, in this document we are not + suggesting any direct or indirect role for the IAB, the IETF, or the + IRTF in handling any funding for Internet research. + +5. Acknowledgements + + The people who directly contributed to this document in some form + include the following: Ran Atkinson, Guy Almes, Rob Austein, Vint + Cerf, Jon Crowcroft, Sally Floyd, James Kempf, Joe Macker, Craig + Partridge, Vern Paxson, Juergen Schoenwaelder, and Mike St. Johns. + + We are also grateful to Kim Claffy, Dave Crocker, Michael Eder, Eric + Fleischman, Andrei Gurtov, Stephen Kent, J.P. Martin-Flatin, and + Hilarie Orman for feedback on earlier drafts of this document. + + + + +Atkinson & Floyd Informational [Page 23] + +RFC 3869 Research Funding Recommendations August 2004 + + + We have also drawn from the following reports: + [CIPB02,IST02,NV02,NSF02,NSF03,NSF03a]. + +6. Security Considerations + + This document does not itself create any new security issues for the + Internet community. Security issues within the Internet Architecture + primarily are discussed in Section 3.4 above. + +7. Informative References + + [ASRG] Anti-Spam Research Group (ASRG) of the IRTF. URL + "http://asrg.sp.am/". + + [Atk96] R. Atkinson et al., "Implementation of IPv6 in 4.4 + BSD", Proceedings of USENIX 1996 Annual Technical + Conference, USENIX Association, Berkeley, CA, USA. + January 1996. URL + http://www.chacs.itd.nrl.navy.mil/publications/CHACS/ + 1996/1996atkinson-USENIX.pdf + + [Bellman1957] R.E. Bellman, "Dynamic Programming", Princeton + University Press, Princeton, NJ, 1957. + + [Claffy03] K. Claffy, "Priorities and Challenges in Internet + Measurement, Simulation, and Analysis", Large Scale + Network meeting, (US) National Science Foundation, + Arlington, VA, USA. 10 June 2003. URL + "http://www.caida.org/outreach/ + presentations/2003/lsn20030610/". + + [Claffy03a] K. Claffy, "Top Problems of the Internet and What + Sysadmins and Researchers Can Do To Help", plenary talk + at LISA'03, October 2003. URL + "http://www.caida.org/outreach/presentations/ + 2003/netproblems_lisa03/". + + [Clark02] D. D. Clark, "Deploying the Internet - why does it take + so long and, can research help?", Large-Scale + Networking Distinguished Lecture Series, (U.S.) + National Science Foundation, Arlington, VA, 8 January + 2002. URL: http://www.ngi- + supernet.org/conferences.html + + + + + + + + +Atkinson & Floyd Informational [Page 24] + +RFC 3869 Research Funding Recommendations August 2004 + + + [CSTB99] Computer Science and Telecommunications Board, (U.S.) + National Research Council, "Funding a Revolution: + Government Support for Computing Research", National + Academy Press, Washington, DC, 1999. URL + "http://www7.nationalacademies.org/cstb/ + pub_revolution.html". + + [CIPB02] Critical Infrastructure Protection Board, "National + Strategy to Secure Cyberspace", The White House, + Washington, DC, USA. September 2002, URL + "http://www.whitehouse.gov/pcipb". + + [CWWS92] J. Crowcroft, I. Wakeman, Z. Wang, and D. Sirovica, "Is + Layering Harmful?", IEEE Networks, Vol. 6, Issue 1, pp + 20-24, January 1992. + + [Diot00] C. Diot, et al., "Deployment Issues for the IP + Multicast Service and Architecture", IEEE Network, + January/February 2000. + + [Deering1988] S. Deering, "Multicast Routing in Internetworks and + LANs", ACM Computer Communications Review, Volume 18, + Issue 4, August 1988. + + [Dijkstra59] E. Dijkstra, "A Note on Two Problems in Connexion with + Graphs", Numerische Mathematik, 1, 1959, pp.269-271. + + [FF1962] L. R. Ford Jr. and D.R. Fulkerson, "Flows in Networks", + Princeton University Press, Princeton, NJ, 1962. + + [FK02] S. Floyd and E. Kohler, "Internet Research Needs Better + Models", Proceedings of 1st Workshop on Hot Topics in + Networks (Hotnets-I), Princeton, NJ, USA. October + 2002. URL + "http://www.icir.org/models/bettermodels.html". + + [IM1993] J. Ioannidis and G. Maguire Jr., "The Design and + Implementation of a Mobile Internetworking + Architecture", Proceedings of the Winter USENIX + Technical Conference, pages 489-500, Berkeley, CA, USA, + January 1993. + + [IST02] Research Networking in Europe - Striving for Global + Leadership, Information Society Technologies, 2002. + URL "http://www.cordis.lu/ist/rn/rn-brochure.htm". + + + + + + +Atkinson & Floyd Informational [Page 25] + +RFC 3869 Research Funding Recommendations August 2004 + + + [Jacobson88] Van Jacobson, "Congestion Avoidance and Control", + Proceedings of ACM SIGCOMM 1988 Symposium, ACM SIGCOMM, + Stanford, CA, August 1988. URL + "http://citeseer.nj.nec.com/jacobson88congestion.html". + + [Jackson02] William Jackson, "U.S. should fund R&D for secure + Internet protocols, Clarke says", Government Computer + News, 31 October 2002. URL + "http://www.gcn.com/vol1_no1/security/20382-1.html". + + [Kruse00] Hans Kruse, "The Pitfalls of Distributed Protocol + Development: Unintentional Interactions between Network + Operations and Applications Protocols", Proceedings of + the 8th International Conference on Telecommunication + Systems Design, Nashville, TN, USA, March 2000. URL + "http://www.csm.ohiou.edu/kruse/publications/ + TSYS2000.pdf". + + [KLMS2000] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure + Border Gateway Protocol (S-BGP)", Proceedings of ISOC + Network and Distributed Systems Security Symposium, + Internet Society, Reston, VA, February 2000. + + [LD2002] E. Lear and R. Droms, "What's in a Name: Thoughts from + the NSRG", expired Internet-Draft, December 2002. + + [MBFIPS01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John + Ioannidis, Vern Paxson, and Scott Shenker, "Controlling + High Bandwidth Aggregates in the Network", ACM Computer + Communications Review, Vol. 32, No. 3, July 2002. URL + "http://www.icir.org/pushback/". + + [MBKQ96] M. McKusick, K. Bostic, M. Karels, and J. Quarterman, + "Design and Implementation of the 4.4 BSD Operating + System", Addison-Wesley, Reading, MA, 1996. + + [MGVK02] Z. Mao, R. Govindan, G. Varghese, & R. Katz, "Route + Flap Dampening Exacerbates Internet Routing + Convergence", Proceedings of ACM SIGCOMM 2002, ACM, + Pittsburgh, PA, USA, August 2002. + + [NV02] NetVision 2012 Committee,"DARPA's Ten-Year Strategic + Plan for Networking Research", (U.S.) Defense Advanced + Research Projects Agency, October 2002. Citation for + acknowledgement purposes only. + + + + + + +Atkinson & Floyd Informational [Page 26] + +RFC 3869 Research Funding Recommendations August 2004 + + + [NSF02] NSF Workshop on Network Research Testbeds, National + Science Foundation, Directorate for Computer and + Information Science & Engineering, Advanced Networking + Infrastructure & Research Division, Arlington, VA, USA, + October 2002. URL "http://www- + net.cs.umass.edu/testbed_workshop/". + + [NSF03] NSF ANIR Principal Investigator meeting, National + Science Foundation, Arlington, VA, USA. January 9-10, + 2003, URL "http://www.ncne.org/training/nsf- + pi/2003/nsfpimain.html". + + [NSF03a] D. E. Atkins, et al., "Revolutionizing Science and + Engineering Through Cyberinfrastructure", Report of NSF + Advisory Panel on Cyberinfrastructure, January 2003. + URL "http://www.cise.nsf.gov/evnt/reports/ + atkins_annc_020303.htm". + + [NSF03b] Report of the National Science Foundation Workshop on + Fundamental Research in Networking. April 24-25, 2003. + URL "http://www.cs.virginia.edu/~jorg/workshop1/NSF- + NetWorkshop-2003.pdf". + + [Floyd] S. Floyd, "Papers about Research Questions for the + Internet", web page, ICSI Center for Internet Research + (ICIR), Berkeley, CA, 2003 URL + "http://www.icir.org/floyd/research_questions.html". + + [RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September 1993. + + [RFC-1633] Braden, R., Clark, D., and S. Shenker, "Integrated + Services in the Internet Architecture: an Overview", + RFC 1633, June 1994. + + [RFC-2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", + RFC 2082, January 1997. + + [RFC-2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + Services", RFC 2210, September 1997. + + [RFC-2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with + Digital Signatures", RFC 2154, June 1997. + + [RFC-2385] Heffernan, A., "Protection of BGP Sessions via the TCP + MD5 Signature Option", RFC 2385, August 1998. + + + + + +Atkinson & Floyd Informational [Page 27] + +RFC 3869 Research Funding Recommendations August 2004 + + + [RFC-2407] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [RFC-2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking + (MANET): Routing Protocol Performance Issues and + Evaluation Considerations", RFC 2501, January 1999. + + [RFC-2990] Huston, G., "Next Steps for the IP QoS Architecture", + RFC 2990, November 2000. + + [RFC-3221] Huston, G., "Commentary on Inter-Domain Routing in the + Internet", RFC 3221, December 2001. + + [RFC-3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and + Issues", RFC 3234, February 2002. + + [RFC-3424] Daigle, L. and IAB, "IAB Considerations for UNilateral + Self-Address Fixing (UNSAF) Across Network Address + Translation", RFC 3424, November 2002. + + [RFC-3467] Klensin, J., "Role of the Domain Name System (DNS)", + RFC 3467, February 2003. + + [RFC-3535] Schoenwaelder, J., "Overview of the 2002 IAB Network + Management Workshop", RFC 3535, May 2003. + + [RFC-3387] Eder, M., Chaskar, H., and S. Nag, "Considerations from + the Service Management Research Group (SMRG) on Quality + of Service (QoS) in the IP Network", RFC 3387, + September 2002. + + [RIPE] RIPE (Reseaux IP Europeens), Amsterdam, NL. URL + "http://www.ripe.net/ripe/". + + [Savage00] Savage, S., Wetherall, D., Karlink, A. R., and + Anderson, T., "Practical Network Support for IP + Traceback", Proceedings of 2000 ACM SIGCOMM Conference, + ACM SIGCOMM, Stockholm, SE, pp. 295-306. August 2000. + + [Schiller03] J. I. Schiller, "Interception Technology: The Good, The + Bad, and The Ugly!", Presentation at 28th NANOG + Meeting, North American Network Operators Group + (NANOG), Ann Arbor, MI, USA, June 2003. URL + "http://www.nanog.org/mtg-0306/schiller.html". + + + + + + + +Atkinson & Floyd Informational [Page 28] + +RFC 3869 Research Funding Recommendations August 2004 + + + [SM03] P. Sharma and R. Malpani, "IP Multicast Operational + Network Management: Design, Challenges, and + Experiences", IEEE Network, Vol. 17, No. 2, March + 2003. + + [SMA03] N. Spring, R. Mahajan, & T. Anderson, "Quantifying the + Causes of Path Inflation", Proceedings of ACM SIGCOMM + 2003, ACM, Karlsruhe, Germany, August 2003. + + [WD02] Walter Willinger and John Doyle, "Robustness and the + Internet: Design and Evolution", Unpublished/Preprint, + 1 March 2002, URL + "http://netlab.caltech.edu/internet/". + + [WIDE] WIDE Project, Japan. URL "http://www.wide.ad.jp/". + +8. Authors' Addresses + + Internet Architecture Board + EMail: iab@iab.org + + Internet Architecture Board Members + at the time this document was published were: + + Bernard Aboba + Harald Alvestrand (IETF chair) + Rob Austein + Leslie Daigle (IAB chair) + Patrik Faltstrom + Sally Floyd + Mark Handley + Bob Hinden + Geoff Huston (IAB Executive Director) + Jun-ichiro Itojun Hagino + Eric Rescorla + Pete Resnick + Jonathan Rosenberg + + We note that Ran Atkinson, one of the editors of the document, was an + IAB member at the time that this document was first created, in + November 2002, and that Vern Paxson, the IRTF chair, is an ex-officio + member of the IAB. + + + + + + + + + +Atkinson & Floyd Informational [Page 29] + +RFC 3869 Research Funding Recommendations August 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Atkinson & Floyd Informational [Page 30] + |