Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 26
2 Public Telephone Network and Internet Trustworthiness The public telephone network (PTN) and the Internet are both large NISs. Studying their trustworthiness thus gives insight into the technical problems associated with supporting trustworthiness in an NIS. Identify- ing the vulnerabilities in these networks is also valuable any NIS is likely to employ one or both of these networks for its communication and could inherit those vulnerabilities. In some ways, the Internet and PTN are very similar. No single entity owns, manages, or can even have a complete picture of either. · The PTN in the United States comprises five distinct regional Bell operating companies and a large number of independent local telephone companies, all interconnected by long-distance providers.] · The U.S. portion of the Internet consists of a few major Internet service providers (ISPs) along with a much larger number of local or regional network providers, sometimes referred to as downstream ser- vice providers (DSPs). The ISPs are interconnected, either by direct links or by using network access points distributed around the country. · Both networks involve large numbers of subsystems operated by different organizations. The number and intricate nature of the interfaces that exist at the boundaries of these subsystems are one source of com- plexity for these networks. The increasing popularity of advanced ser . · . VlCeS IS a secona source. 1Additional consolidation among the regional operating companies remains a real possi- bility; at the same time, pressure for competition in the local telephone market will prob- ably increase the number of major players. 26

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 27 The vulnerabilities of the PTN and Internet are exacerbated by the dependence of each network on the other. Much of the Internet uses leased telephone lines as its physical transport medium. Conversely, telephone companies rely on networked computers to manage their own facilities, increasingly employing Internet technology, although not nec- essarily the Internet itself. Thus, vulnerabilities in the PTN can affect the Internet, and vulnerabilities in Internet technology can affect the tele- phone network. This chapter, a study of vulnerabilities in the PTN and the Internet, has three parts. The first discusses the design and operation of both networks. The second examines environmental disruption, operational errors, hardware and software design and implementation errors, and malicious attacks as they apply to the networks. Finally, the chapter concludes by analyzing two emerging issues: Internet telephony and the expanding use of the Internet by business. NETWORK DESIGN The Public Telephone Network Network Services and Design The PTN has evolved considerably over the past decades. It is no longer simply a network comprising a set of linked telephone switches, many of which are connected by copper wires to each and every tele- phone instrument in the country. There are now many telephone compa- nies that provide advanced services, such as toll-free numbers, call for- warding, network-based programmable call distribution, conference calling, and message delivery. The result is a network that is perhaps more flexible and responsive to customer needs but also more complex. The flexibility and complexity are sources of vulnerability. Some of the advanced services also have intrinsic vulnerabilities. With call forwarding, for example, a caller can unknowingly reach a number different from the one dialed. Consequently, a caller can no longer make assumptions about what number a call will reach, and the recipient no longer knows what number a caller is intending to reach. Havoc could result if an attacker modified the telephone network's data- base of forwarding destinations.2 As a second example, with network 2In one recent case, a plumber call forwarded his competitor's telephone number to his own, thereby gaining the callers' business without their knowledge of the deception. Call forwarding could also subvert the purpose of dial-back modems used for security. Here, the presumption is that only authorized users have access to certain telephone numbers.

OCR for page 26
28 TRUST IN CYBERSPACE based programmable call distribution, a voice menu greets callers and allows a company to direct its incoming calls according to capabilities in different offices, time zones, and so on. The menus and distribution criteria can be modified directly by the company and uploaded into a telephone network database. But, as with call forwarding, a database that can be modified by telephone network customers constitutes a potential vulnerability. The telephone network is made up of many different kinds of equip- ment that can be divided roughly into three major categories: signaling, transmission, and operations. Signaling equipment is used to set up and tear down calls. This category also includes databases and adjunct pro- cessors used for number translation and call routing. Transmission equip- ment carries the actual conversations. Operations equipment, including the operations support system (OSS), is used for provisioning, database updates, maintenance, billing, and the like. All communication between modern central-office switches takes place over a dedicated data network using protocols, such as Signaling System 7 (SS7), which the switches use to set up calls, establish who pays for the call, return busy signals, and so on. Such out-of-band signaling helps prevent fraud (such as the deceptions of the 1960s and 1970s made possible by the infamous "blue boxes," which sent network control tones over the voice path) and helps conserve resources (i.e., no voice path need ever be allocated if the target number is busy). However, out-of-band signaling does introduce new vulnerabilities.3 Failure of the signaling path can prevent completion of a call, even if there is an available route for the call itself. Authentication Authentication is a key part of any scheme for preventing unautho- rized activity. In a network containing programmable elements, authen- tication is an essential ingredient for protecting those elements from per When such users try to log in, the site calls them back. But the system has no way of knowing whether the person who answers the callback is really the authorized user, and call forwarding could cause the callback to be redirected. 3ss7 messages are carried over a mix of private and public X.25 (data) networks, providing out-of-band signaling. However, such networks, especially public ones, are subject to various forms of attacks. There is even a curious semicircularity here, since the X.25 interswitch trunks usually are provisioned from telephone company long-distance circuits, although not from the switched circuits that ss7 manages. Owing to deregulation designed to foster com- petition, telephone companies must allow essentially anyone to connect into ss7 networks for a modest fee ($10,000~. ss7 is a system that was designed for use by a closed community, and thus embodies minimal security safeguards. It is now employed by a much larger commu- nity, which makes the PIN subject to a broad range of "insider" attacks.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 29 forming actions illicitly requested by attackers. Specifically, in the PTN, the OSSs must be able to authenticate requests in order to control changes in the configuration of the elements constituting the network. In addi- tion, authentication is required to support certain advanced services, such as caller ID.4 To prevent caller ID from subversion, all elements in the path from the caller to the recipient must be authenticated. The need for authentication by OSSs is growing because interconnec- tions among previously isolated networks has increased the risk of exter- nal intrusions. As the PTN's management networks convert to the Trans- mission Control Protocol/Internet Protocol (TCP/IP) and are connected to other TCP/IP-based networks, ignoring authentication may prove di- sastrous. Historically, proprietary protocols and dedicated networks were used for the network's management, so knowledge of these was restricted to insiders, and there was little need for authentication or authorization of requests. The Internet Network Services and Design The Internet, a successor to the ARPANET (McQuillan and Walden, 1977), is a worldwide packet-switched computer-communications network. It interconnects two types of processors: hosts and routers. Hosts are the source and destination for all communications; routers5 forward packets received on one communications line to another and thereby implement a communication. A shared set of protocols and service architecture was designed to provide support for various forms of robust communication (e.g., e-mail, remote terminal access, file transfer, the World Wide Web) despite outages and congestion. Little design effort was devoted to resist- ing attacks, although subsequent Department of Defense research has done so. And the designers elected to eschew service guarantees in favor of providing service on a "best effort" basis. For example, the Internet Proto- col (IP), a datagram service used extensively by the Internet, does not guar- antee delivery and can deliver duplicates of messages.6 4Caller ID is an advanced service that identifies the originator of a telephone call to a suitably equipped receiver. As this service becomes more pervasive, it will be used more and more for identification and authentication by systems employing the telephone net- work for communications. Here, then, is a vulnerability that can propagate from a commu- nications fabric into an NIS that is built on top of that fabric. 5Routers sometimes act as hosts for purposes of network management and exchanging routing protocol messages. 6ISPs are now beginning to offer quality of service features E.g., using RSVPy, so the best- efforts notion of IF service may change over the next few years.

OCR for page 26
30 TRUST IN CYBERSPACE The Internet's protocols have proven remarkably tolerant to changes in the size of the network and to decades of order of magnitude improve- ments in communications bandwidth, communications speed, and pro- cessor capacity. In electing for "best effort" services, the Internet's de- signers made it easier for their protocols to tolerate outages of hosts, routers, and communications lines. Selecting the weaker service model also simplified dealing with router memory and processing capacity limi- tations. The Internet protocols were designed to operate over a range of network technologies being explored by the military in the 1970s from 56- kbps ARPANET trunks to 10-Mbps Ethernets and a mix of satellite and low-speed tactical packet radio networks. Despite two decades of net- work technology evolution, these protocols perform relatively well in today's Internet, which has a backbone and other communications lines that are far faster. Routing protocols in the Internet implement network-topology discov- ery, calculation of shortest routes, and recovery (i.e., alternate route selec- tion) from link and router outages. Initially, all of the Internet's routers were owned and operated by a single entity, making it reasonable to as- sume that all routers were executing compatible protocols and none would behave maliciously. But as the Internet matured, ownership and control of the routers became disbursed. More robust but less cooperative routing protocols were developed, thereby limiting the Internet's vulnerability to malicious and faulty routers. The Exterior Gateway Protocol (Mills, 1984) was originally employed for communication with routers outside an origi- nating domain; today, the Border Gateway Protocol (BGP) (Rekhter and Li, 1995; Rekhter and Gross, 1995; Traina, 1993, 1995) is used. A routing protocol must resolve the tension between (1) performance gains possible given information about the far reaches of the network and (2) increased vulnerability that such dependence can bring. By trusting information received from other domains, a router can calculate near- optimal routes, but such routes are useless if based on inaccurate informa- tion provided by malicious or malfunctioning routers. Conversely, re- stricting the information that routers share allows routing tables to be smaller, hence cheaper to compute, but sacrifices control over route qual- ity. Today's Internet routing protocols generally favor cost over route quality, but ISPs override this bias toward minimum hop routes in the context of interdomain routing.7 Communication in the Internet depends not only on the calculation of routing tables but also on the operation of the Domain Name Service 7ISPs use the local policy feature of the Border Gateway Protocol (BGP) to favor routes that might not be selected by BGP on a minimum-hop basis. This is necessary to balance traffic loads and to reduce vulnerability to configuration errors, or malicious attacks, on BGP.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 31 (DNS) (Mockapetris, 1987a,b). The most important function of this ser- vice is to map host names, such as , into numeric IP addresses. DNS also maps IP addresses into host names, defines inbound mail gateways, and so on. The name space implemented by DNS is tree structured. The top level has a handful of generic names (.COM, NET, .GOV, and the like)8 as well as two-letter names corresponding to Interna- tional Organization for Standardization (ISO) country codes (.US, .UK, .DE, .RU, and so forth). Definitive information for each level of the tree is maintained by a single master server; additional servers for a domain copy their information from it. Subtrees of the name space can be (and generally are) delegated to other servers. For example, .COM and NET currently reside by chance on the same server as do the root name servers; .US, though, is delegated. Individual sites or machines may cache re- cently retrieved DNS records; the intended lifetime of such cache entries is controlled by the source of the cached records. Network management tasks in the Internet are implemented using the Simple Network Management Protocol (SNMP) (Case et al., 1990~. SNMP itself is quite elementary it merely uses the User Datagrams Pro- tocol (UDP) to read and alter predefined parameters. These parameters, called management information bases (MIBs), are organized in a tree structure with branches representing MIB type, protocol structure, device type, and vendor. The hard task in managing a network is not the me- chanics of changing values of parameters; it is knowing what MIB vari- ables to set in order to effect some desired change in network behavior. SNMP provides no assistance here. Most of the deployed implementa- tions of SNMP also lack good security features, so the protocol has been used primarily to retrieve data from MIBs in managed devices, not to make changes to these MIBs. Instead, Telnet, a protocol that can be used with a variety of user authentication technologies, is often used for modi- fication of MIBs. The latest version (3) of SNMP promises to overcome these security limitations. Perhaps the most visible Internet service is the World Wide Web.9 The Web is implemented by servers that communicate with Web brows- ers (clients) using the Hypertext Transfer Protocol (HTTP) (Berners-Lee et al., 1996) to retrieve documents represented in Hypertext Markup Lan- guage (HTML) (Berners-Lee and Connolly, 1995~. HTML documents con ~At this time, there is an active debate over how many new top-level names to add and who should make the decisions. The outcome of this debate may change some of the details presented here; the overall structure, however, is likely to remain the same. Several of the generic top-level domain names are decidedly U.S.-centric. .MIL and .GOV are restricted to U.S. military and government organizations, and most of the entries in the .EDU domain are from the United States. 9Indeed, many think that the Web is the Internet.

OCR for page 26
32 TRUST IN CYBERSPACE lain data (text, images, audio, video, and so on), as well as uniform re- source locators (URLs) (Berners-Lee et al., 1994) to reference other HTML documents. An HTML document can be a file stored by a Web server or the output from a program, known as a common gateway interface (CGI) script, run by the Web server in response to a client request. CGI scripts, although not necessarily installed or managed by system administrators, are basically network servers accessible to Internet users. Bugs, therefore, can be a source of vulnerability. HTTP treats each client request as separate and independent. Thus, information about past interactions must be stored and retrieved explic- itly by the server in processing each request, usually an unnatural style of programming. The information can be stored by the client, as "cookies" (Kristol and Montulli, 1997) or as hidden fields in URLs and forms, or it can be stored by the server, or it can be stored as part of a secure socket layers (SSL) session index (if the HTTP session is being cryptographically protected). Observe that with the latter two schemes, the server's state becomes visible to the client and the client must implement any security. HTTP uses TCP and makes large numbers of short-lived TCP connec- tions (even between the same pairs of hosts). TCP, however, was de- signed to support comparatively long-lived connections. Web browsers thus cannot benefit from TCP's congestion-control algorithms (Stevens, 1997; Jacobson, 1988~. That means that the load imposed by the Web on the Internet's routers and communications lines not only is dispropor- tionately high but also reduces network throughput. Although HTTP 1.1 (Fielding et al., 1997) is mitigating this particular problem, it does exem- plify a broader concern: Deploying an application that does not match assumptions made by the Internet's designers can have a serious global impact on Internet performance. For implementing a trustworthy NIS, the Internet's "best effort" ser- vice semantics is probably not good enough. Bandwidth, latency, route diversity, and other quality of service (QOS) guarantees are likely to be needed by an NIS. Efforts are under way to correct this Internet defi- ciency. But accommodating QOS guarantees seems to require revisiting a fundamental architectural tenet of the Internet that intelligence and state exist only at the network's periphery. The problem is that, without add- ing state to routers (i.e., the "inside" of the network), the Internet's routers would lack a basis for processing some packets differently from others to enforce differing QOS guarantees. The most ambitious scheme to provide QOS guarantees in the Inter- net relies on the new Resource Reservation Protocol (RSVP) (Braden et al., 1997~. This protocol transmits bandwidth requests to the routers in a ~OAvailable on line at OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 33 communications path on a hop-by-hop basis. The receiver makes a re- quest of an adjacent router; that router, in turn, passes the request to its predecessor, and so on, until the sender is reached. (Special messages convey the proper path information to the receiver, and thence to each router.) The RSVP bandwidth requests feed the Internet's integrated ser- vices model (Shenker and Wroclawski, 1997) with parameters that in- clude bandwidth, latency, and maximum packet size. With RSVP, band- width reservations in routers are not permanent. They may be relinquished explicitly or, if not periodically refreshed, they expire. Note that RSVP reservations are not required for packets to flow. The term "soft state" has been coined for such saved information informa- tion whose loss may impair performance but does not disrupt functional correctness (i.e., the Internet's "best effort" semantics). The use of soft state in RSVP means that changes in toutings or the reboot of a router cannot cause a communications failure, and packets will continue to flow, albeit without performance guarantees. By periodically refreshing reser- vations, performance guarantees can be reactivated. Differentiated service, an alternative to RSVP for providing QOS in the Internet, employs bits in packet headers to indicate classes of service. Each class of service has associated service guarantees. The bits are in- spected at network borders, and each network is responsible for taking appropriate measures in order to satisfy the guarantees. Authentication (and other Security Protocols) Concern about strong and useable authentication in the Internet is relatively new. The original Internet application protocols used plaintext passwords for authentication, a mechanism that was adequate for casual log-ins but was insufficient for more sophisticated uses of a network, especially in a local area network environment. Rather than build proper cryptographic mechanisms which were little known in the civilian sec- tor at that time the developers of the early Internet software for UNIX resorted to network-based authentication for remote log-in and remote shell commands. The servers checked their clients' messages by convert- ing the sender's IP address into a host name. User names in such mes- sages are presumed to be authentic if the message comes from a host whose name is trusted by the server. Senders, however, can circumvent the check by misrepresenting their IP addressll (something that is more difficult with TCP). ~ . 1lA number of different attacks are known. They can be accomplished in a number of ways, such as sequence number guessing (Morris, 1985) or route corruption (Bellovin, 1989~. Alterna- tively, the attacker can target the address-to-name translation mechanism (Bellovin, 1995~.

OCR for page 26
34 TRUST IN CYBERSPACE But cryptographic protocols a sounder basis for network authenti- cation and security are now growing in prominence on the Internet. Link-layer encryption has been in use for many years. (See Box 2.1 for the names and descriptions of various network layers.) It is especially useful when just a few links in a network need protection. (In the latter days of the ARPANET, MILNET trunks outside the continental United States were protected by link encryptors.) Although link-layer encryption has the advantage of being completely transparent to all higher-layer devices and protocols, the scope of its protection is limited. Accordingly, atten- tion is now being focused on network-layer encryption (see Box 2.2~. Network-layer encryption requires no modification to applications, and it can be configured to protect host-to-host, host-to-network, or network-to- network traffic. Cost thus can be traded against granularity of protection. Network-layer encryption is instantiated in the Internet as the IP Se- curity (IPsec) protocol, which is designed to run on the Internet's hosts and routers, or on hardware outboard to either.l2 The initial deployment of IPsec has been in network-to-network mode. This mode allows virtual private networks to be created so that the otherwise insecure Internet can be incorporated into an existing secure network, such as a corporate net 12RFC 2401, Security Architecture for the Internet Protocol, and RFC 2411, IF Security Docu- ment Roadmap, are both forthcoming (~.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 35

OCR for page 26
36 TRUST IN CYBERSPACE work. The next phase of deployment for IPsec will most likely be the host-to-network mode, with individual hosts being laptops or home ma- chines. That would provide a way for travelers to exploit the global reach of the Internet to access a secure corporate network. It is unclear when general host-to-host IPsec will be widely deployed. Although transparent to applications, IPsec is not transparent to system administrators the deployment of host-to-host IPsec requires outboard hardware or modifications to the host's protocol system software. Be- cause of this impediment to deploying IPsec, the biggest use of encryp- tion in the Internet is currently above the transport layer, as SSL embed- ded into popular Web browsers and servers. SSL, although quite visible to its applications, affects only those applications and not the kernel or the hardware. SSL can be deployed without supervision by a central author- ity, the approach used for almost all other successful elements of Internet technology. Higher still in the protocol stack, encryption is found in fairly wide- spread use for the protection of electronic mail messages. In this manner, an e-mail message is protected during each Simple Mail Transfer Protocol (Poster, 1982), while spooled on intermediate mail relays, while residing in the user's mailbox, while being copied to the recipient's machine, and even in storage thereafter. However, no secure e-mail format has been both standardized by the Internet Engineering Task Force (IETF) and accepted by the community. Two formats that have gained widespread support are S/MIME (Dusse et al., 1998a,b) and POP (pretty good privacy) (Zim- merman, 1995~. Both have been submitted to the IETF for review. Findings 1. The PTN is becoming more vulnerable as network elements be- come dependent on complex software, as the reliance on call-translation databases and adjunct processors grows, and as individual telephone companies increasingly share facilities with the Internet. 2. As the PTN is increasingly managed by OSSs that are less propri- etary in nature, information about controlling OSSs will become more widespread and OSSs will be vulnerable to larger numbers of attackers. 3. New user services, such as caller ID, are increasingly being used to provide authenticated information to customers of the PTN. However, the underlying telephone network is unable to provide this information with high assurance of authenticity. 4. The Internet is becoming more secure as its protocols are improved and as enhanced security measures are more widely deployed at higher levels of the protocol stack. However, the Internet's hosts remain vulner- able, and the Internet's protocols need further improvement.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 51 This subsection concentrates on vulnerabilities in the Internet's infra- structure, since this is what is most relevant to NIS designers. Vulner- abilities in end systems are amply documented elsewhere. See, for ex- ample, Garfinkel and Spafford (1996~. Name Server Attacks. The Internet critically depends on the operation of the DNS. Outages or corruption of DNS root servers and other top-level DNS servers whether owing to failure or successful attacks can lead to denial of service. Specifically, if a top-level server cannot furnish accu- rate information about delegations of zones to other servers, then clients making DNS lookup requests are prevented from making progress. The client requests might go unanswered, or the server could reply in a way that causes the client to address requests to DNS server machines that cannot or do not provide the information being sought. Cache contami- nation is a second way to corrupt the DNS. An attacker who introduces false information into the DNS cache can intercept all traffic to a specific targeted machine (Bellovin, 1989~. One highly visible example of this occurred in July 1997, when somebody used this technique to divert re- quests for a major Web server to his own machines (Wall Street Journal, 1997~. In principle, attacks on DNS servers are easily dealt with by extend- ing the DNS protocols. One such set of extensions, Secure DNS,is based on public-key cryptography (Eastlake and Kaufman, 1997) and can be deployed selectively in individual zones.22 Perhaps because this solution requires the installation of new software on client machines, it has not been widely deployed. No longer merely a question of support software complexity, the Internet has grown sufficiently large so that even simple solutions, such as Secure DNS, are precluded by other operational crite- ria. A scheme that involved changing only the relatively small number of DNS servers would be quite attractive. But lacking that, techniques must be developed to institute changes in large-scale and heterogeneous net- works. Routing System Attacks. Routing in the Internet is highly decentralized. This avoids the vulnerabilities associated with dependence on a small number of servers that can fail or be compromised. But it leads to other vulnerabilities. With all sites playing some role in routing, there are many more sites whose failure or compromise must be tolerated. The 22However, configuration management does become much harder when there is partial deployment of Secure DNS.

OCR for page 26
52 TRUST IN CYBERSPACE damage inflicted by any single site must somehow be contained, even though each site necessarily serves as the authoritative source for some aspect of routing. Decentralization is not a panacea for avoiding the vulnerabilities intrinsic in centralized services. Moreover, the trustwor- thiness of most NISs will, like the Internet, be critically dependent both on services that are more sensibly implemented in a centralized fashion (e.g., DNS) and on services more sensibly implemented in a decentral- ized way (e.g., routing). Understanding how either type of services can be made trustworthy is thus instructive. The basis for routing in the Internet is each router periodically in- forming neighbors about what networks it knows how to reach. This information is direct when a router advertises the addresses of the net- works to which it is directly connected. More often, though, the informa- tion is indirect, with the router relaying to neighbors what it has learned from others. Unfortunately, recipients of information from a router rarely can verify its accuracy23 because, by design, a router's knowledge about network topology is minimal. Virtually any router can represent itself as a best path to any destination as a way of intercepting, blocking, or modi- fying traffic to that destination (Bellovin, 1989~. Most vulnerable are the interconnection points between major ISPs, where there are no grounds at all for rejecting route advertisements. Even an ISP that serves a customer's networks cannot reject an advertisement for a route to those networks via one of its competitors many larger sites are connected to more than one ISP.24 Such multihoming becomes a mixed blessing, with the need to check accuracy, which causes traffic addressed from a subscriber net arriving via a different path to be suspect and rejected, being pitted against the increased availability that multi- homing promises. Some ISPs are now installing BGP policy entries that define which parts of the Internet's address space neighbors can provide information about (with secondary route choices). However, this ap- proach undermines the Internet's adaptive routing and affects overall survivability. Somehow, the routing system must be secured against false adver- tisements. One approach is to authenticate messages a hop at a time. A number of such schemes have been proposed (Badger and Murphy, 1996; Hauser et al., 1997; Sirois and Kent, 1997; Smith et al., 1997), and a major router vendor (Cisco) has selected and deployed one in products. Unfor 23In a few cases it actually is possible to reject inaccurate information. For example, an ISP will know what network addresses belong to its clients, and neighbors of such a router generally will believe that and start routing traffic to the ISP. 24The percentage of such multihomed sites in the Internet is currently low but appears to be rising, largely as a reliability measure by sites that cannot afford to be offline.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 53 tunately, the hop-at-a-time approach is limited to ensuring that an autho- rized peer has sent a given message; nothing ensures that the message is accurate. The peer might have received an inaccurate message (from an authorized peer) or might itself be compromised. Thus, some attacks are prevented but others remain viable. The alternative approach for securing the routing system against false advertisements is, somehow, for routers to employ global information about the Internet's topology. Advertisements that are inconsistent with that information are thus rejected. Schemes have been proposed (e.g., Perlman, 1988), but these do not appear to be practical for the Internet. Perlman's scheme, for example, requires source-controlled routing over the entire path. Routing protocol security is an active research area, and appropriately so. Routing in the Internet is actually performed at two levels. Inside an autonomous system (AS) a routing domain under the control of one organization an interior routing protocol is executed by routers. At- tacking these routers can affect large numbers of users, but wiretapping of these systems appears to be rare and therefore of limited concern.25 Of potentially greater concern are attacks on BGP, the protocol used to dis- tribute routing information among the autonomous ISPs around the world. Because BGP provides the basis for all Internet connectivity, a successful attack can have wide-ranging effects. As above, it is easy to secure BGP against false advertisements on a hop-at-a-time basis and difficult to employ global information about topology. Moreover, even if false advertisements could be discarded, successful attacks against BGP routers or against the workstations used to download configuration infor- mation into the BGP routers could still have devastating effects on Inter- net connectivity. To secure BGP against a full range of attacks, a combination of secu- rity features involving both the routers and a supporting infrastructure 25Attacks against an interior routing protocol or against an organization's routers can deny or disrupt service to all of the hosts within that AS. If the AS is operated by an ISP, then the affected population can be substantial in size. Countermeasures to protect link state intradomain routing protocols have been developed (Murphy and Hofacker, 1996) but have not been deployed, primarily because of concerns about the computational overhead associated with the signing and verification of routing traffic (specifically, link state adver- tisements). Countermeasures for use with distance vector algorithms (e.g., DVRP) are even less well developed, although several proposals for such countermeasures have been pub- lished recently. Because all of the routers within an AS are under the control of the same administrative entity, and because there is little evidence of active wiretapping of intra-AS links, there may be a perception that the proposed cryptographic countermeasures are too expensive relative to the protection afforded.

OCR for page 26
54 TRUST IN CYBERSPACE needs to be developed and deployed. Each BGP router must be able to verify whether a routing update it receives is authentic and not a replay, or a previous, authentic update, where an authentic routing update is one that no attacker can modify (undetectably) and one for which the source of the update can be verified to be the "owner" of the portion of the IP address space being advertised.26 Thus, implementing BGP security in- volves creating an infrastructure that codifies the assignment to organiza- tions (e.g., ISPs, DSPs, subscribers) of AS numbers and portions of IP address space. Because of the BGP routing system's size (approximately 50,000 routes and 4,000 ISPs), deployment of these countermeasures is not a certainty. Moreover, after deployment some residual BGP vulnerabili- ties will still remain. For example, a router that is authorized to advertise a route to a network may suppress propagation of route withdrawal mes- sages it receives, thus continuing to advertise the route for some time. But this can cause traffic to the network in question to be discarded. It is worth noting that the routing system of the Internet closely mir- rors call routing in the PTN, except that, in the PTN, a separate manage- ment and control network carries control functions. Any site on the Inter- net can participate in the global routing process, whereas subscribers in the PTN do not have direct access to the management and control net- work. The added vulnerabilities of the Internet derive from this lack of isolation. As network interconnections increase within the PTN, it may become vulnerable to the same sorts of attacks as the Internet is now. Protocol Design and Implementation Flaws. The design and implemen- tation of many Internet protocols make them vulnerable to a variety of denial-of-service attacks (Schuba et al., 1997~. Some attacks exploit buggy code. These are perhaps the easiest to deal with; affected sites need only install newer or patched versions of the affected software. Other attacks exploit artifacts of particular implementations, such as limited storage areas, expensive algorithms, and the like. Again, updated code often can cure such problems. The more serious class of attacks exploits features of certain protocols. For example, one type of attack exploits both the lack of source address verification and the connectionless nature of UDP to bounce packets be- tween query servers on two target hosts (CERT Advisory CA-96.01. This process can continue almost indefinitely, until a packet happens to be dropped. And, while the process continues, computation and network bandwidth are consumed. The obvious remedy would be for hosts to detect this attack or any such denial-of-service attack, much the same way 26Because of the route and address aggregation features of BGP, the route verification requirements are even more complex than described here.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 55 virus-screening software detects and removes viruses. But, if it is cheaper for an attacker to send a packet than it is for a target to check it, then denial of service is inevitable from the sheer volume of packets. Even cryptogra- phy is not a cure: authenticating a putatively valid packet is much harder (it requires substantial CPU resources) than generating a stream of bytes with a random authentication check value to send the victim.27 Findings 1. New countermeasures for name server attacks are needed that work well in large-scale, heterogeneous environments. 2. Cryptography, while not in itself sufficient, is essential to the pro- tection of both the Internet and its end points. Wider deployment of cryptography is needed. Algorithms for authentication only are largely free from export and usage restrictions, yet they can go a long way to- ward helping. 3. Cryptographic mechanisms to secure the DNS do exist; however, deployment to date has been limited. 4. No effective means exist to secure routing protocols, especially on backbone routers. Research in this area is urgently needed. 5. Attacks that result in denial of service are increasingly common. Wider use of updated software and patches, new product development, and better software engineering are needed to deal with this problem. EMERGING ISSUES Internet Telephony What are the security implications if, as predicted by today's traditional telephone network is replaced by an . . ~· ~ ~ T - ~ ~. ~ many pundits, Internet-based transport mechanism? Will telephony become even less secure, owing to all the security problems with the Internet discussed earlier in this chap- ter? Or will some portion of the Internet used only for telephony be resistant to many of the problems described in the preceding sections? Recall that many current PTN vulnerabilities are related either to the services being provided or to the physical transport layer. Rehosting the PTN on the Internet will have no effect on these vulnerabilities. Thus, the OSSs and database lockups related to advanced PTN services, with their 27Encryption is even worse in this regard, as the cost of decryption is often greater than the cost of authentication and because a receiver might have to both decrypt and authenti- cate a packet to determine if it is valid. The Encapsulating Security Payload (ESP) protocol of IPsec counters this denial-of-service vulnerability by reversing the order in which these operations are applied (i.e., a receiver authenticates ciphertext prior to decrypting it).

OCR for page 26
56 TRUST IN CYBERSPACE associated vulnerabilities, would be unaffected by the move to an Inter- net-based telephone system. Similarly, if access to the Internet-based telephone system is accomplished by means of twisted pairs (albeit twisted pairs carrying something like integrated services digital network (ISDN) or asymmetric digital subscriber line (ADSL)), then interconnec- tions of some sort will still be needed. These would likely be routers or switches, but such interconnections are at least as programmable and at least as vulnerable. Call routing in an Internet-based telephone system would be differ- ent, but likely no more secure. At the very least, IP routing would be involved. Most probably, a new database would be introduced to map telephone numbers to domain names or IP addresses. Both, of course, raise serious security and reliability concerns. In at least two respects, both noted earlier in this chapter, an Internet- based telephone system could be significantly more vulnerable to attack than today's PTN. The primary active elements of an Internet-based net- work the routers are, by design, accessible from the network they con- trol, and the network's routing protocols execute in-band with the com- munications they control. By contrast, virtually the entire PTN is now managed by out-of-band channels. Considerable care will be needed to deliver the security of out-of-band control by using in-band communi- cations. The other obvious weakness of the Internet is its end points, personal computers and servers, because attacks on them can be used to attack the telephone system. Finding The PTN is likely to become more vulnerable with the rise of Internet telephony, most notably because Internet-based networks use in-band channels for routing and have end points that are prone to failure. Atten- tion to these issues is needed. Is the Internet Ready for "Prime Time"? Whether the Internet is "ready for business" depends on the require- ments of the business. There are already numerous examples of busi- nesses using the Internet for advertising, marketing, sales of products and services, coordination with business partners, and various other activi- ties. On the other hand, the Internet is also viewed and rightly so as being less reliable and less secure than the PTN. Specifically, the Internet is perceived as more susceptible to interception (i.e., eavesdropping) and has proved to be more susceptible to active attacks (e.g., server flooding,

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 57 Web site modification). Consequently, most Internet-savvy business us- ers restrict what they entrust to the Internet. The Internet is also more prone to outages than the PTN. Thus, it would be unwise for utility companies and other critical infrastructure providers to abandon the PTN and rely on remote access through the Internet for controlling power distribution substations, because individual ISPs are less likely than individual telephone companies to survive local power interruptions.28 Few established businesses seem willing to forgo their telephone or- der centers for Internet-only access, although a small and growing num- ber of newer businesses, such as Virtual Vineyards and Amazon.com, do maintain an Internet-only presence. Abandoning the PTN for the Internet seems unwise for businesses such as brokerage houses or mail-order cata- log companies, where continued availability of service is critical. For example, during the stock market frenzy on October 27-28, 1997, custom- ers of Internet-based brokerage systems experienced unusual delays in executing trades. But the magnitude of their delays was relatively small and was commensurate with the delays suffered by telephone-based ac- cess and even some of the stock market's back-end systems. Still, it is sobering to contemplate the effect of an Internet-related failure that coin- cided with a spike in market activity. Mail-order firms, brokerage houses, and others do make extensive use of the Internet as an avenue of customer access. But it is not the only avenue of access, and neither the customers nor the business have become wholly dependent on it. If, for example, these and similar businesses reduced their other avenues of access (e.g., to save money), then an Inter- net outage could have a significant impact. Consider a scenario in which banks acquire the capability to download customer money onto smart cards through the Internet. Over time, banks might reduce the number of automatic teller machines available (just as the numbers of physical bank branches and tellers have fallen as automated teller machines have prolif- erated). A prolonged failure of this Internet cash distribution mechanism could overload the few remaining available machines and tellers. In theory, the risks associated with using the Internet can be evalu- ated and factored into a risk management model (see Chapter 6~. Most businesses, however, are not fully cognizant of these risks nor of the return on investments in protection. As a result, the level of protection 28Internet service providers have differing plans for dealing with power system failures, which may make it impossible to access computers and data following such a failure. The failure need not even be widespread. By contrast, telephone networks are under central control, can easily implement backup power systems, and require very little electrical cur- rent for an ordinary telephone line.

OCR for page 26
58 TRUST IN CYBERSPACE adopted by many business users of the Internet does not seem commen- surate with that afforded their physical assets. For example, it seems as though the quality of burglar alarms and physical access control systems deployed by most businesses is considerably higher than the level of Internet security countermeasures they deploy (see Chapter 4~. Moreover, businesses that make extensive use of Internet technology may do so in a fashion that externalizes the risks associated with such use. If infrastructure suppliers, such as telephone companies and electric and gas utilities, do not take adequate precautions to ensure the availability of their systems in the face of malicious attacks over the Internet, then the public will bear the brunt of the failure. Because many of these businesses operate in what is effectively a monopoly environment, the free-market forces that should eventually correct such cost externalization may not be effective. Of particular concern is that most of the security countermeasures adopted by businesses connecting to the Internet are designed only to thwart the most common attacks used by hackers. Most hackers, how- ever, are opportunistic and display only a limited repertoire of skills. Protection against that hacker threat is insufficient for warding off more capable, determined threats, such as criminals or terrorists. And while in one sense the Internet poses no new challenges a sys- tem that can be accessed from outside only through a cryptographically protected channel on the Internet is at least as secure as the same system reached through a conventional leased line new dangers arise precisely because of pervasive interconnectivity. The capability to interconnect networks gives the Internet much of its power; by the same token, it opens up serious new risks. An attacker who may be deflected by crypto- graphic protection of the front door can often attack a less protected ad- ministrative system and use its connectivity through internal networks to bypass the encryption unit protecting the real target. This often makes a mockery of firewall-based protection. Findings 1. The Internet is ready for some business use, but it is not at a point where it would be prudent for businesses to abandon the PTN in favor of the Internet. For managing critical infrastructures, the Internet is too susceptible to attacks and outages to be a viable basis for control. 2. Risk management, especially to guard against highly skilled at- tackers, deserves further attention in the business community.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 59 REFERENCES Badger, M.R., and S.L. Murphy. 1996. "Digital Signature Protection of the OSPF Routing Protocol," pp. 93-102 in Proceedings of the Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press. Bellovin, Steven M. 1989. "Security Problems in the TCP/IP Protocol Suite," Computer Communications Review, 19~2~:3248. Bellovin, Steven M. 1995. "Using the Domain Name System for System Break-ins," pp. 199-208 in Proceedings of the 5th USENIX UNIX Security Symposium, Salt Lake City, Utah. Berkeley, CA: USENIX Association. Berners-Lee, T., and D. Connolly. 1995. Hypertext Markup Language 2.0. RFC 1866. No- vember. Berners-Lee, T., L. Masinter, and M. McCahill. 1994. Uniform Resource Locators (URL). RFC 1738. December. Berners-Lee, T., R. Fielding, and H. Frystyk. 1996. Hypertext Transfer Protocol HTTP 1.0. RFC 1945. May. Blaze, Malt. 1996. Afterword. 2nd Ed. Applied Cryptography, Bruce Schneier, ed. New York: John Wiley & Sons. Bolt, Beranek, and Newman (BBN). 1978. "Appendix H: Interfacing a Host to a Private Line Interface," Specification for the Interconnection of a Host and an IMP. BEN Report 1822. Cambridge, MA: BEN, May. Braden, R., L. Zhang, S. Berson, S. Herzog, and S. Jamin. 1997. Resource ReSerVation Proto- col (RSVP) Version 1 Functional Specification. RFC 2205. September. Case, J.D., M. Fedor, M.L. Schoffstall, and C. Davin. 1990. Simple Network Management Protocol (SNMP). RFC 1157. May. Computer Science and Telecommunications Board (CSTB), National Research Council. 1997. The Evolution of Untethered Communications. Washington, DC: National Acad- emy Press. Cooper, Brinton. 1989. "Phone Hacking," RISKS Digest, Vol. 8, Issue 79, June 14. Available online at . Dusse, S., P. Hoffman, and B. Ramsdell. 1998a. S/MIME Version 2 Certificate Handling. RFC 2312. March. Dusse, S., P. Hoffman, B. Ramsdell, L. Lundblade, and L. Repka. 1998b. S/MIME Version 2 Message Specification. RFC 2311. March. Eastlake, D., and C. Kaufman. 1997. Domain Name System Security Extensions. RFC 2065. January. Fielding, R., J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. 1997. Hypertext Transfer Protocol HTTP 1.1. RFC 2068. January. Floyd, S., and K. Fall. 1998. "Promoting the Use of End-to-End Congestion Control in the Internet," IEEE/ACM Transactions on Networking. Available online at . Floyd, S., and V. Jacobson. 1993. "Random Early Detection Gateways for Congestion Avoidance," IEEE/ACM Transactions on Networking, 1~4~:397413. Garfinkel, S., and E. Spafford. 1996. Practical UNIX and Internet Security. Newton, MA: O'Reilly and Associates. Hauser, R., T. Przygienda, and G. Tsudik. 1997. "Reducing the Cost of Security in Link- State Routing," pp. 93-101 in Proceedings of the Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press. Howard, John D. 1997. "An Analysis of Security Incidents on the Internet 1989-1995," Ph.D. thesis, Department of Engineering and Public Policy, Carnegie Mellon Univer- sity, Pittsburgh, PA.

OCR for page 26
60 TRUST IN CYBERSPACE Ioannidis, John, and Malt Blaze. 1993. "The Architecture and Implementation of Network Layer Security in UNIX," pp. 29-39 in Security IV, Santa Clara, California. Berkeley, CA: USENIX Association. Jacobson, V. 1988. "Congestion Avoidance Control," pp. 314-329 in SIGCOMM 88, Stanford California. Los Alamitos, CA: IEEE Computer Society. Kahn, David. 1976. The Code Breakers. 8th Ed. New York: Macmillan. Kristol, D., and L. Montulli. 1997. HTTP State Management Mechanism. RFC 2109. February. McQuillan, J.M., and D.C. Walden. 1977. "The ARPA Network Design Decisions," Com- puter Networks, August, pp. 243-289. Mills, D.L. 1984. Exterior Gateway Protocol Formal Specification. RFC 904. April. Mills, Mike. 1998. "AT&T High Speed Network Fails: Red Cross, Banks Scramble to Adjust," Washington Post, April 14, p. C1. Mockapetris, P.V. 1987a. Domain Names Concepts and Facilities. RFC 1034. November. Mockapetris, P.V. 1987b. Domain Names Implementation and Specification. RFC 1035. No- vember. Morris, Robert T. 1985. A Weakness in the 4.2 BSD UNIX TCP/IP Software. Murray Hill, NJ: AT&T Bell Laboratories, February. Murphy, Jamie, and Charlie Hofacker. 1996. "Explosive Growth Clogs the Internet's Back- bone," New York Times, July 3. Network Reliability and Interoperability Council (NRIC). 1996. Network Reliability: The Path Forward. Washington, DC: Federal Communications Commission. Available online at . Network Reliability and Interoperability Council (NRIC). 1997. Final Report of the Network Reliability and Interoperability Council. Washington, DC: Federal Communications Com- mission, July 15. Parasuraman, Raja, and Mustapha Mouloua, eds. 1996. Automation and Human Performance: Theory and Applications. Mahwah, NJ: Lawrence Erlbaum Associates. Perillo, Robert J. 1997. "AT&T Database Glitch Caused '800' Phone Outage," Telecom Di- gest, Vol. 17, Issue 253, September 18. Available online at . Perlman, Radial 1988. "Network Layer Protocols with Byzantine Robustness," Ph.D. the- sis, Computer Science Department, Massachusetts Institute of Technology, Cambridge, MA. Postel,J. 1982. Simple Mail Transfer Protocol. RFC 821. August. Rekhter, Y., and P. Gross. 1995. Application of the Border Gateway Protocol in the Internet. RFC 1772. March. Rekhter, Y., and T. Li. 1995. A Border Gateway Protocol 4 (BGP-4). RFC 1771. March. Schuba, Christoph L., Ivan Krsul, Markus G. Kuhn, Eugene H. Spafford, Aurobindo Sundaram, and Diego Zamboni. 1997. "Analysis of a Denial of Service Attack on TCP," pp. 208-233 in Proceedings of 1997 IEEE Symposium on Security and Privacy. Los Alamitos, CA: IEEE Computer Society Press. Shenker, S., and J. Wroclawski. 1997. General Characterization Parameters for Integrated Ser- vice Network Elements. RFC 2215. September. Sirois, K.E., and Stephen T. Kent. 1997. "Securing the Nimrod Routing Architecture," pp. 74-84 in Proceedings of the Annual Internet Society (ISOC) Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press. Smith, B.R., S. Murthy, and J.J. Garcia-Luna-Aceves. 1997. "Securing Distance-Vector Rout- ing Protocols," pp. 85-92 in Proceedings of the Annual Internet Society (ISOC) Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press.

OCR for page 26
PUBLIC TELEPHONE NETWORK AND INTERNET TRUSTWORTHINESS 61 Stevens, W. 1997. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. RFC 2001. January. Thompson, Kevin, George J. Miller, and Rick Wilder. 1997. "Wide-Area Internet Traffic Patterns and Characteristics," IEEE Network, 11~6~:10-23. Traina, P. 1993. Experience with the BGP-4 Protocol. RFC 1773. March. Traina, P. 1995. BGP-4 Protocol Analysis. RFC 1774. March. Wall Street Journal. 1997. "An Internet Stunt Causes Trouble for Kashpureff," November 4. Weissman, Clark. 1992. "Blacker: Security for the DDN: Examples of A1 Security Engi- neering Trades," pp. 286-292 in Proceedings of the 1992 IEEE Symposium on Security and Privacy. Los Alamitos, CA: IEEE Computer Society Press. Wickens, Christopher D., Anne S. Mavor, and James P. McGee, eds. 1997. Flight to the Future: Human Factors in Air Traffic Control. Washington, DC: National Academy Press. Zimmerman, Philip R. 1995. The Official POP User's Guide. Cambridge, MA: MIT Press.