Securing the Routing System at All Levels
-----------------------------------------
The Internet routing system is extremely vulnerable to accidental
misconfiguration and malicious attack, with serious consequences 
for the security and robustness of the infrastructure.  A simple
configuration mistake in one Autonomous System (AS) can, and sometimes
does, have cause global consequences.  Malicious parties can, and
sometimes do, introduce bogus information into the Border Gateway
Protocol (BGP) to intercept data traffic or disrupt end-to-end 
communication.  An adversary controlling a router along the path
between two hosts could easily drop packets or redirect traffic along
a different path.  Detecting and fixing these kinds of problems is
notoriously difficult, and preventing them from happening is even harder.

Network management tools offer incremental approaches to addressing
these problems.  For example, documenting (and following) best common
practices for securing access to routers and for configuring the
routing protocols can reduce the likelihood and effectiveness of
malicious attacks.  Tools for configuration checking and automated
configuration reduce the likelihood of accidental errors that disrupt
the routing system or leave an AS open to attack.  Monitoring systems
that capture and analyze the routing-protocol messages can help
operators detect anomalies, such as hijacked prefixes or routing
leaks, to enable a faster response to security breaches.  However,
these network-management techniques do not provide a complete defense,
since they do not get at two main issues at the heart of the problem:

  * Today's routing protocols were designed with an implicit assumption 
    of trust, in direct conflict with the operational reality of
    configuration errors and malicious adversaries.  For example, BGP
    assumes that an AS advertising a destination prefix is entitled to
    do so, and that the AS-path attribute is an accurate reflection of
    the sequence of ASes that propagated the route advertisement, and
    the sequence of ASes that the data packets will ultimately follow.  

  * Secure and robust routing depends not only on the routing protocol
    (operating in the control plane on the individual routers), but
    also on the data plane (that forwards packets) and the management
    plane (that configures and monitors the data and control planes).
    Most research and standardization activity on secure routing has
    focused exclusively on the control plane, whereas a complete 
    solution must ultimately span all three layers.

A clean-slate redesign of the Internet would allow a refactoring of
functionality across the layers, or even the creation of new and
different layers, with security in mind.  For example, rather than
proposing incremental fixes to make the control plane more secure, 
you could imagine largely *removing* the control plane in each AS,
reducing the individual routers to merely (i) forwarding data traffic
(under the direct control of the management system for the AS) and (ii) 
providing measurement data (to give the management system an accurate,
real-time view of the topology and traffic) [1,2].  With a "wafer-thin" 
control plane, each router would communicate only with the AS's management 
system, in a secure fashion, and would have no other control-plane
configuration state.  This approach would essentially replace today's
intra-AS routing protocols (such as OSPF/IS-IS and internal BGP) with
a secure, distributed, real-time network-management system that computes 
forwarding-table entries and installs them in the data plane of the
routers.  The management system becomes the single place where the
AS's policy, security, and performance goals are specified and enforced.

A redesign should give careful consideration to the mechanisms needed
to make the inter-AS routing more secure.  A new inter-AS protocol
running between the network-management servers could support a wide
variety of routing architectures.  For example, cooperating ASes could
work together to detect and diagnose routing anomalies, perhaps drawing 
on historical measurement data and the trust relationships between
groups of ASes [3].  Or, third-party servers could compute and install
end-to-end forwarding state on behalf of end users [4], based on
routing and performance data provided by each AS.  For any of these
schemes, having data-plane mechanisms to verify that the data packets
actually follow a suitable end-to-end path is crucial.  For example,
the data plane could include a secure active probing mechanism [5] that
detects whether the end-to-end forwarding path is functional, even if
an adversary provides misleading routing information.  New techniques
could be designed to verify that the data packets traverse the advertised 
path, or some path that satisfies the users' policy, security, and 
performance requirements.

[1] J. Rexford, A. Greenberg, G. Hjalmtysson, D. Maltz, A. Myers, 
    G. Xie, J. Zhan, and H. Zhang, "Network-wide decision making: 
    Toward a wafer-thin control plane," Proc. ACM SIGCOMM HotNets 
    Workshop, November 2004.
      http://www.cs.princeton.edu/~jrex/papers/cmu-hotnets04.pdf

[2] A. Greenberg, G. Hjalmtysson, D. Maltz, A. Myers, J. Rexford,
    G. Xie, H. Yan, J. Zhan, and H. Zhang, "Refactoring network
    control and management: A case for the 4D architecture," CMU
    Technical Report, February 2005.
      http://www.cs.princeton.edu/~jrex/papers/4D-report.pdf

[3] H. Yu, J. Rexford, and E. Felten, "A distributed reputation
    approach to cooperative Internet routing protection," June 2005.
     http://www.cs.princeton.edu/~harlanyu/papers/DistRepIR05.pdf

[4] K. Lakshminarayanan, I. Stoica, and S. Shenker, "Routing as a 
    service," UCB Technical Report UCB/CSD-04-1327, January 2004.
      http://www.cs.berkeley.edu/~karthik/research/papers/csd-04-1327.pdf

[5] I. Avramopoulos and J. Rexford, "Stealth probing: Securing IP 
    routing through data-plane security," Princeton University
    Technical Report TR-730-05, June 2005. 
      http://www.cs.princeton.edu/research/techreps/TR-730-05