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
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.
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.
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].
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.
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
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,
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
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
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?
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