Functional and Operational Priorities for a New Network Architecture by Kevin Fall, Intel Research, Berkeley kfall@intel.com It has recently become fashionable among researchers to 're-design' the Internet. The driving factors behind this motivation are based on some general sense that the current Internet is inadequate in one or more ways. I would like to discuss these, from the user, enterprise manager and large operator perspective. Without significant value being offered to these communities, a clean slate Internet design is likely to remain an academic exercise. Furthermore, without buy-in from these communities, large government investment in testbeds is of dubious value outside the pure research realm. Users: For users, some of the major problems are: difficulty in handling the volume of traffic (e.g. SPAM), determining what data is legitimate (e.g. Phishing/Pharming), being able to use the network under a wide variety of circumstances using a wide variety of devices (e.g. phones in cars, laptops on trains, computers in remote villages with satellite connectivity), and dermining what went wrong during failures or errors. End-node security needs to be explored in addition to in-network analysis for many of these problems. Approaches involving limited execution address spaces (e.g. not executing from stack segments) and code diversity (e.g. different executables in different OS variants) are a start. Network researchers should also become more aware of the work on trusted platforms (and TPMs) so as to ensure proposed capabilities mesh well with future networking plans and are considered acceptable from a privacy perspective. Many networking approaches to "security" are not adequate-- simply authenticating the sender of a message does not suffice. Security of data being processed is needed, leading to a more general requirement for "data provenance" which resembles current work on so-called 'data-centric' or 'data-oriented' architectural proposals. This includes the ability to verifiably track modifications to data. Our protocols and infrastructure inherit a strong "continuously connected" abstraction, based on the telephone network legacy and captured in IP. This is violated today in two ways. First, there are portions of the world where even connectivity infrastructure does not maintain continuous connectivity for extended periods of time for a variety of reasons (poor power, cables, weather, maintenance, configuration, congestion). Second, the potentially billions of portable Internet devices available in the next decade are moved around regularly, between regions of connectivity and non-connectivity. Future equivalents of the routing, transport, and session layers will need to handle these circumstances. Unfortunately, current testbed directions (at least in the US) indicate no plan to incorporate assets such as satellites, which would stress these capabilities. Failures and errors are beyond diagnosis for most users. This is related to the lack of tools available in combination with the considerable skill required to operate those that do exist. Protocols such as the venerable ICMP used to provide at least the basis for fault diagnosis, but this information is now typically blocked due to security problems. A future signaling protocol (beyond connection setup like SIP or resource reservation) should be both secure and rich and span layers down to the physical layer (relevant for capabilities such as quantum cryptography and lambda switching). This would help users and others to understand how the network is behaving. Challenges abound: identifying the principals of the communication, how to cross-correlate such messages with error conditions, and determining what is legitimate. Enterprise: Enterprises include commercial and non-commerical organizations. Some enterprises (govt, military) have particular needs that are not as common commercially, but may become so (e.g. E911, secure time and location services -- there is no compelling reason why systems such as GPS shouldn't be considered part of the Internet). Enterprises are often concerned with "information assurance". Although this term is more common in the military, it has expanded to include not only traditional security issues (authentication/privacy) but also reliability and availability and audit. There are many well-known issues here that do not have well-known solutions. For example, current state-of-the-art for Internet security monitoring involves pattern recognition, both in terms of packet payload as well as traffic (volume) anomaly detection. These approaches are difficult in general-- network middleboxes need to deal with protocols not designed to have their payload interrogated (e.g. TCP, with variable segment sizes) and distributed anomaly detection is probabilistic by nature and may require centralized computation on large data sets. While simple means (source filtering) help security, this has deployment hurdles because the benefits are not immediately delivered to the party paying the cost of implementing such filtering {this is also a more general issue in the commercial Internet}. Other schemes (tokens or capabilities) share the problem of how to effectively distribute capabilities without distributing them to undesirable parties. With respect to configuration, many network devices require IP addresses for identification. This relates to the general issue of "ID/locator" overloading with conventional IP and how address space and routing are handled. Enterprises generally wish to have multiple network attachment points (for availability reasons), wish to have some say in how their traffic is routed, and are required to support a potentially large number of remote users. 'Policies' applied to these situations are generally described in low-level language (e.g. Cisco router configurations), rather than an an intuitive level. There are some efforts at addressing this issue (algebras, P2, etc). Further research is needed here to come to agreement on how policies can be manipulated and verified. Operators: operators are faced with providing an increasingly-commoditized basic service, in combination with competing in an expanding and increasingly lucrative service market. As their business depends on factors such as performance and RoI, they are concerned with scalability, deployment, and utilization of existing infrastructure. There is a current concern that the existing routing system will ultimately need to be "fixed", and this represents a huge challenge, requiring talent from wherever it is available. Scalability concerns include routing table size growth and high update rates, and simply forwarding traffic at ever-increasing speeds. Given the current use of aggregated network prefixes as policy units, de-aggregation is forced in order to have finer grained traffic engineering control. There is a fundamental tension: aggregation for scalability versus de-aggregation for individual traffic control, multi-homing, mobility, and the desire for fixed identifiers. Most proposals in this area do not really solve the problem, but rather shift it (e.g. from the forwarding plane to DNS). Routing approaches that have nice theoretical bounds (e.g. compact routing) do not necessarily have nice update properties, and those that do often lack theoretical bounds.