00001.tif

PDF

Download

Open document

Transcript (if available)

Content ACCESS CONTROL AND POLICY ENFORCEMENT IN INTERNETWORKS by Gene Y. Tsudik A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (Computer Science) April 1991 Copyright 1991 Gene Y. Tsudik UMI Number: DP22838 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. U M T Dissertation Publishing UMI DP22838 Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106-1346 UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90007 This dissertation, written by Gene Y. T sudik under the direction of h i s Dissertation Committee, and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillment of re quirements for the degree of ?h.D. CpS '9 1 T 882 DOCTOR OF PHILOSOPHY Dean of Graduate Studies D a te..... DISSERTATION COMMITTEE Chairperson D e d ic a tio n To R & D and 179 steps o f w isdom . I I I ! * A ck n o w led g em en ts ( This is one of the most difficult sections of this thesis’as there are so many people I would like to , thank. First and foremost, I can only scratch the surface of my deepest gratitude to my advisor, Dr. Deborah Estrin, whose guidance, friendship and piquant sense of humor I enjoyed during my years at USC. Our innumerable meetings, discussions and (at tim es heated) debates at various exotic locations have contributed greatly to this dissertation and m y intellectual maturity. Most importantly, she is responsible for convincing me not to view research as a sequence of sprints, ■ and to use analogies sparingly. I would also like to thank other members of my dissertation com m ittee, Drs. Silvester and McLeod for their helpful comments and for enduring my ramblings, both written and spoken. I sincerely thank all former and current members of the Computer Networks and Distributed Systems Lab for maintaining a stim ulating and friendly research milieu. I am indebted to Lee Breslau and Steve Hotz for comments on this thesis and its presentation. Kamal Anand, Danny Mitzel and Ron Cocchi have contributed to various stages of Visa protocol implementation, testing and experiments. I am also grateful to fellow IDPR-ers: Lee Breslau, Tony Li and Katia Obraczka with whom I enjoyed having many a brainstorming session. Special thanks to Debbie Galtman for conquering DESNC. I am also indebted to Sharon Anderson who is, tragically, no longer with us. I am thankful to all members of the Internet Open Routing Working Group who contributed to the design and implementation of IDPR. In particular, I would like to thank Martha Steenstrup and Helen Bowns at BBN, and Robert (W oody) Woodburn at SAIC. Last, but certainly not least, I wish to thank my family. My parents have always been an endless source of warmth, understanding and support. My wife, Rima, is impossible to thank \ properly in this context; any expression of gratitude will be an understatement. Finally, my ' daughter, Daniela, has been instrumental to this dissertation by being the chief motivation for its eventual completion, and by staying exceptionally quiet in difficult moments. C o n ten ts D ed ication ii A ck n ow led gem en ts iii A b stract viii 1 In trod u ction 1 1.1 O v e rv ie w .................................................................................................................... 1 1.1.1 Organization of This C h a p te r.................................................................. 2 1.2 Interconnection of Autonomous N e tw o rk s ........................................................ 2. 1.2.1 Adm inistrative D o m ain s............................................................................ 2 1.2.2 P o lic ie s .......................................................................................................... 2 1.2.2.1 Stub and Transit P o lic ie s......................................................... 3 1.2.2.2 Policy A ttrib u tes.......................................................................... 4 1.2.2.3 Problem atic P o licies................................................................... 5 1.2.3 Internetwork T opology............................................................... 5 1.3 Access Control R eq u irem en ts............................................................................... 6 1.3.1 End-sy stems and Applications ............................................................... 7 1.3.2 Network R esources...................................................................................... 8 1.3.2.1 AD B oundaries..................................................... 9 1.3.2.2 S tu b A D s ...................................................................................... 9, 1.3.2.3 Transit A D s ................................................................................ 11 1.3.3 Route se le c tio n ............................................................................................... 11 1.4 Design C h o ic e s ............................................................................................................. 12 1.4.1 Security S e rv ic e s......................................................................................... 12, 1.4.2 Enforcement L o c a tio n .............................................................. 14 1.4.3 Enforcement P r o to c o l.................................................................................. 15 1.4.4 Principal G r a n u la r ity .................................................................................. 16 1.4.5 Communication Granularity and Enforcement M o d e .......................... 17 1.4.6 S u m m a ry ......................................................................................................... 19 1.5 C o n clusions................................................................................................................ 19 1.6 Overview of This T h e s is ........................................................................................ 20 2 B ackground 22 2.1 Related W o rk .......................................................... ................................................. 22; ! 2.1.1 Network S e c u rity ......................................................................................... 22 j 2.1.2 A d hoc Methods ......................................................................................... 2 5 1 2.1.3 Internetwork Routing ................................................. 26' 2.1.3.1 Exterior Gateway P r o to c o l...................................................... 28 ! 2.1.3.2 Border Gateway P ro to c o l......................................................... 28 2.1.3.3 Inter-Domain Routing P ro to co l............................................... 29 2.1.3.4 Routing with. M ultiple Hierarchical Addresses .................. 30 2.1.3.5 I D P R ........................................ 31, 2.1.3.6 Secure and Robust R o u tin g ...................................................... 32 2.2 Support M echanism s............................................................................................... 33 2.2.1 Encryption and Signature S u p p o r t........................................................ 33 j 2.2.2 Certification ........................................................ ....................................... 36 ■ 2.2.3 Time S yn ch ro n izatio n ................................................................................ 37: I Stub P o licy E nforcem ent: Visa P ro to co l 39 3.1 O v e rv ie w ................................................................................................................... 39 3.2 History ...................................................................................................................... 40 3.3 Goals .......................................................................................................................... 41 3.4 Network E n v iro n m e n t............................................................................................ 42 3.5 P a rtic ip a n ts ................................................................. .............................................. 43 3.5.1 ACSs ............................................................................................................... 43 3.5.2 Border R o u te rs .............................................................................................. 43 3.5.3 Participating E nd-system s.......................................................................... 44 3.6 P ro to c o l...................................................................................................................... 45 3.6.1 Setup P h a se ..................................................................................................... 46 3.6.1.1 Exit A uthorization...................................................................... 47 3.6.1.2 Entry A u th o rizatio n................................................................... 48 1 3.6.1.3 Visa Distribution ...................................................................... 49 3.6.1.4 Setup S u m m a r y .......................................................................... 50 3.6.2 Packet F o rw ard in g ........................................................................................ 51 3.6.2.1 Exiting A D a ................................................................................ 51 3.6.2.2 Entering ADb ............................................................................. 52 3.6.3 T e a rd o w n ........................................................................................................ 52 3.7 Design I s s u e s ............................................................................................................. 53 3.7.1 V isas.................................................................................................................. 53 3.7.2 Replay P re v e n tio n ....................................................................................... 54 3.7.3 Visa E x p iratio n .............................................................................................. 54 3.7.4 Visa R e v o c a tio n .......................................................................................... 55 3.7.5 Coverage of Packet Signatures ................................................................ 55 3.7.6 F ra g m e n ta tio n .............................................................................................. 56 3.7.7 Loss of S t a t e ................................................................................................. 5 7 ! 3.7.8 Stateful M o d e l.............................................................................................. 58 3.8 Security A n a ly sis..................................................................................................... 59 3.8.1 V ISA -R EQ U EST.......................................................................................... 59 3.8.2 V IS A -G R A N T .............................................................................................. 61 ______________________________ _____ ________________________________V i 3.8.3 D ata p a c k e ts 61 j 3.9 Protocol C o s t s 63 * 3.9.1 Setup and D istribution 63 1 3.9.2 State O v e rh ea d 63 I 3.9.3 Per packet costs ......................................................................................... 64 3.10 S u m m a r y ..................................... 65 T ra n s it P o licy E n fo rc e m e n t: C o n tro l o f T ra n s it In te rn e tw o rk Traffic 66 4.1 Controlling Transit T raffic....................................................................................... 67 4.1.1 Extending Network Access C o n tr o ls 67 > 4.1.1.1 Transit Pisa P r o to c o l................................................................... 67 ‘ 4.1.1.2 D is c u s sio n ...................................................................................... 68 4.1.2 Policy R o u tin g 69 ' 4.1.2.1 ID PR A rchitecture......................................................................... 69 4.1.2.2 D is c u s sio n ....................................................................................... 72 4.2 Security Issues in Transit C o n tro l.......................................................................... 72 4.2.1 Specific Threats .......................................................................................... 73 4.2.2 Terminology ................................................................................................ 73 4.2.3 Distribution of Policy Terms .................................................................. 74 4.2.4 Route Setup .............................................. 75 4.2.5 Packet F o rw ard in g ................................. 77 4.2.5.1 Signature c o m p u ta tio n ................................................................ 77 4.2.5.2 Signature C o v e ra g e ...................................................................... 79 4.2.5.3 Signature V erificatio n ................................................................... 81 4.2.5.4 Preventing Replay of D ata P ack ets............................................ 83 4.3 Protocol D e sc rip tio n ................................................................................................. 85 4.3.1 P a rticip a n ts................................................................................................... 86 4.3.2 Packet H a n d lin g ................................................. 87 4.3.3 PR S e t u p .............................................. 88 4.3.3.1 PR Setup S u m m a ry ...................................................................... 90 4.3.4 Packet F o rw ard in g ...................................................................................... 91 4.4 Security A n a ly sis........................................................................................................ 91 4.4.1 PR S e t u p ....................................................................................................... 91 4.4.1.1 SETUP Processing......................................................................... 92 4.4.1.2 A CCEPT Processing ................................................................... 93. 4.4.2 Packet F o rw ard in g .......................... 94 4.5 Assessment and C o s t.................................................. 95 4.5.1 Packet Signatures ...................................................................................... 95 4.5.2 Costs Due to Increased Packet L e n g th .................................................. 96 4.5.3 Setup Overhead ..................................................................................... . 96 4.5.4 Other Per Packet Processing C o s ts ........................................................ 97 4.6 C o n clusions.................................................................................................................. 97 E x p e rim e n ta l R e su lts 101 5.1 Experim ental P la tfo rm ................................................................................................. 101 5.2 Visa E xperim ents 103 j 5.3 ID PR E x p erim en ts.......................................................................................................106 5.3.1 Additional B a c k g ro u n d .................. 106 5.3.1.1 Policy Routes ..................................................................................108 5.3.1.2 Protocol Description: ORIGINATOR P G ................................ 109! 5.3.1.3 Protocol Description: TRANSIT and TARGET PGs . . . 110, 5.3.1.4 PR Tear down ................................................................................. 112' 5.3.2 Experiments ................................................................................................... 114 J 6 C o n clu sio n s a n d F u tu re W o rk 118 ' 6.1 Contributions of This Thesis 118 . 6.1.1 F ra m e w o rk ................................................................................. 118 6.1.2 Stub AD Policy E n fo rc em e n t..................................................................... 119 6.1.3 Transit AD Policy E nforcem ent.................................................................. 120 6.1.4 Security .vs. Cost ......................................................................................... 121 6.2 Future Work ................................................................................................................ 121 6.2.1 M ulticasting ................................................................................................... 122 6.2.2 Fault T olerance................................................................................................123 6.2.2.1 State R ecovery..................................................................................123 6.2.2.2 Connection and Route Repair ....................................................124 6.2.3 Accounting and B illing...................................................................................125 6.2.4 I n te g r a tio n .......................................................................................................125 6.2.4.1 Border R o u ters................................................................................. 125 6.2.4.2 Specialized S ervers............................................................. 126 6.2.5 Other Policy Routing Approaches ............................................................127 A p p e n d ix A Message Authentication with One-Way Hash Functions ............................................ 134 A .l In tro d u ctio n ................................................................................................................... 134 A.2 M otivation ....................................................................................................................134 A .3 Protocol D e sc rip tio n ............................................. 135 A.4 Informal A n aly sis............................................ 135 A.4.1 Definitions .......................................................................................................136 A.4.2 Secret P r e f i x ................................................................................................... 136 A.4.3 Secret Suffix ................................................................................................... 137 A .5 C o s t ................................................................................. 137 A.6 An E x te n s io n ................................................................................................................ 137 A .7 A pplications................................................................................................................... 138 A.8 S u m m a r y .................................................................... 138 A b stra c t , A collection of independent Administrative Domains (ADs) can be joined together in an internetwork in order to support inter-organizational communication and resource shar ing. Despite the interconnection, ADs are concerned with maintaining varying degrees of autonomy by exerting local control over their network resources. Each AD specifies its own network p o lic y th at represents a tradeoff between autonomy and interdependence. However, existing internetworking approaches attem pt to achieve full connectivity w ith out much regard to policy. This research represents the first broad-scale treatm ent of policy enforcement in in ternetwork environments. We explore the range of potential policies and consider policy enforcement in the context of end-point and transit ADs. A well-known end-to-end argu ment is applied to provide a comprehensive framework for the placement and composition of access controls to support policy enforcement. For end-point ADs, we propose fine grained enforcement provided by Visa protocol which controls the flow of packet traffic at AD boundaries. In order to control transit internetwork traffic, policy support must be integrated into internetwork routing and packet-forwarding protocols. Secure protocols for the Inter-Dom ain Policy Routing architecture are presented. The central theme of protocol security is addressed throughout. In order to minimize . the performance im pact of typically costly security services, innovative cryptographic protocols are introduced and the cost of security is evaluated in detail. Furtherm ore,: methods for strong, yet inexpensive, encryption-free d ata integrity and authentication are presented. ! Prototype implementations of the proposed policy enforcement mechanisms have been developed. We discuss implementation issues and performance results. I C h a p ter 1 In tro d u ctio n i 1.1 O verview Increasing use of computers for communication has prom pted widespread interconnection of autonomous networks. In an environment of interconnected A dm inistrative Domains (ADs), access to network resources is an issue of growing concern. In the absence of special mechanisms, network interconnection using existing internetworking protocols (e.g., IP [73] or OSI [43]) attem pts to achieve full connectivity. However, ADs should be able to interconnect without exposing their internal resources to unrestricted external access [24, 27]. Moreover, internetwork components should be able to control incoming and outgoing traffic by specifying or constraining the ADs to, and through, which the traffic can flow [26]. While complete autonomy implies no interconnection, increased ”openness” sacrifices autonomy. Thus, each participant organization must reach its own tradeoff between autonomy and interdependence. The particulars of this tradeoff are embodied in what we refer to as policy. The purpose of this thesis is to present the design of a policy enforcement archi tecture for an environment of interconnected ADs. In this chapter, we introduce some basic concepts necessary for the appreciation of the underlying problem and propose a framework for the subsequent design of policy enforcement mechanisms. In Chapter 2, . we discuss current policy enforcement approaches and a number of support mechanisms to be used as basic building blocks in our design. Chapter 3 is dedicated to the treatm ent of access control at end-point AD boundaries and Chapter 4 addresses the control of transit internetwork traffic. Chapter 5 describes the experimental results obtained from the implementations of the mechanisms proposed in Chapters 3 and 4. Finally, Chapter 6 summarizes the results of this thesis and discusses topics for future research. 1 .1 .1 O r g a n iz a tio n o f T h is C h a p te r This chapter is organized as follows.1 We begin in Section 1.2 by addressing the inter network environment and exploring the range of network policies th at an organization might wish to express. In Section 1.3, we identify three objects of internetwork access control:2 end-systems, network-layer resources, and internetwork routes. We then con sider the well-known end-to-end argument for the placement of controls in network layer protocols [78]. Section 1.4 describes the security services needed to address each of these requirements and the corresponding design choices of enforcement location, protocol, and granularity. Section 1.6 concludes this chapter w ith an overview of the rest of the thesis. 1.2 In terc o n n ec tio n o f A u to n o m o u s N etw ork s In order to provide appropriate background for the subsequent discussion, this section defines our terminology and assumptions regarding internetwork environments, policies, and protocol design principles. 1 .2 .1 A d m in is tr a tiv e D o m a in s In the context of this thesis, an internetwork is composed of a number of Adm inistrative Domains, or ADs. An AD is defined as a collection of network resources under control of a single adm inistrative entity [26]. We distinguish between two types of ADs: stub and transit. Stub ADs are interested mainly in communication with other stub ADs, i.e., providing communication for their constituent end-systems. A campus network is an example of a stub AD. Transit ADs provide communication service (i.e., bandw idth and switching) for stub AD traffic. Finally, there are also hybrid ADs th at combine transit service w ith end-system communication. 1.2.2 P olicies As frequently happens with a new concept, an analogy can lead to better understanding of the problem at hand. We can view ADs as sovereign countries, each with a specific set of foreign policy statem ents regarding interaction with foreign entities (other ADs). For example, a country may have policies restricting foreign visitors to specific areas or restricting travel privileges of the local populace when visiting foreign countries. Countries 1 Portions of this chapter appeared in [30]. 2Throughout this thesis, the terms access control and policy enforcem ent are used interchangeably. imay also have specific policies pertaining to transit travelers, e.g., restricting entry on the basis of the traveler’s itinerary. Security policies regarding international travel can express policy with regard to passport and visa requirements, length of stay, etc. Accounting or billing policies may concern, for example, visa fees or departure taxes. ADs can express similar policies regarding communication with external entities, e.g., restrict internal systems available for external access or restrict external systems available for internal access. Transit traffic may or may not be allowed, or it may be restricted to specific source, destination ADs or end-systems. Policies can also embody security requirements, e.g., authentication and authorization for inter-AD traffic, as well as ac counting and billing conditions [26]. Network level policies are primarily concerned with unauthorized access to resources, denial of service, and inappropriate accrual of communication-related charges. These threats can all come about through attacks on the authenticity and the integrity of internetwork packet traffic. Some concerns are of greater im portance to stub networks and others, to transit networks. 1.2.2.1 S tub and Transit P olicies Due largely to the nature of service provided, stub and transit ADs tend to express differ ent policies. Most policies expressed by stub ADs protect internal resources from external access, while those expressed by transit ADs tend to be cost-related. Another way of mak ing this distinction is to observe th at transit ADs, by virtue of providing transit service, are inherently more open than their stub counterparts. Furthermore, subversion of transit A D ’s policies will, in the worst case, result in denial of communication services, whereas subversion of stub network polices can potentially disrupt the end-systems themselves. Another reason for separating the respective policies is the difference in accounting and billing requirements. Stub ADs are more likely to bundle communication costs into billing for end services, if any such billing occurs. Transit ADs are more likely to charge for the communication itself. Finally, stub AD policies include route selection criteria, which dictate how the A D ’s packets travel to their destinations. In some respects, the requirements for transit policy enforcement are simpler than those for stub policy enforcement. However, several factors complicate the implemen tation of the latter. First, in an internetwork, a packet may travel through a number of transit ADs on its way to the destination. Consequently, applicable policies from all transit ADs must be considered when a packet is being sent; whereas for control of stub resources, only the policies of the two end-point ADs need to be taken into account. In 3 addition, transit control has to be reconciled with topology changes (routers or links going down). If in the middle of a connection any component of the route becomes disabled, entirely different policies may come into effect. Also, when a transit AD decides to ac count or charge for resource usage, coordination is required to pass charges back to the lend points. Moreover, stub AD route selection criteria m ust be integrated with transit control policies to determine the appropriate routes. These factors add to the complexity of potential enforcement mechanisms. Based in part on the difference in policies, and in part on the functionality required in any routing (i.e., transit) mechanism, transit and stub AD mechanisms also differ. By analogy with international travel, in most countries transit travelers are set apart from other visitors. They are issued special transit visas and are restricted in movement and length of stay. We discuss transit mechanisms further in later sections. 1.2.2.2 P o licy A ttr ib u te s Policies can be based upon a number of attributes: • E n d p o in t policies place restrictions on the source an d /o r destination of traffic. Example: [No traffic to/from AD X is acceptedJ • P a th policies place restrictions on other ADs of the path in addition to the source and destination ADs. Example: [Transit traffic must enter/exit through A D Y] • S e c u rity attributes express requirements for authentication, data integrity, replay detection and privacy. Example: [All incoming traffic must be encrypted] • T e m p o ra l p a ra m e te rs include restrictions on usage based on tim e of day, day of the week or other tim e-related param eters. Example: [Traffic from A D X is only accepted between midnight and 6 am] • T y p e o f S erv ice (T oS) policies discriminate according to the service parameters (e.g., delay, throughput) made available to different users. Example: [High-bandwidth, low-delay traffic is not handled] • A c c o u n tin g /B illin g policies express conditions related to charging and account ing. Example: [Transit service is charged for on per packet basis] 4 A typical policy statem ent can be based upon several policy attributes. For example, the policy statem ent below applies to transit traffic and combines ToS, tem poral and accounting/billing attributes: [Priority transit traffic from A D a is accepted between 2 and 6 am with a per packet charge] Further examples of policy types can be found in [26]. 1.2.2.3 P ro b lem atic P olicies Policy types discussed thus far involve static attributes and are determ inistic in nature, i.e., a policy either perm its or prohibits communication between a set of entities. Policies can also be based upon highly dynamic param eters such as current load or link availability. Such policies are known as non-deterministic policies. For example, A D a may have a policy to carry transit traffic as long as it does not interfere with local communication, j Or, A D a will carry transit traffic as long as it consumes less than, say, 30% of ADa s total bandwidth. The ubiquity of these policies is th at an AD can express conditional policy statem ents based on the constantly changing state of the network. The difficulty is that, outside of the AD th a t expresses non-deterministic policies, it is generally impossible to determine whether a particular policy perm its or prohibits communication at a given point in time. 1 .2 .3 In te r n e tw o r k T o p o lo g y Some routing protocols place restrictions on internet scale and topology, e.g., EG P [77]. Any inter-AD routing protocol should have the potential of supporting very large scale internetworking. We anticipate on the order of 105 ADs.3 In an internet of such enormous size, it would be im practical to design a protocol th at relied on topological restrictions; enforcement would be near impossible. Consequently, one of our design goals is to allow for maximum degree of flexibility in regard to the configuration of the internetwork. The protocols discussed below do not place restrictions on the internetwork topology. Figure 1.1 depicts an example of AD interconnection topology. It resembles a tra ditional three-level hierarchy of long haul, regional and stub ADs. However, there are exceptions to the hierarchy in the form of lateral and bypass links. These exceptions to the otherwise regular topology are not dispensable and must be supported, perhaps at 3 A lthough the m ajority will be stub AD s, our m odel assumes a large number o f transit and hybrid A D s as well. 5 a : S j : S : |: ^ j g ; |: |: ^ga^> backbone transit AO regional transit AD <g§i> Hybrid A D Figure 1.1: Example of AD interconnection. the expense of routing protocol overhead. Absence of restrictions on AD interconnec tion allows us to accommodate this, or any other, topology th at may evolve in future internetworks.4 1.3 A c c e ss C on trol R eq u irem en ts This section addresses access control requirements for all objects of policy. It begins with a brief discussion of end-system control in an inter-AD context. We then argue for controlling access to AD network resources independently of end-system access control. 4 For further discussion of internetwork topology see [26]. 6 1 .3 .1 E n d -s y s te m s a n d A p p lic a tio n s End-system security is a requirement for all stub ADs. Previous work has addressed the design of secure applications, operating systems, as well as the adaptation of secure systems to a network context [89, 51, 90, 89, 46, 27]. Modern distributed operating systems, e.g., Andrew [80] and Amoeba [64], illustrate m ethods for efficient im plem entation of security features in a distributed computing en vironment with high availability of services. In the realm of secure applications, Privacy- Enhanced Electronic Mail [51], for example, provides valuable insights pertaining to the im plem entation of security services in a large-scale distributed environment with a very large and volatile user population. We emphasize end-system and application-level controls as a point of comparison for the other controls addressed, and comment on the division of labor between end-system and network controls. But first, we briefly discuss how inter-AD connections influence the requirements for end-system controls themselves. Inter-AD connections im pact ADs th at have relatively open internal computing en vironments more so than ADs with closed, protective internal environments. For an AD th at employs rigorous security mechanisms on all end-systems, introduction of an inter- AD link need not induce significant modification of the end-systems themselves. However, many ADs employ a more laissez-faire approach to security-im plem enting stringent con trols on only a small subset of critical systems and leaving the balance of end-systems relatively vulnerable to intra-AD access. This should not be viewed as a criticism or fail ing of intra-AD security. R ather, to the extent th at controls may inhibit internal resource sharing, it may be in the organization’s interest to m aintain a relatively open environ ment. Introducing additional controls throughout an AD is often im practical because of the large number of internal end-systems and the subsequent difficulties in verifying the correct operation of these controls. Nevertheless, introduction of inter-AD links may require some reassessment of this approach. In addition, some communication-oriented applications will require special consider ation. Among them are: electronic mail, video conferencing, file sharing and process migration. Each demands a unique combination of security-related services. In video conferencing, for example, privacy is often im portant while d ata integrity is somewhat secondary; also, bandwidth availability is critical. Hence, denial of service (malicious or otherwise) is of significant concern. 7 1 .3 .2 N e tw o r k R e so u r c e s Many discussions of network security are actually discussions of end-system protection in a network environment, e.g., [85, 69, 48, 46, 27, 90]. W hile this is an im portant consideration, we claim th at it is not adequate in the multi-AD context. For both stub 'and transit ADs, there are valuable network resources th at are also the object of policy, j This is in agreement with a well-known design principle, the end-to-end argument ' [78]. It states th at the placement of controls should be in the highest protocol layer at the end-points of communication. From a functional standpoint, features such as reliability and security must take place in the highest layers if they are to cover all sources of vulnerability. Therefore, the argument is th at lower-layer efforts are always redundant and should be implemented only to the extent th at they improve efficiency. In the case of security, the argument suggests th a t end-system resources are best protected by the end-systems themselves, e.g., security services should be provided in the transport layer as opposed to the network or data link layer [90]. We observe, however, th a t in the sense of the end-to-end argument, network resources are endpoints to the extent they require protection in their own right. Therefore, it is imperative to address the protection of network resource in addition to the more traditional end-system protection. This implies the need for controls at the AD exit and entry points. If control is left to the end-systems, valuable stub-AD network resources may be consumed by unauthorized traffic. Rejecting packets at the end-system is too late from the perspective of network resource usage. Moreover, unrestricted network access increases the vulnerability of ADs to denial of service attacks in the form of packet storms. In other words, the network interfaces of end-systems are themselves network resources and should be subject to access control (which can only be achieved below the transport layer). Similarly, some ADs have no relevant end-systems (they provide transit services only) and therefore must implement desired controls in the network-layer routing protocol. Since routing is a network layer function, these controls m ust also involve network level entities and can not be left to transport session endpoints. Network interconnection is typically done at the network layer for reasons of trans parency, flexibility and performance. Consequently, transport and higher layers are gener ally not well-suited for the implementation of network resource controls. Moreover, lower layers (physical and data-link) do not provide access to subject and object information necessary to make policy decisions with respect to network resources. This leads to our 8 assertion th at the network layer is most appropriate for the im plem entation of network resource controls. In summary, to the extent network resources require protection, the highest relevant endpoint is the network router and associated packet forwarding and routing protocols. In ; this sense, the end-to-end argument supports implementing these controls at the network I jlayer. 1.3.2.1 A D B oundaries An AD represents a set of resources th at are governed by common policies. We argue » jthat the enforcement of policies pertaining to inter-AD communication is best carried out Jat the AD boundaries.5 Throughout our discussion we will exploit the AD abstraction to decouple requirements and mechanisms for intra-AD communication from those for inter-AD communication. In particular, we assume network layer enforcement only in those routers th at connect the AD to other ADs, i.e., border routers (also referred to as Policy Gateways [50]). Another m otivating factor for implementing controls at border routers is the trend towards commercialization of portions of the Internet. Some network resources may be charged for on a usage-sensitive basis. This opens new incentives and opportunities for fraud. Consequently, border routers must be equipped to detect such abuse before valuable network resources are consumed and charges are accrued. In the following sections, we address such security concerns in the context of both stub and transit ADs. 1.3.2.2 Stub A D s Stub ADs need to protect the integrity of their internal network in the presence of inter- AD connections. Network resources th at may require protection include links, bridges, routers, and end-system network interfaces. In the following paragraphs we further justify the need to control access to communication resources themselves, and the need to include end-system network interfaces among the resources being protected. Most internal networks are implemented without explicit access controls in the nodes or routers. In the context of intra-AD use, lim itations on access to private information or resources applies prim arily to end-systems. Communication is most often treated as 5Policies that apply to intra-A D com m unication can be enforced by each AD independently. 9 a free good within organizations. It is neither charged for, nor controlled on a usage- sensitive basis. Most often, internal network access is unrestricted if a user has legitimate end-system access. Even within the AD this can lead to undesired dependencies among hosts, departm ents, etc; for example, misbehaving hosts generating broadcast storms, or poor transport protocol implementations degrading performance of a bottleneck resource. However, in most cases, the existence of a common adm inistrative umbrella alleviates the need for intra-AD control of communication resource usage. W hen an inter-AD connection is first established, it may violate some of the assump tions under which these intra-AD protection decisions were made. There is no longer a common adm inistration, nor the common organizational goals th at can be assumed in the intra-AD context. In addition, there is no control over im plem entation and configuration of end-systems and routers in other ADs. The number and nature of the potential users increases qualitatively in the presence of an inter-AD link. In this context, the commu nication resources can no longer be considered free to all potential users. For this reason, stub AD network resources themselves must be considered as objects of access control policy in a multi-AD internet. The external connection in a stub AD usually exists for the purposes of a small subset of internal end-systems [24]. It may be undesirable to expose all internal end-systems. Furtherm ore, as discussed in section 1.3.1, it is im practical to assume th at all end-systems in every AD will implement adequate defenses to be considered secure in the face of a greatly expanded and diversified user community (e.g., a global internetw ork).6 There fore, ADs require mechanisms th at allow them to designate those end-systems th at will be reachable from the outside, and those th at will not. Similarly, ADs may wish to re strict origination of outgoing traffic to those end-systems th at are explicitly authorized, e.g., to restrict the usage of pay-per-packet transit services or to reduce the risk of unde sired information exportation. Hereafter, we refer to the externally-accessible (reachable) end-systems as equipped, and the rest as unequipped end-systems. Access to unequipped end-systems is treated as a network-level access control problem. In other words, the end-system network interfaces are viewed as network resources that require protection. By controlling access to end-system interfaces, ADs can also address the susceptibility of all end-systems to denial of service attacks through flooding [27], 6We consider physical isolation of reachable end-system s from strictly internal end-system s to be an overly restrictive solution. For m ost environm ents, it would infringe on internal com m unication and integration to an unacceptable extent. 10 Finally, even communication with equipped end-systems must be controlled at the network layer. Each time an unauthorized external user attem pts to communicate with an equipped end-system, stub AD network resources are consumed. Even if the end- system knows to reject the transaction, it is too late with respect to the expended network resources. In summary, if a stub AD wishes to control usage of its internal network resources (links, bridges, routers, and end-system network interfaces) it can not rely solely on the protection mechanisms in end-systems. 1.3.2.3 T ransit A D s Transit ADs are concerned with controlling usage of, and access to, their internal routers and links. Their policies may be based upon the source or destination AD, the previous or next hop AD, or other characteristics such as user classes, charge codes, or type of service [26]. Transit resources may be billed on a usage-sensitive basis. In addition, service quality is dependent upon adequate capacity to meet demand. Consequently, control of access to these resources is critical to their operation. As with stub ADs, transit resource protection can not be left to end-systems. By the tim e traffic reaches the end-systems, the communication resources would have been used. Moreover, in the case of transit ADs, the destination end-system is not w ithin the particular transit AD’s adm inistrative control and can not be expected to recover the transit AD’s costs. Furtherm ore, transit ADs should not rely on stub ADs to enforce transit policies; this represents an excessive compromise of transit ADs’ autonomy. Even if transit ADs are open to all paying customers, they need to monitor and charge for traffic. M onitoring and charging are just different types of network-layer control mechanisms. In any case, network layer controls are needed at the boundaries of transit ADs to protect against unauthorized resource usage and denial of service attacks. 1 .3 .3 R o u te s e le c tio n The last policy requirement faced in the multi-AD context is control of route selection. Different routes have different characteristics. For example, some routes may travel via ADs th at charge on a usage sensitive basis. Other ADs may be avoided because they are not trusted. Stub ADs may wish to express policies regarding the particulars of their traffic flows, i.e., where a packet can be sent, how it should get there, and which internal systems can originate it. Similarly, some ADs will want to enforce policies regarding 11 the routes taken by incoming traffic. Control of transit AD network resources and route selection are similar to the extent th at they both restrict access to transit resources. However, route selection is based on preferences of stub ADs, whereas transit ADs protect their resources on the basis of local policies. Therefore, a stub AD may need to control access to inter-AD routes according to their characteristics. Not all internal traffic sources will be given external access. Even those sources allowed external access may not be perm itted to use routes th at incur usage- sensitive charges. Still others may be perm itted to transm it only over routes composed of highly trusted ADs. Some AD destinations may even be considered off lim its to all outgoing traffic. These policies can not be enforced by transport layer protocols as routing is transparent to them. Hence, enforcement must take place at the level of internetwork routing and packet forwarding protocols. 1.4 D e sig n C h oices This section addresses the design of enforcement mechanisms to meet all three control requirements: end-system, network resource, and route selection. It begins w ith the discussion of applicable security services and proceeds to discuss appropriate enforcement locations, enforcement protocols, and granularity of principals. In the final subsection the object granularity and mode of enforcement are discussed. The results of our discussion are summarized in Section 1.4.6. 1 .4 .1 S e c u r ity S e r v ic e s The OSI model specifies fourteen security services [44]. (They are summarized in Table 1.1). These services, however, are not uniformly applicable to all types of objects: 1. End-systems Due to the variety of applications and services provided, end-systems are subject to a wide range of potential security threats. To counter these threats, end-systems may require all or most of the (fourteen) OSI security services. 2. Network resources (a) Stub ADs In order to prevent unauthorized access to their internal network resources and unauthorized export of traffic across AD boundaries, stub ADs need to 12 N o. IS O S e c u rity S erv ice A p p lic a b ility 1 Peer Entity Authentication Y 2 D ata Origin Authentication Y 3 Access Control Service Y 4 Connection Confidentiality N 5 Connectionless Confidentiality N 6 Selective Field Confidentiality N 7 Traffic Flow Confidentiality N 8 Connection Integrity with Recovery N 9 Connection Integrity without Recovery N 10 Selective Field Connection Integrity N 11 Connectionless Integrity Y 12 Selective Field Connectionless Integrity N 13 Non-repudiation at Origin Y 14 Non-repudiation at Delivery ? Legend: Y - applicable N - not applicable ? - potentially applicable Table 1.1: Applicability of ISO Security Services enforce access control policies. This entails the authentication of principals (peers) involved. Furthermore, since a compromised communication channel between an authorized pair of principals can lead to im proper usage of stub A D ’s internal network resources (i.e., compromised d ata still consumes stub AD network resources en route), data origin authentication and data integrity m ust be m aintained as well. Non-repudiation of origin may be needed if an AD needs to account for usage of network resources. On the other hand,, confidentiality of the end-to-end d ata is logically a function of higher protocol layers in end-systems. (b) Transit ADs Because transit AD network resources are similar to those of stub ADs (with the exception of end-systems) they are subject to the same security threats, and, hence, require much the same security services. As discussed later, dif ferences arise in other characteristics of policy enforcement. 13 3. Route selection policies can be thought of as access control restrictions with respect to internetwork routes. This requires authentication of the principals requesting ac cess to routes. Furtherm ore, it also requires authentication and integrity of routing inform ation provided by the transit ADs (because this routing inform ation is used to associate cost and security characteristics with computed routes). In summary, we are prim arily concerned with five security services: access control, peer entity authentication, data origin authentication, d ata integrity and non-repudiation. The remaining services may be of concern to some end-systems but, in general, are not affected by the particular issue of AD interconnection. Not surprisingly, the Standard for Inter operable LAN Security (SILS) recommends attention to these same five security services [42]. Moreover, the SILS document points out the inter-dependencies among these five services: access control on authentication and integrity, authentication on integrity, and non-repudiation on authentication and integrity. 1 .4 .2 E n fo r c e m e n t L o c a tio n One of the most critical decisions in the design of enforcement mechanisms is their physical location. We address the enforcement of network policies in the context of end-systems, border routers, and specialized servers. Internal AD routers (i.e., those th a t speak the AD’s interior routing protocol) are potentially large in number. Modification, in the form of additional access control mechanisms, raises concerns regarding the cost of im plementing and verifying system configurations, and interference of inter-AD protection mechanisms with intra-AD communication. In Section 1.3.2 we justified the placement of controls only in those routers th at act as points of connections to other ADs, i.e., the border routers. In determining the appropriate locations for the enforcement of specific policies, we based our decisions on the principle th a t, ideally, unauthorized resource usage attem pts should be detected before any resources have been consumed, i.e., at the earliest possible point. 1. E n d -sy s te m reso u rce s: equipped end-systems can be controlled by mechanisms in the transport and application layers. Controls for unequipped end-systems are placed with the stub AD’s network resource controls (see next item ). This is because no external traffic whatsoever should be allowed to reach these end-systems as they are assumed to be unprotected. 14 2. N e tw o rk re so u rces: Stub and transit AD network resources are both controlled by mechanisms located in the border routers of the ADs. Border routers may work in conjunction with servers (e.g., authentication and access control servers, policy servers, and route servers) th at will also enforce policy. Such servers are needed to i offload tim e and space consuming functions for performance-critical routers, and as a point of coordination and integration of policy. 3. R o u te selectio n : Stub ADs control access to routes within the route servers th at compute external routes and w ithin border routers th at may validate traffic. 1 .4 .3 E n fo r c e m e n t P r o to c o l I | Closely related to the enforcement location is the enforcement protocol. We consider mechanisms in the end-system transport (and higher layer) protocols, the internetwork packet-forwarding protocol, and the internetwork routing protocol. We distinguish be tween mechanisms implemented in the intra-AD protocols, and those required in the border router protocols only. 1. End-systems can protect themselves at any (or all) layers in the protocol hierarchy (transport layer being the most applicable). Of course, this only holds for the reachable end-systems th at are sufficiently equipped. 2. (a) The unequipped end-systems and the rest of the stub AD network resources are protected by the border routers as discussed above. Since ADs interconnect at the network layer and the network-layer p a c k e t-fo rw a rd in g protocol is the highest layer w ith respect to these resources, it is the most appropriate protocol for the enforcement of access restrictions to unequipped end-systems. (b) In order to protect network resources of transit ADs, access controls must also be incorporated into the network-layer ro u tin g p ro to c o l. This is necessary because, unlike stub AD policies, transit AD policies may prevent communi cation even when a viable route exists. If a stub AD’s policy disallows com munication, the user may be inconvenienced. However, the policy is having its desired affect. On the other hand, transit AD policies have more far-reaching im pact. The shortest route computed by a traditional routing algorithm may not be usable by a particular source due to a policy of one of the transit ADs. W ithout access to transit policy inform ation, the routing protocol has no means of finding an alternative, perhaps longer, route for th a t source. 15 As a result, transit ADs can not simply enforce policy restrictions on a unilat eral basis at packet forwarding tim e. Instead, policies pertaining to transit AD network resources must be either implicit in the topology of an internetwork, or advertised to the anticipated resource users as part of the network-layer routing protocol.7 3. Route selection policies are enforced at both border routers and route servers. In route servers, the enforcement protocol is the rou tin g p rotocol application th at computes internetwork routes and distributes them to appropriate end-systems. In addition, border routers have to validate route selection made by the route servers at packet forwarding time. The latter function needs to take place in the network-layer packet-forwarding protocol. 1 .4 .4 P r in c ip a l G r a n u la rity We refer to the subject of a security policy as a principal [79] (i.e., a principal is perm itted to access, or is restricted from accessing a particular object). Policies may be applied to ADs as a whole, to user classes th at are location-independent, to particular end-systems within ADs, or to particular users or user processes. The coarser grain policies (i.e, those based on AD or user class) are easier to manage but, by definition, less precise. Of these policies, ones based on user classes are more difficult to implement, but offer flexibility of grouping users independent of the physical location. The difficulty arises from having to bind a user or user class to lower-level units of communication, i.e., packets. Whereas packets routinely include end-system addresses th a t can be m apped more easily into AD addresses through existing mechanisms. 1. For policy enforcement at the end-system level, the choice of principal granularity depends on the protocol layer. Since end-systems can implement controls at several, protocol layers, principals of different granularity can be specified. For example, end-systems at the transport layer and application protocols or users at higher layers. 2. The ends-points of inter-AD communication with respect to stub AD network re sources are the end-point stub ADs This implies th a t the principal granularity for stub AD access control should be at the level of ADs or user classes. However, 7A s argued in [7], it is difficult to reflect a rich set of policies in the topology when the internetwork is of this scale and heterogeneity. 16 as mentioned before, network resources of stub ADs include the unequipped end- systems. To preclude all access to these end-systems, it is necessary to discriminate incoming traffic on the basis of the end-system destination address. Therefore, principal granularity for stub AD network resources may be end-system as well as AD. 3. Since transit ADs provide communication facilities for large numbers of stub ADs, it is im practical for their resource usage policy to specify fine-grained principals such as end-systems.8 Therefore, the subjects of transit resource policy enforcement are expected to be ADs and user classes. 4. For route selection policies, we must consider the granularities of the two end-point (source and destination) principals. They may be the same (e.g., a single route between a pair of ADs) or they may differ, e.g., a policy may prescribe a specific route for a given {end-system,destination-AD} pair. It is expected th at most route selection policies will restrict based on source AD (or user class) and destination AD. 1 .4 .5 C o m m u n ic a tio n G r a n u la rity a n d E n fo r c e m e n t M o d e Policies may be applied to communication units of different granularity. In particular, there are tradeoffs associated w ith implementing controls per packet, per end-system association (i.e., connection), and per AD association. We also consider the appropriate ness of using a priori (preventive) or post facto (accounting) detection, of unauthorized resource use, in the context of different policy objects and security services. 1. At the end-systems, the granularity of controlled communication units depends on their reachability. For the reachable end-systems, granularity depends upon the particular enforcement protocol. For example, per-packet at the network layer, and per end-system association at the transport layer. Regardless of the protocol, the mode of enforcement has to be preventive (at real-time) since end-system disruption can not usually be tolerated. Access control for unequipped end-systems has to be done on a per packet preventive basis in border routers. This is because even a single packet can disrupt these unprotected end-systems. 8 Transit A D s are also more likely to bundle usage charges on the basis of A D s rather than end-system s. 17 2. It is less straight forward to determine the appropriate basis for protection of other stub AD network resources. If reachable end-systems implement controls, and ex ternal traffic to unequipped end-systems is prevented at AD boundaries, the only j potential for unauthorized use of stub AD network resources is the compromised i traffic addressed to reachable end-systems. Such traffic consumes network resources ' en route.9 However, authenticating the origin and checking data integrity of every incoming packet may be expensive in term s of performance and im plem entation. | Thus, some ADs may elect to allow for some unauthorized resource usage of this sort in return for faster packet switching in border routers, while others may go to the trouble of scrutinizing every packet to assure non-interference of compromised traffic. In summary, for network resources other than end-systems, both real-time and post facto (accounting-based) detection methods can be used. 3. For transit AD network resources, the communication unit granularity is dependent upon the particular security service. It is im practical to control access on the basis of packets or end-system associations due to potentially large numbers of them . It is more manageable to apply enforcement to stub AD associations. Because AD-pair associations are coarse-grained (i.e., can encompass large volumes of packet traffic), establishm ent of such associations may be verified and validated by intervening transit AD. However, due to the potential risks involved, this type of enforcement should be addressed using preventive methods. Once a stub AD-pair association is validated by a transit AD, individual data pack ets must be associated with a particular AD-pair, e.g., to pass charges appropriately. ■ The im plication is th a t at least some enforcement must take place on per-packet basis. One possible scenario is to enforce certain inexpensive controls (based on addressing and/or route) in real-time, (i.e., w ithout expensive data authentication and integrity checks), combined w ith bulk packet-based accounting to later detect fraudulent (or unaccounted for) resource usage. In summary, the design choices of object granularity and enforcement mode are more context-dependent than are enforcement location, protocol, or principal granularity. j 9However, it poses no direct threat to end-systems, as they are snfficiently protected. ,18_ 1 .4 .6 S u m m a r y We conclude this section with the results of the above discussion summarized in Table 1.2.10 Resources Security services Enforcement location Enforcement protocol Principal granularity End-systems All End-systems, Access Control Servers Transport and above Any Stub AD Network Resources 2,3,11,13 Border Routers, Access Control Servers Network End-system, AD, user class Transit AD Network Resources 2,3,11,13 Border Routers, Access Control Servers Routing AD, user class Route Selection 2,3 Border Routers, Route Servers Routing and Route Com putation Any Table 1.2: Policy Enforcement Param eters 1.5 C o n clu sio n s In conclusion, an integrated view of access control is needed in an environment of in terconnected ADs in order to achieve effective and efficient placement of function for different types of policy, and to define consistent policies across the many network ele ments, protocols, and servers th at are involved. In this chapter, we proposed a framework for placement of access control functions. We applied the original end-to-end argum ent to network resources and concluded th at resources other than sufficiently protected end-, systems are best protected at the border routers. This argum ent is reinforced by the increasing concerns with respect to resource usage feedback and cost recovery th at are raised by the commercialization of internetwork transit facilities [33]. 10We exclude the issues discussed in Section 1.4.5 because the suggested approach is very context- dependent and does not lend itself to accurate representation in a table. 19 1.6 O v erv iew o f T h is T h e sis The rem ainder of this thesis is organized as follows. Chapter 2 begins by reviewing and discussing related research in policy enforcement. We concentrate on two areas: i) network security and internetwork access control, and i) internetwork routing. Subsequently, in I the second part of the chapter, we identify and discuss several basic support mechanisms used as building blocks in our design. C hapter 3 addresses stub AD policy enforcement mechanisms. We introduce Visa i protocol for controlling packet traffic at stub AD boundaries; its main purpose is the establishment of authorized and authenticated end-system associations. The key features of the protocol are: • A special ticket, called a visa is required for communication outside an AD. • Only select end-systems (those th at are sufficiently protected) are granted visas. t • Access Control Servers in both end-point ADs m ust authorize communication before a visa is issued. • Visas are distributed to the authorized end-systems and border-routers in the end point ADs. • Every packet th at attem pts to leave or enter an AD is expected to be stam ped with a valid visa thereby proving its authenticity. After describing the protocol and discussing numerous design issues, we analyze its secu rity and associated overhead costs. Chapter 4 is concerned with controlling access to transit AD network resources, i.e., control of transit internetwork traffic. It begins by attem pting to extend network access control methods to control of transit traffic. In response to some fundam ental deficiencies of existing approaches, we conclude th at novel protocols are necessary in order to address the problem effectively. Such protocols are embodied in the Inter-Dom ain Policy Routing (IDPR) architecture which is used as a springboard for our design. ID PR has the following key features: • Each AD expresses its policy in Policy Terms (PTs) which are disseminated to all other ADs along with the inter-AD topology information. • Individual end-system connection are aggregated into coarser-grained Policy Routes (PRs). A P R is an AD-level source route th at also includes PT s necessary to make policy authorization decisions in transit ADs. 20 • PRs are installed (and authorized) in all intervening ADs before any communication can take place. • Since the ’’expensive” p art of policy enforcement is done at P R installation time, subsequent d ata packets encounter little scrutiny, i.e., delay. After identifying a number of security issues and threats facing ID PR, we specify se cure P R setup and packet forwarding protocols, analyze their security and address the performance costs. C hapter 5 supports the choices made in our protocol design by dem onstrating and evaluating experimental results obtained from prototype im plem entations of protocols proposed in Chapters 3 and 4. In conclusion, C hapter 6, reviews the contributions of this thesis and discusses topics for future research. 21 C h a p ter 2 B ack grou n d This chapter sets the stage for protocol design by reviewing related work in network security and internetwork routing and identifying the inadequacies of the existing policy enforcement approaches. It also discusses a number of support mechanisms th at are employed throughout the rest of this thesis. 2.1 R e la te d W ork Policy enforcement is not an entirely new subject. Much effort has been put into the enforcement of certain types of policy, especially, access control in stub AD environments. Most of the related work comes from two areas: Network Security and Internetwork Routing. Previous results in these two areas form a solid background for the design of stub and transit policy enforcement, respectively. 2 .1 .1 N e tw o r k S e c u r ity Research in network security dates back to the mid-seventies when com puter networks first began to proliferate. There has been a lot of research in the field, as evidenced by the enormous am ount of literature. It is impossible to treat all of it thoroughly; related work considered below was selected for being the most applicable to the subject of this thesis. Since early networks were, for the most part, technically and adm inistratively homo geneous, security issues concerned basic services, such as session and user authentication, data integrity and confidentiality. In their pioneering work [67], Needham and Schroeder introduced third party authen tication protocols based on both conventional and public key encryption. The purpose of these simple, but elegant, protocols is to allow the establishment of a secure channel 22 between two m utually suspicious principals by providing them with a shared secret, th at can consequently be used a session key. The protocols make use of a trusted A uthentica tion Server th at shares pairwise keys with all principals and can be trusted to to generate good session keys. Variations of the Needham-Schroeder protocols are used in existing control mecha nisms, most notably, Kerberos A uthentication Server[85]. I Voydock and Kent in [90] treated security in high-level network protocols by con- I si dering a broad range of security risks and possible attacks and suggesting a number of iencryption-based countermeasures. Their main contribution lies in outlining the relation ship between cryptographic and network protocols in the context of structured protocols such as the OSI reference model. In the late seventies, the DARPA Internet1 evolved into the first truly heterogeneous, jdynamic internetwork [12]. This prom pted increased concern w ith access control across autonomous network boundaries. This subject and other security-related issues in inter-organizational setting were first discussed in a series of papers by Estrin [24, 25]. The main contribution of this work is twofold: i) it identified a number of issues th a t set inter-AD access control apart from the ; more traditional access control scenarios and dem onstrated the need for network-layer i controls, and ii) it suggested a range of possible solutions, some of which later served as the basis for protocol design in this thesis (e.g., Visa Protocol [24, 32]). At the same tim e, (non-military) government agencies became aware of the security is sues and produced a number of reports and guidelines, m ost notably, a paper by Gomberg describing a model for inter-adm inistration network authentication and access control[38]. Also, work by Nessett at DOE analyzed the security implications of the heterogeneous network administration[69]. A subject th a t received a lot of attention is the authentication of principals in a suspi cious distributed system environment. In particular, a paper by Birrell et al. presents an authentication service w ithout global tru st[6]. However, since the same (rather elaborate) authentication mechanism is prescribed for use by all intended participants, autonomy and flexibility are sacrificed. Another authentication scenario for a distributed system environment is described by Sollins[83] in the paper on cascaded authentication. In it, authentication between parties not enjoying m utual tru st is achieved by chaining pairwise authentication between adjacent parties th at enjoy such trust. 1 Hereafter referred to as sim ply Internet. 23 For the most part, interconnection of autonomous networks takes place at the net work layer to provide datagram-level connectivity. (Interconnection at higher layers is possible commensurate w ith losses in performance and flexibility. A comparison between network and higher-layer access control approaches can be found in [25]). At the network layer, communication between a pair of end-systems in different ADs involves traversing a sequence of (at least two) network-layer border routers. Therefore, more than two prin cipals would have to be involved in network-layer policy enforcement. For this reason, m ethods described above are not applicable to access control across network-layer AD boundaries. One m ajor effort to provide network-layer access control for the internetwork envi ronm ent is the Security Protocol 3 (SP3) [81]. SP3 originated from a larger project, Secure D ata Network Systems (SDNS), overseen by the N ational Security Agency.2 The goal of SP3 is to provide transparent security services (connectionless confidentiality and integrity, access control and d ata origin authentication) for the constituent end-systems. SP3 is implemented in so-called SP3 systems, each SP3 system serves a set of end-systems. (An SP3 system can be viewed as a border router). Because it is decoupled from the end- systems, SP3 assumes a trusted path between an end-system and its SP3 system. Since individual end-systems are not authenticated, SP3 does not (as specified) protect against m asquerading attacks. Furtherm ore, SP3 has no facility for on-demand association es tablishm ent between SP3 systems with no history of previous communication. Last (but not least), SP3 is not specified to detect replay attacks, i.e., duplicate or out-of-order packets. An instantiation of SP3 architecture is the The Blacker system[5].3 It is is a hardware unit designed to secure user traffic in sensitive packet networks. It protects data from disclosure during transit, ensures correct identification of packets by address, and enforces security labels. Another workable approach is Visa protocol [32, 27], a network-layer mechanism for establishing authorized and authenticated inter-AD network connections. (A simpler and less secure variant using packet filtering is described in [61]). In ISO parlance, Visa protocol provides connectionless integrity, data origin authentication and access control services. It involves Access Control Servers (ACSs), border gateways and select end-systems (those th at are allowed external access). Before an inter-AD connection is established, both end-systems must be authorized and authenticated by their respective 2In cooperation w ith several other government agencies and private corporations. 3The name refers to the proverbial black box. 24 ACSs. After establishing authorization, ACSs jointly issue a visa to the requesting end- systems. The same visa is distributed to the border routers in each AD. A visa is a certificate authorizing two end-systems to communicate. Included in a visa is a visa-key, a secret quantity which end-systems use to sign subsequent d ata packets. Intervening tborder routers authenticate d ata packets by verifying packet signatures. We describe | Visa protocol in greater detail in C hapter 3. I 2 .1 .2 A d hoc M e th o d s In order to further m otivate the need for a comprehensive policy enforcement architecture, this section reviews some simple, ad hoc stub AD access control m ethods currently in use. Some are direct applications of the related work described in the previous section. • Physical isolation Physical isolation of externally accessible resources is, by far, the simplest and the most drastic of all methods. It requires configuration of a separate network and increased end-point security for all externally accessible resources. While this provides perfect security (only in a sense of separation) communication between externally accessible and internal resources is impossible. It also requires th a t every distinct set of externally accessible resources be isolated, an im practical task in case of multiple overlapping sets of externally-accessible resources. • Protection of all internal resources If stronger security mechanisms are incorporated into all internal resources, pol icy can be enforced, but at the price of infringing upon intra-AD communication. Moreover, when the set of externally-accessible resources is small as compared to the rest of the AD, this becomes a highly im practical approach[24]. • Application-specific filtering If traffic is restricted to a specific application, e.g., mail or voice, application-specific filters can be build to implement this policy. In general, however, a separate filter m ust be built for each application anticipated[61]. Moreover, performance overhead of application-level filtering may prove prohibitively high, especially, for throughput- oriented applications, e.g., real-tim e voice and video[25]. • Access control lists If external access is confined to a relatively static set of entities, access control lists can be used, once again, to filter traffic. Unfortunately, this will not accommodate 25 dynamic requirements. In addition, list-based filtering is subject to spoofing as network addresses can be easily modified. • Bilateral policy agreements Two or more ADs can always agree out of band to follow a specific policy or agree on a set of policies. Such an agreement may include adopting a common charging scheme or a common authentication protocol. This can work for a lim ited number of policies, but requires th a t autonom y be sacrificed. I Any of the above m ethods can be effective under special circumstances. Their main l | flaw is the lack of flexibility. Each addresses a small subset of possible policies, while ] compromising performance, flexibility or autonomy. 2 .1 .3 In te r n e tw o r k R o u tin g Network routing has received a lot of attention since the late fifties as evidenced by the enormous am ount of literature in the field. Several fundam ental routing algorithms were developed, most notably, D ijkstra’s Shortest P ath [22] and Ford and Fulkerson’s Max Flow algorithm s [35]. The former gave rise to a family of routing protocols known as link state, and the latter, to a collection of protocols known as distance vector. Link state protocols are characterized by each node keeping a ’’m ap” of the entire network over which it computes shortest paths to all destinations. Each node contributes to this ’ ’m ap” by flooding the network with a link state packet, i.e., a packet th a t contains the status of all incident links. In distance vector protocols, nodes keep tables of the best paths and associated metrics for all possible destinations and periodically exchange the contents of this table with neighbors. As m entioned before, the DARPA Internet evolved into the first large, decentralized and dynamic datagram network. At first, its routing protocol was of a distance vector variety, as described in [55]. However, as the network grew, shortcomings of the distance vector became more apparent. Frequent oscillations and otherwise unstable behavior th at it exhibited were due mostly to long propagation delays with respect to changes in topology. The successor [56], was a link state protocol with a relatively short convergence period and looping avoidance. Neither protocol incorporated any notion of security or policy. As the Internet grew, it began to encompass a greater number of autonomous net works, or ADs, using our terminology. W ith regard to routing, this growth presented two problems: 26 • A u to n o m y while electing to become p art of the Internet, ADs do not necessarily wish to expose their internal network structure to the rest of the world. In other words, there is a need to lim it the dissemination of routing information. I • Scale the size of the Internet makes the deployment of a global routing protocol unde sirable. Since routing inform ation is typically propagated throughout the entire domain of a routing protocol, routing tables in participating gateways grow in pro portion to the size of the Internet. Therefore, in order to avoid an information explosion routing inform ation granularity m ust be coarser than end-systems or net works. In response to these problems, two types of routing protocols were defined: • Interior G atew ay P ro to co ls (IG P s) are intended for use w ithin a single admin istrative entity, i.e., AD. Routers employing an IG P exchange reachability informa tion pertaining to entities within an AD [65]. • E xterior R o u tin g P ro to co ls (E G P s) are used by AD border routers to learn about reachability of networks in other ADs [65]. (We discuss EGPs in the following subsections). Some of the notable IG Ps are: IGRP [40], OSPF [62] and DEC IS-IS [21]. IGRP, a distance vector protocol, supports ToS routing indirectly by distributing several different m etrics (e.g., delay, bandw idth). Routers assign a weight to each m etric before combining them into a single composite m etric which then serves as a basis for ’’shortest” path selection. Both OSPF and IS-IS are links state protocols. They may include a number of metrics corresponding to different ToSs in link state updates. These IG Ps are well-suited for their intended application dom ain, i.e., a single-AD environment. However, they do not scale to a large num ber of ToS-s and require route com putation to be repeated for each ToS supported [7]. In addition, most IGPs are designed with little concern for security as components are assumed to share a certain level of trust. This assum ption is unreasonable in a multi-AD environment where routing inform ation may not be ’’trusted” across AD boundaries. 27 2.1.3.1 E xterior G atew ay P ro to co l As the Internet incorporated a more diverse organizational mix, coexistence of multiple adm inistrations (and the associated security implications) was recognized as an im portant problem. The Exterior Gateway Protocol (EGP) [77] was the first routing protocol to address this issue.4 EG P was designed to communicate reachability inform ation among adm inistrative regions th at do not enjoy m utual trust. It includes an authentication facility for validating routing inform ation exchanged among the regions. The regions hooked together by EG P can be viewed as ADs. EG P supports a very limited notion of policy. Individual ADs are allowed to hide :portions of their routing database th at they are not willing to share. Also, ADs are free to m anipulate route metrics th at they assign to other ADs in order to favor or preclude certain transit AD hops. However, EG P does not provide for ToS-based or other fine grained policy enforcement. In E G P, an AD makes routing decisions based only on its own policy, since EG P provides no facility for the distribution of policy inform ation across AD boundaries. Furtherm ore, in order to avoid routing loops EG P imposes a topological restriction on AD interconnection in the form of a cycle-free hierarchy. As Clark points out in [13], E G P ’ s restriction on the interconnection topology has proved unsatisfactory. In general, topological restrictions are undesirable as they inhibit autonomy and are near impossible to enforce [7, 26]. 2.1.3.2 B ord er G atew ay P ro to co l BGP is a recently proposed addition to the Internet Protocol fam ily[53]. It was designed to be a successor to EG P and a variant has been subm itted as an international standard[2]. Its foremost goal is to provide efficient and robust Inter-AD routing w ith rapid conver gence and loop detection for arbitrary internetwork topologies.5 It is prim arily intended for use by transit ADs and inter-operates w ith other interior routing protocols. BGP is designed under the following assumptions: 4 In this section, th e term E G P denotes a specific protocol. W hereas, EGP, as referred to in the previous section, denoted a c la ss of protocols. 5BG P and E G P use the term Autonomous System and Routing Domain, respectively. We use the term Adm inistrative Domain. They are not com pletely equivalent but, for the sake of this discussion, they can be interchanged. See [54, 26] for further discussion. 28 1. Policies can be expressed using inform ation about the full AD path th a t packets will travel to a destination. 2. Transit policies apply uniformly to all sources. BGP uses hop-by-hop routing and a distance vector algorithm for the next hop selection [55]. One common benefit of traditional distance vector algorithms is the ability to hide network structure. Neighboring nodes exchange reachability inform ation for a specific destination in the form of distance metrics corresponding to each next hop. Nodes do not exchange inform ation about subsequent hops to the destination. BGP augments this traditional approach by distributing full AD-level paths. In other words, for each destination advertised, nodes specify the AD-level path to th at destination. As a result, BGP provides less information hiding in return for the ability to detect routing loops quickly. By using full AD paths to detect loops BGP avoids convergence problems [56] w ithout imposing topological restrictions on AD interconnection. In addition, AD path inform ation can be used as policy criteria for route selection. BG P allows for lim ited policy-based route selection. A BGP router can select its next hop based on the inform ation provided in the full AD path, in addition to the distance m etric. For example, AD a can reject all routes through A D b - On the other hand, each AD m ust apply the same route selection decision to all packet sources, including itself. For example, A D a can not reject all routes through A D b for itself without affecting its neighbors, and vice versa. Similarly, an AD can not apply one policy to one neighbor and a second policy to another neighbor. Since BGP was not intended to implement policies th at discrim inate between traffic end-points with arbitrary granularity, the approach achieves its goals [53]. Each BGP router can be configured according to its A D ’s local policy. Even though local policy is not distributed among ADs, it is represented in a universal policy language. A policy in this language is an expression: [Ne twork-list,A D-pa th]— p refe rence The semantics of a policy are as follows: if a routing update for a network in Network- list is received via AD-path and its preference metric is better than th a t of a path currently in use, then, this update must be used for subsequent routing. 2.1.3.3 In te r-D o m a in R o u tin g P ro to c o l Inter-Dom ain Routing Protocol (IDRP) is an extension of BGP th at has been proposed as an international standard. IDRP augments the BGP protocol by including (among other 29 features) distribution lists along with route inform ation [2]. The list may be inclusive or exclusive and is propagated along with next hop and full-AD path information. Each border router along a path may further restrict a distribution list before advertising a route, i.e., ADs may be deleted from the inclusive list or added to the exclusive list but mo router can relax or ignore the list.6 This feature allows IDRP to support some source- specific policies. However, IDRP has no built-in support for enforcing source-specific jpolicies at packet forwarding time. Another departure from BGP is the ID R P ’s ability to include policy-related (e.g., ToS or User Class) inform ation in routing updates. IDRP is thus able to support a wider range of policies than BGP. Nevertheless, because IDRP is a hop-by-hop protocol, it only allows a single route per every [destination, ToS] to be advertized. However, multiple routes for a given [destination,ToS] combination may be necessary in order to allow traffic sources to apply route selection policies. (See [7] for an in-depth discussion of this and other related issues). 2.1 .3 .4 R ou tin g w ith M u ltip le H ierarchical A d d resses A novel approach to policy routing is the use of multiple hierarchical addresses (MHA). In [87], Tsuchiya suggests th at multiple addresses be assigned to end-systems (stub ADs, in our parlance). A single address is formed as [stub.regional.backbone] indicating th at the corresponding route: [backbone =>• regional = > stub] satisfies the policies of its component ADs. A given end-point may have a number of such addresses differing in the regional and/or backbone fields. Routing in this approach can be viewed as a variant of source routing. More specifi cally, a route between A D a and ADb is the combination of AD a s address and the inverse of AD bS address, e.g., A D a.regional\.backbone\ followed by backbone2 .regional2 .ADb- To route a packet, a stub AD simply selects (according to its policy) one of the addresses for the intended destination. The main benefit of MHA is its simplicity and low overhead with regard to route com putation. There are a few im portant drawbacks, though. F irst, a shallow (three- level) hierarchy is assumed. As pointed out above, such restriction is undesirable for two reasons: i) lateral and bypass links must be supported as the Internet is not expected to conform to a strict hierarchy, and ii) even if a strict hierarchy is possible, lim iting it to three levels may be inadequate in the context of a global Internet. A related problem 6T he proposed standard includes severed other extensions which are not directly relevant to our discussion. 30 is the assum ption regarding backbones. If the backbone components of a route are not identical, multiple transit backbones have to be traversed. Such backbones, however, are not included in either of the two addresses. Consequently, policy enforcement is severely lim ited from the perspective of the end-points (since transit backbones are hidden) from them . Conversely, transit backbones, not included in the ’’route” must enforce their policy on a per-packet basis, i.e., they are denied any opportunity of restricting traffic in advance of actual communication. 2.1.3.5 I D P R Routing protocols discussed thus far have been developed w ith lim ited concern for policy enforcement. Designed w ith more conventional routing in m ind, these protocols either impose topological restrictions and do not scale well (e.g., E G P ), or can not support large numbers of diverse and dynamic policies (e.g., BGP, IDRP and MHA). In his landm ark paper, Clark [13] first m otivated the need for the integration of policy support into the routing function and presented a blueprint for policy routing in the Internet. The Internet Inter-Dom ain Policy Routing Working Group (IDPR-W G) has since developed an architecture for Inter-Dom ain Policy Routing (ID P R )7 th at is largely based on C lark’s policy routing proposal. ID PR represents a significant departure from the more traditional routing protocols. In brief, the distinctive features of ID PR are (we discuss ID PR in greater detail in Chapter 4.1): • P o lic y T e rm s ( P T s ) are units of policy expressed in a universal policy syntax. Every AD includes its PTs in a link state update which it distributes to all other ADs via a flooding mechanism. • P o lic y R o u te s (P R s ) are source routes at the granularity of ADs. A PR is computed by a source AD and then installed at all intervening ADs in advance of the actual communication. Subsequent d ata traffic flows along established PRs.8 ID PR was designed to support a wide range of policies while alleviating global consistency requirements. Stub ADs enforce their policy at the tim e of route com putation. Transit ADs advertize their policies to their stub counterparts th a t, in turn, use these policies 7N ot to be confused w ith IDRP. For the record, ID P R was named first! 8T his bears som e resemblance to a traditional virtual circuit m odel. However, w ithout packet sequenc ing or reliable delivery. 31 to compose PRs. Transit policy enforcement takes place when PRs are installed at the transit AD hops. ID PR supports the following policy attributes: source and destination ADs, previous and next AD hop, Quality-of-Service, Time-of-Day, User Classes, authentication and , security requirem ents, and charging conditions. In return for this functionality, ID PR ! presents a number of challenging problems relating to complexity and scale [7]. In C hapter 4, we discuss ID PR in greater detail concentrating on security aspects of its policy enforcement mechanisms. 2 .1 .3 .6 Secure and R ob u st R ou tin g At an extreme of robustness and security is Network-layer Protocol with Byzantine Ro bustness (NPBR) by Perlm an [71]. N PBR concepts are suitable for use as either IGP or EGP, mainly because it makes no assumptions about trust among its components. N PBR comes in two flavors: flooding and link state. Flooding N PBR is a highly- robust protocol where communication between two nodes is guaranteed as long as there exists a non-faulty path between them . This robustness is achieved at the expense of: (1) flooding d ata packets, (2) per-packet public key encryption at every hop, and, (3) significant state in routers. The value of this protocol is largely theoretical as it illustrates the lim its of achievable network-layer robustness and security. Link state N PBR is slightly less robust. It guarantees communication between two nodes as long as there exist n node-disjoint paths between a given pair of nodes, and at m ost (n-1) node failures exist simultaneously in the network. Reduced robustness in link state N PBR is counter-balanced by the use of a link state protocol in conjunction with source routing. Link state update dissemination is performed using highly-robust flooding NPBR m ethod, whereas d ata packets are source-routed. This design, while still quite costly, dem onstrates some useful techniques: • Public key signatures for link state updates to defend against tam pering and repu diation of origin. • Per-node nonwrapping sequence numbers to achieve replay detection and packet reordering. • End-to-end and hop-by-hop packet delivery acknowledgements to determ ine dy namically the status of links and nodes traversed by a packet. In C hapter 4, we take advantage of these techniques in our design of secure transit policy enforcement. 2.2 S u p p o rt M ech a n ism s This section briefly addresses a number of common support mechanisms used as basic building blocks in our policy enforcement protocols. 2 .2 .1 E n c r y p tio n a n d S ig n a tu r e S u p p o r t Protocols th at implement security services for policy enforcement will have to make use of encryption to support authentication, d ata integrity, and confidentiality (if applicable). Two dominant types of encryption are: conventional (or symmetric) and public key. Conventional cryptography has been in use for quite a long tim e [49]. Typically, it involves a function and a single key used for encryption, as well as decryption, of data. The key m ust be shared among every group (usually, of size two) of principals wishing to communicate in secret. The best-known (if not the most notorious) of the contem porary conventional cryp tosystem s is the D ata Encryption Standard (DES)[66]. It is, at present, a United States jstandard which makes it (and a number of derivatives) the most widely used cryptosys tem. Some conventional cryptosystems are also suitable for generating digital signatures, e.g., FEAL-8 [82] and DES [66]. A digital signature is a value th at, when attached to a message, proves th at the message has been generated by a party in possession of the key used in the signature com putation. For the most part, conventional cryptosystems lend themselves to efficient implemen tations and are able to reach encryption rates of several megabytes per second (thereby m atching some LAN speeds). On the other hand, conventional cryptography has several drawbacks: • Sharing a distinct key for every pair of principals makes key management extremely difficult (N 2 keys are required for N principals). • An unfortunate consequence of key sharing is the inability of attributing encrypted messages to a single principal. In other words, a message encrypted (or signed) with a shared key can be generated by any of the (at least two) principals in possession of this key. 33 • Finally, authenticated m ulticast and broadcast communication is rather laborious. In order to send a message to a group of N principals, the sender must produce N distinct message signatures, one for each intended recipient. Public key encryption9 addresses some of the drawbacks of conventional encryption. In a public key cryptosystem , each principal is associated with a unique key-pair. A key- pair consists of a public (encryption) and a private (decryption) key. The former is made available to anyone who wants to communicate with the principal in question, while the latter is kept secret. Encryption is performed with the public key, and decryption with the corresponding private key. The m ost im portant feature is th a t, given a principal’s public key, computing the corresponding private key is com putationally infeasible.10 The best-known example of a public-key cryptosystem is the RSA [76]. In RSA, the | difficulty of attacking the system is equivalent to factoring large numbers. RSA has been | extensively researched and scrutinized in the past and is considered one of the most secure j cryptosystems available. Another example of a hereto unbroken public key cryptosystem ! is the El Gamal scheme[23] which is very slow (even by public key standards), but well- 1 suited for certain specialized tasks, e.g., key distribution.1 1 j Public key encryption addresses many of the conventional encryption’s drawbacks. • Since a principal only needs a single key-pair, key m anagement is no longer a prob lem. • A principal generates signatures w ith a private key known only to it. Therefore, there is no ambiguity in tracing a signed message to its origin. • A uthenticated m ulticast or broadcast are easily achieved by a single message sig nature computed with the sender’s private key. Any of the intended recipients can authenticate the origin and the contents of the message by verifying the signature w ith the help of the sender’s public key. In return for all the benefits it provides, public key encryption takes a heavy toll in terms of performance. As compared to its conventional counterpart, public key encryption is extremely slow. M ethods for reducing the high cost of public key encryption have been proposed. Specifically, in RSA, the cost of signature com putation (with private key) is roughly the 9First proposed by W . Diffie and M. Heilm an in 1976 [20]. 10D erivation o f a private key from its public counterpart is usually equivalent to solving a hard, e.g., N P-com plete, com putational problem [20], 11 El G am al’s slowness is due to exponentiation com plexity and expansion in ciphertext size. .34 sam e as the cost of signature verification (with public key).12 For example, Privacy- Enhanced Mail[51] uses a scaled-down version of RSA where signature verification is significantly less expensive than signature com putation. This is accomplished by using large private keys in conjunction with relatively small public keys. In order to avoid the respective drawbacks and combine the respective benefits, con ventional encryption is frequently used for data integrity and confidentiality (encryption), while public key encryption is reserved for session key distribution and authentication. The end-result is a hybrid cryptosystem. In the context of policy enforcement, public key encryption is particularly useful for disseminating routing inform ation, especially in the form of link state updates [71]. A link state packet can be signed once by its originator and the signature can be easily jverified by all potential recipients, assuming th a t the originator’s public key is readily available. Also, as described in the next section, inter-AD associations can be established I |Using public key certificates. Conventional signatures are especially well-suited for data Integrity once the relevant principals are authenticated. As discussed in Chapter 1, confidentiality is not a relevant security service in the context of policy enforcement, hence, applicable security services do not require bulk en cryption. Message signatures suffice for origin authentication and d ata integrity services. It is not necessary to sign the entire message [17]. Instead, a short (e.g., 128-bit) digest of a message is produced and then signed, thereby greatly reducing the costs. The security of this type of signature is dependent on the digest com putation function, usually referred to as a hash function. A strong (or one-way) hash function m ust have the following properties: • It m ust be com putationally difficult to find two messages th a t hash to the same digest. • It m ust be com putationally difficult to find a message th at hashes into a given digest. In practical term s, it is im portant for a hash function to lend itself to fast im plem enta tions, at least an order of m agnitude faster than the signature function. In recent years, some hash functions conjectured to be one-way have been proposed. Some have been successfully attacked, e.g., Merkle’s SNEFRU [57, 3]. O thers, such as Rivest’s MD4 and MD2 [75], appear to be more resilient. (MD4 is discussed in detail in Appendix A). 12 Usually, both keys are of equal (or near-equal) length. 35 The use of hash functions for message authentication entails signing only a short fixed-length message digest value. Nonetheless, encryption-based signatures are still quite expensive. In Appendix A, we describe two methods of encryption-free message authen tication based entirely on the use of one-way hash functions. (A similar scheme was developed independently by the Internet Security and Privacy Working Group [36]). 2 .2 .2 C e r tific a tio n Our internetwork model assumes a very large number of interconnected ADs. Assuming th at all ADs participate in a global public key encryption scheme, each AD would need to have reliable knowledge of all other ADs’ public keys in order to support arbitrary communication patterns. Moreover, a global, secure key m anagem ent scheme would be necessary to distribute, grant and revoke, keys. Overhead due to both storage and main tenance makes this scenario rather undesirable. Nonetheless, since policies are most often based on AD allegiance, principals must have means of proving their identity. Principals include the various AD-level servers: Access Control, Route, Policy, Name and Time to nam e just a few. To allow for more dynamic, yet secure, on-demand binding between names and public keys, a technique known as certification is used.[37] Certification is performed by well- known trusted Certification A uthorities (CAs). Included in a certificate is a name (e.g., a DNS name [60] or an X.500 distinguished name [10]) and a corresponding public key. A certificate also contains the name of the issuing CA, and the expiration date and time. Most im portantly, a certificate is signed with the private (secret) key of the issuing CA. All interested parties are thus only required to possess the CA’s public key as opposed ! to a m ultitude of principals’ public keys. j In the simplest case, there is a single universally trusted CA. However, in a hetero- igeneous internetwork environment, it is unlikely th at a single CA will suffice for reasons jof scale and policy. A more realistic scenario is the CA hierarchy as described by Gasser et al. in [37]. For example, a worldwide internetwork may require at least a four-level hierarchy. The top level CA is responsible for certifying individual countries’ CAs which, in turn, certify ADs in their domain. Bottom m ost, AD-level CAs may be employed to certify constituent users and end-systems. In this model, an association between two principals (A and B) is established as follows. If A and B are under the jurisdiction of the same CA, A forwards its certificate to B and B verifies the signature and the expiration time. (The procedure is then repeated w ith B sending its certificate to A). Otherwise, the least common ancestor (LCA) in the 36 CA hierarchy is established. Then, A supplies B with not one, but a list of, certificates starting w ith A ’s own certificate and ending with the certificate of the LCA. Since B is able to verify LCA’s certificate, it iterates through the list of certificates culm inating with the verification of A ’s certificate. Certificates are currently being used in Privacy-Enhanced Electronic Mail (PEM ) [51]. PEM certificates are used for proving identity of mail message originators. Certificates can be obtained from either a private company (RSADSI) th at manages the PE M ’s authentication hierarchy for a fee, or an organizational notary (ON) who will vouch for people in an organization. (ONs are under contract to only issue Certificates legitim ately). This approach is well suited for the distribution of signed routing updates and for route setup. Key distribution will involve route servers and border routers and will be a t a coarse granularity of ADs. Public Key certificates can be used to identify ADs th at have no previous history of association. For example, a source AD can include its public key certificate as a part of route setup when one (or more) ADs in the route are being used for the first tim e. Certificates can also be very useful in stub policy enforcement (see C hapter 2) where a new association between two stub ADs may begin w ith an exchange of the certificates as a form of secure introduction. Throughout the rem ainder of this thesis, we assume the existence of a certification hierarchy as described above. At the very least, every relevant principal (servers and some border routers) is assumed to possess a certificate.13 2 .2 .3 T im e S y n c h r o n iz a tio n The purpose of a tim e service is to provide its clients with continuous, accurate tim e synchronized with global (or national) standards [58]. Time service is a m ajor contributor to the proper function of a network as m any network protocols assume the presence of a reliable tim e service to achieve clock synchronization. One example of a working tim e service is the Network Time Protocol (N TP) [59] currently used in the Research Internet. N TP tim e servers are arranged in a three-level hierarchy. The hierarchy is flexible,14 i.e., it is resilient to certain types of node failures. The actual source of precise time is usually an external system (e.g., an atom ic clock) w ith which top-level time servers are synchronized. 13T he granularity o f certificates can vary between ADs. Some A D s may issue distinct certificates to different servers an d/or routers, while others m ay have a single certificate shared am ong all servers and routers. 14 Except for the top-level servers. 37 In an environment of interconnected ADs, there are several security threats facing a tim e service [4]: 1. im personation of a tim e server 2. modification of tim e server messages 3. replay of previously recorded tim e server messages 4. prevention of tim e server messages from reaching their intended destination 5. delay of tim e server messages (e.g., by flooding the network) In [4], N TP is analyzed for susceptibility to these threats. The conclusions and recom m endations made are applicable to any tim e service. In particular, threats (1) and (2) can be countered by using message authentication while protection from (3) requires main- 'taining state with respect to all possible peers. Threats (4) and (5) are not addressable within the tim e service itself. In the context of this thesis, secure and available tim e service is utilized in stub and transit policy enforcement for insuring the timeliness and uniqueness of the various resource access requests. In other words, a tim estam p is treated as as a unique sequence number (i.e., a nonce [67]) as well as a freshness indicator. We assume th a t the principals’ clocks are loosely synchronized with a maximum clock skew of A t 15 between any pair of principals. Furtherm ore, clocks are assumed never to run backwards. In general, when a principal A receives a packet from its peer B, the packet tim estam p, T , is validated as follows:16 If A and B have communicated recently (within last A t interval) A is required to keep the tim estam p of the last packet (T O L P g) received from B. T is considered valid if: (1) T is greater than T O L P q and (2) T is within the maximum clock skew. This insures th a t T is tim ely (within the limits of the clock skew) and has never been used before. If A and B have not communicated recently, i.e., T O L P b does not exist, A can establish T ’s freshness by making sure th at it is within the maximum allowed clock skew, ji.e. it differs from the current clock reading by at m ost A t . If this condition is satisfied, ,A is im plicitly assured of T ’s uniqueness (if T had been used in the past, A would have (kept a record of it). 15T he value of A t depends on the particular protocol. 16Origin authentication and data integrity services are assumed. 38 C h a p ter 3 S tu b P o lic y E n forcem en t: Visa P r o to c o l In this chapter we address policy enforcement for stub AD communication. The key design goals and guidelines have been outlined in C hapter 1. As discussed in Chapter 2, there are several existing approaches for controlling inter-AD communication at stub AD boundaries. Visa protocol, the mechanism described below, has been selected for several reasons: I j • Flexibility - protocol operation is almost entirely dependent on the particular access control and authentication policies of the participating AD. j • Functionality - protection against: i) unauthorized AD en try /ex it, and ii) modifi- I cation, substitution and replay of legitim ate inter-AD traffic. i • Layering - the entire protocol is situated at the network-layer. 3.1 O v erv iew Visa protocol is a mechanism for controlling the flow of packet traffic to and from end- systems in a stub AD. Before an end-system can communicate across its AD boundary, the communication has to be authorized according to the policies of both local and destination ADs. Authorization can be obtained via a dialog w ith an Access Control Server (ACS) on local and destination ADs. The need for and particulars of this dialog are determined independently by the adm inistration of each AD involved. W hen the communication is approved by both end-point ADs, the respective ACSs issue visas to the requesting end-system. A visa is a cryptographically sealed certificate issued by an Access Control Server (ACS). It contains, among other things, a secret quantity, known as the visa-key. Each packet belonging to an authorized stream carries a visa-stamp, which indicates th at the .39. packet is allowed to leave (or enter) an A D ’s network. A visa-stam p is a function of the visa-key and the packet’s data. It is attached to the packet by the originating end-system and is then re-computed and verified by the border routers of the end-point ADs. In Visa protocol, border routers do not bear sole responsibility for making access control decisions. By issuing a visa, an ACS has pre-computed a decision such as ”end- system s H a and Hb are allowed to communicate”, or ”end-system H a can be trusted to pay its bills”. The task of a router is reduced to ensuring th a t a visa is valid and is being jused correctly; the expensive part of the policy enforcement is done once per connection, by the ACSs of the end-point ADs, rather than once per packet, by the border routers. 3.2 H isto r y The term visa was first suggested by D. Reed, and documented by J. Mracek [63]. A detailed analysis of the issues associated w ith multi-AD internetworks, as well as the original m otivating factors leading to the development of Visa protocol, can be found in j[24]. The first detailed description and the informal analysis of the protocol appeared in [32]. Subsequent research [27] resulted in the development of two protocol models based !on different philosophies with regard to state in visa-routers. The original stateful model requires th a t participating border routers m aintain reliab le tables of active visas. In it, ACSs explicitly distribute visas to visa-routers. Although the loss of state in a visa-router is not fatal to communication, overhead is incurred in the process of re-establishing the necessary state. In contrast, the stateless model avoids the necessity for the distributed state, but requires some additional encryption steps. The stateless model has several advantages: higher fault tolerance (insofar as routers), lower router storage requirements, 'and the ability to accommodate multiple visa-routers without additional overhead. All 'this is gained at a price of higher per-packet processing costs and increased packet size. | In the rem ainder of this chapter, we use the experience from previous work to design the next-generation Visa protocol. In the next section, the goals of Visa protocol are formalized. Network environment is discussed in Section 3.4. Visa protocol participants and their respective requirements are addressed in Section 3.5. Section 3.6 presents the new Visa protocol, and Section 3.7 addresses the key design issues and choices. Section 3.8 analyzes the security of Visa protocol and Section 3.9 evaluates the storage requirements. Protocol im plem entation and performance results are presented in C hapter 5. 40 3.3 G oals The prim ary goal of Visa protocol is to allow an AD to control communication between its constituent end-systems and end-systems in other ADs. If the end-systems involved can be trusted, then a stronger goal can be met: we can control the transm ission of packets to and from a specific end-system in another AD. In a datagram network, as opposed to a circuit-switched network, the only information available about a packet must be attached to the packet rather than inferred from the route the packet follows. Therefore, we can state these goals more directly as follows. 1. A packet can leave the source AD, A D src if and only if A C S src has authorized the source end-system, H src to communicate with the destination end-system, Hdst- 2. A packet can leave A D src if and only if it originated at H src w ithin a reasonable tim e interval, has not been modified in transit and is addressed for Hdst- 3. A packet can enter the destination AD, A D dst if and only if A C S dst has authorized H src to communicate with Hdst- 4. A packet can enter AD dst if and only if it originated at H src within a reasonable tim e interval, has not been modified in transit and is addressed for Hdst- A nother fundam ental goal is not to im pact intra-AD communication, nor to impose addi tional security measures upon unequipped end-systems, i.e., those th a t do not participate lin inter-AD communication. Similarly, we wish to limit the overhead imposed upon ADs th a t are not concerned w ith controlling external access. Finally, we would like to minimize the costs imposed by Visa protocol, including: I • A dditional per-packet processing in border routers and end-systems • Storage requirem ents for routers and end-systems • E xtra communication during connection setup • Additional packet length (additional length increases latency and decreases through- 1 put) j • Cost of recovery from router crashes ) 41 3.4 N etw o rk E n v iro n m en t j l I 5 We assume th a t the internetwork closely follows the model of the DAR.PA Internet [70], j which is substantially similar to the Open Systems Interconnection (OSI) model [43]. The 1 ! ' essential features of this environment are: | • End-systems are autonomous and cannot necessarily be trusted. ' ! • ADs are interconnected w ith routers; between any pair of end-systems in different l ^ i ADs there are at least two routers, one belonging to each of the ADs. Conceptually, < < the connection between two ADs is a pair of half-routers connected via a trusted link. Each half-router can be trusted by its own AD but not necessarily by any other AD. The term s border router and inter-AD router are equivalent. • All inform ation flows via datagram packets. A packet consists of a header that includes addressing and other control inform ation, and a d ata segment th a t is not intelligible to routers. • A packet may flow through several untrusted ADs on its way to the destination. • End-system addresses, both source and destination, can be forged. It is not possible (using hardware m ethods) to determine reliably which end-system actually sent a packet or to prevent a packet from being seen by unauthorized end-system. • Packets traveling across an internetwork may be: i) lost, ii) duplicated, and iii) re-ordered. • Successive packets between a given end-system pair may travel along different routes. Lastly, there m ust exist a global name service which, in a secure and reliable fashion, provides a m apping from end-system network addresses to AD identifiers in addition to ' the more traditional mapping between end-system names and addresses. Along with AD identifiers, the name service has to provide: • Addresses of ACS-s w ithin an AD. • Public key certificates for a given AD (or an ACS assuming each ACS is assigned a ( distinct certificate) . 3.5 P a r tic ip a n ts Visa protocol involves the following participants: access control servers, border routers, and end-systems. These participants and their responsibilities are described in this sec tion. '3.5.1 A C S s Iaji ACS is an end-system, usually dedicated for security reasons, th at is prim arily con cerned w ith access control. Each AD th at implements Visa protocol has at least one ACS, responsible for authorizing its constituent end-systems for communication with end-systems in other ADs.1 M ultiple ACSs may be necessary for availability and perfor mance reasons. Each ACS knows of a number of local border routers th a t implement Visa protocol. ACSs are trusted and are sufficiently secure to defend against hostile attacks. The security of the overall protocol requires th at ACSs be secure and th a t they employ an authenti cated and secure channel for communication w ith local end-systems and routers. Further more, each ACS m ust be identifiable by a unique public key pair [ E K a c s , D K a c s ] where E K a c s is the ACS’s public (encryption) key, and D K a c s is the corresponding secret (decryption) key. Also, each AD is assumed to be a participant in a global, internet-wide certification scheme, whereby each AD (or each ACS therein) has a public-key certificate, C E R T a c s , issued by a well-known certification authority (as described in C hapter 2). jEach ACS certificate contains (among other fields): ACS’s address, E K a c s , the name of |the issuing authority and the certificate signature. This signature is com puted with the jissuing authority’s private key, hence, anyone in possession of the corresponding public 'key can verify the certificate’s validity and thus authenticate the certificate holder. 3 .5 .2 B o r d e r R o u te r s A border router is an end-system dedicated (for reasons of performance and security) to jpacket forwarding. Routers th at use Visa protocol to enforce access controls are called visa-routers. All inter-AD connections m ust be implemented via visa-routers. Each visa- router knows the ACSs in its AD, is willing to accept visas issued by some or all of these ACSs, and trusts their decisions about authorizing and term inating connections. 1 If a participant A D does not have an ACS, its end-system s will still be able to com m unicate w ith the end-system s in other A D s, although the A D in question will be subject to risks associated w ith the uncontrolled access. 43 A visa-router allows any external party to communicate with any registered, internal ACS. Similarly, visa-routers allow all registered, local ACSs to communicate with any external party. Such tru st is reasonable because ACSs are assumed to implement sufficient defense mechanisms and to enforce A D ’s policy. However, this does not imply th at visa-routers should let the ACS-originated out bound traffic go unchecked. In order to detect bogus ACS packets and prevent replay of pre-recorded ACS-sourced packets, a visa-router must verify packet signatures and validate packet tim estam ps of all packets purportedly originating at a local ACS. It is more difficult to control traffic coming in from the outside destined for a local ACS. Because such traffic can originate anywhere in the internetwork its validation would require a visa-router to have means for verifying signatures and tim estam ps generated by a possibly large number of sources. This would necessitate a lot of state inform ation in visa-routers which is clearly undesirable and im practical for reasons of performance, t The alternative is not to scrutinize in-bound ACS traffic and let the ACSs filter out fraudulent packets. Visa-routers can still m aintain some control by m aking sure th at local ACSs do not get flooded by in-bound traffic. The disadvantage of this approach is th at it m ay violate one of our fundam ental goals of not allowing unauthorized externally- sourced traffic consume internal network resources. This subject is addressed further in Section 3.7. Assuming th a t each AD employs visa-routers, each inter-AD packet travels through at least two such routers. A visa-router must scrutinize every packet it receives; packets w ithout visas cannot be forwarded (except for those to or from trusted entities of the ro u ter’s own AD). In section 3.6.1 we describe a mechanism for a visa-router to inform an end-system th at a visa is required for inter-AD communication. Packets originating at or destined for unequipped end-systems are discarded by the visa-routers since these end-systems are (by definition) not allowed any external access. If the two stub ADs are not directly connected, packets will pass through the routers of transit networks. Visa-routers w ithin a single transit AD are assumed to tru st each other, and transfer transit packets via secure channels to prevent unauthorized entrance or exit. Non-visa routers in transit ADs treat visa-stam ped packets as regular internet packets. 3 .5 .3 P a r tic ip a tin g E n d -s y s te m s An end-system attem pting communication outside of its AD m ust be able to obtain a visa allowing it exit from the local AD and entry to the destination AD. In order to obtain 44 exit authorization it needs to contact one of the local ACSs which (upon authenticating | the requesting end-system and checking its access control lists) then contacts an ACS in ! the destination AD and requests entry authorization on behalf of the original end-system. j A fter establishing entry authorization, the remote ACS issues a visa which is subsequently ! delivered to the requesting end-system. Thereafter, a visa-stam p (computed with the • corresponding visa-key) must be attached to every packet sent from the requesting end- 1 i ' system to the apparent destination. An end-system, unlike a visa-router, does not have to have reliable knowledge of the local ACS’s address; this may instead be supplied by a visa-router when an end-system j first attem pts to communicate across the AD boundary (see section 3.6.1). An end-system * may still need to use an authentication protocol (e.g., Kerberos [85]) to make sure it is ■ really talking to the ACS. Since packet reception is a passive operation, the destination end-system is not re quired to initiate any actions. Of course, in most types of communication, packets flow in both directions, so each end-system is both a source and a destination. Therefore, to avoid additional overhead we assume th a t an AD may allow its ACS to issue two-way visas autom atically if no authentication of the remote destination is required. In summary, the requirements for a participating end-system are as follows: • an authentication mechanism to allow for a dialog w ith a local ACS • secure storage for active visas • a means for generating visa-stamps Lastly, a participating end-system m ust be identifiable, i.e., it must be assigned a unique key or key-pair (depending upon the encryption m ethod). It should be noted th a t Visa protocol, by itself, does not provide for multi-level se curity, nor does it elim inate a variety of covert channels. In the absence of additional non-discretionary controls, a participating end-system may still compromise access con trols by serving as a conduit for comxrtuiiications between unauthorized end-systems.2 3,6 P r o to c o l Visa protocol consists of three phases. In the setup phase, an en^-gysfem obtain? au thorization for exiting .its own AD and entering the destination AD. If successful, it 2See section 3.7. 45 culminates with the issuance and distribution of visas to all principals involved. In the packet forwarding phase, the visa-key is used to generate packet d ata signatures th at are attached to all packets belonging to an authorized connection. Finally, the teardown phase involves the term ination of a visa either because of norm al expiration or by explicit revocation. In the rem ainder of this section, each protocol phase is discussed separately. 3 .6 .1 S e tu p P h a se The purpose of the setup phase is to i) authorize communication between two end-systems by the ACSs in the respective ADs, ii) issue a visa which embodies this authorization, and, iii) distribute it to all parties involved. The placement of the protocol participants is illustrated in Figure 3.1. (f ACS b ACS Figure 3.1: Two ADs participating in Visa protocol 46 3.6.1.1 E xit A uthorization The protocol is put in m otion when an end-system, H a, in A D a begins communication with another end-system, Hb, in a different AD, ADb- H a may already know th a t its intended destination is in a different AD, either because it has previously communicated with IIb or it may have discovered this through some external mechanism (e.g., a name server). If so, H a may communicate directly with an ACS in its AD, A C S a. Otherwise, it may discover th a t Hb is in a different AD when its packet reaches the exit visa-router. Since the packet carries no visa-stamp, the exit visa-router replies with a RED IRECT packet. RED IRECT is essentially a means of notifying H a th a t the intended destination is non-local, and th a t it must ’ ’apply” for a visa w ith a local ACS. (3.1) R E D IR E C T = [H a,H b, AC Sa ] The protocol begins by H a requesting authorization from A C S a. It does so by sending a HOST-REQUEST packet to A C S a. (3.2) H O ST - REQ U EST = [ Ha, Hb, T SH. ] Kh‘ \ To m aintain d ata integrity, HOST-REQUEST is signed w ith H a’s key, K n a- H conven tio n al encryption is used, K jja ' ls a key known only to H a and A C S a. W ith public key i 'encryption, K jja is tbe private (secret) key known only to H a. A tim estam p, T S u ai is i jincluded to dem onstrate the timeliness of the packet, i.e., to indicate its freshness to i \A C Sa as described in Section 2.2.3. (Fresheness is, of course, dependent upon the value of A y.) Next, A C S a has to authorize communication between IIa and Hb- This step is depen dent on the particular policy employed by A D a. For example, it may involve a higher-level authentication dialog between A D a and H a. The details of this procedure are beyond the scope of this discussion. If and when exit authorization is established, A C S a composes a VISA-REQUEST packet: (3.3) V IS A - RE Q U EST = [ Ha,H b,T S a ] DKacs° The packet is signed with A C S o’ s secret key and tim estam ped to help verify both data integrity and timeliness. The tim estam p, T S a, is guaranteed to be unique; thereafter, it is used as a visa identifier. As with HOST-REQUEST, the signature is not needed if a higher-level authentication dialog is used between A C S a and its counterpart in ADb- Nevertheless, our purpose is to allow authentication to take place at the earliest possible tim e rather th an relying on the presence of a higher-layer AD-dependent mechanism. 47 In order to deliver a VISA-REQUEST, A C S a has to locate its counterpart in the des tination AD, ADb- It may know the address of ACSb because of previous communication In which case VISA-REQUEST may be sent directly. It could also obtain A C S ^ s address jvia a name service query [60]. Alternatively, VISA-REQUEST may be sent addressed jto Hb (the destination end-system). This is possible because visa-routers are required to ■reroute all VISA-REQUEST packets to one of the local ACSs. Furtherm ore, in case of no previous communication w ith ADb, A C S a may choose to speed up the setup process a little by including its certificate, CERTACSa w ith the VISA- REQUEST packet. This would save ACSb the need to request this certificate explicitly (from either A C S a or some name server). 3 .6 .1 .2 E n try A u th orization W hen a VISA-REQUEST reaches ADb, the intervening visa-router, GWb, forwards it to one of the local ACSs, ACSb- F irst, ACSb verifies th a t Hb indicated in the VISA-REQUEST is in fact an end-system in ADb- This is necessary in order to minimize tim e spent on potentially malformed VISA-REQUESTs. Next, before proceeding to authorize the connection ACSb has to validate the VISA-REQUEST. In order to authenticate its contents (i.e., re-compute the signature), ACSb needs the public key of A C S a, E K a c So .- To obtain this key ACSb has to know the AD identifier of A C S a (i.e., A D a), which is not included in the VISA- REQUEST. However, ACSb can query its name service w ith H a (which is p art of VISA- REQUEST) and obtain ADj,, ACSb and E K a cSo .- W ith the help of EKACSa ACSb can re-compute the signature of the VISA-REQUEST and verify both its origin and data integrity. Timeliness an uniqueness of the VISA- REQUEST is inferred from the enclosed tim estam p, T S a (as described in Section 2.2.3). ; Next, ACSb authorizes communication between H a and Hb- AS before, this step is dependent on A D ^s policy. At last, when communication is authorized, ACSb issues a fresh visa in a form of a VISA packet. (3.4) V I S A - G R A N T = [Ha, H b, auth - type, T S a, E xpiration, Conditions, (S%)ei<acs«]D K acs> > I Since the structure of a V ISA -G R A N T packet is crucial to the security of the protocol, we now consider the individual packet fields in more detail: I • H a,Hb are the two end-systems th at are authorized to use this visa. In order to associate packets with a particular connection, visa-routers G W a and GWb, need these end-system addresses to locate the appropriate visa-key. 48 • auth-type denotes the signature m ethod to be used for packet signature com putation. • S% is the so-called visa-key. It is subsequently used to compute packet signatures for traffic flowing between H a and //&. Depending on the signature m ethod, S'£ may be an encryption key (as in DES-based MAC) or a secret prefix/suffix for use in conjunction w ith MD4. (See Appendix A). Because a visa-key has to be kept secret to prevent interception by potential intruders, it is encrypted w ith A C S a public key. • T S a is the tim estam p assigned to the visa by A C S a and approved by ACSb- It is used prim arily as a nonce [67], i.e., a unique, hereto unused, visa identifier. • Expiration indicates the condition(s) for the term ination of a visa. May be expressed as any combination of: maximum lifetime of a visa (e.g., in msec) i maxim um inactivity period f maximum number of packets maximum amount of d ata transferred (e.g., in Kbytes) • The Conditions field can be used to express the visa usage conditions, e.g.: Type of Service User Class Higher-level protocol, etc. 3 .6 .1 .3 V isa D istrib u tio n After entry authorization is obtained and the new visa is issued, ACSb forwards the VISA-GRANT packet to the requesting A C S a■ A VISA-GRANT also has to be sent to GWb so it can process entering packets accordingly. However, in the original VISA- GRANT packet, S% is encrypted with E K a c So . 1° m aintain its secrecy. Since D K a c So . is not known to GWb, ACSb has to create a different copy of a VISA-GRANT for delivery to GWb where S% is encrypted with EKACSb• Upon receipt of the VISA-GRANT, GWb creates a new entry in its visa-table. W hen A C S a receives a VISA-GRANT packet, it has to check several conditions: • F irst, A C S a verifies th at H a, Hb and T S a are indeed the same values th a t were used in the VISA-REQUEST packet. 49 • Next, the integrity of the VISA-GRANT packet has to be verified. A C S a can do so by re-computing the packet signature w ith E K a c Si ,-3 • Finally, the authentication type and the expiration conditions are checked for rec- ognizability and consistency. W hen the VISA-GRANT packet is validated, A C S a notifies its visa-router, G W a via a VISA-GRANT packet, where Sj? is encrypted with E K a c So . and the entire packet is signed with D K a c So . instead of D K a c sb-4 On receipt of the VISA-GRANT, G W a installs the new entry in its visa-table and becomes ready to pass packets between H a and H \,. The VISA-GRANT packet sent to H a is similar save for S% which is encrypted with K j j a . 3 .6 .1 .4 S etu p Su m m ary In summary, the setup phase involves the following steps:5 1. H a = ► A C S a : H O S T - R E Q U E S T 2. A C S a = > A C S h : V I S A - R E Q U E S T 3. A C S b = > G W b : V I S A - G R A N T aW b 4 . A C S b = > A C S a : V I S A - G R A N T ACSa 5. A C S a = * > G W a ■ V I S A - G R A N T GWa 6. A C S a = ► H a : V I S A - G R A N T H « In the description above, V I S A — G R A N T P denotes the Visa packet where S§ is en crypted for the principal P (e.g., GWa) with a key which is either P ’s public key, or a key shared among the sender and P . All other fields are the same for all V I S A - G R A N T P-s. Of all the messages exchanged during the setup phase, those in steps (2) and (4) are of particular im portance since they cross AD boundaries and are, therefore, subject to much greater exposure. 3 Freshness and uniqueness of the V ISA -G R A N T packet is evident from the presence in it o i T S a . 4 T he assum ption is that G W a and A C S a share the sam e p ub lic/private key pair. 5T he notation A =S> B : P A C K E T means ”A sends P A C K E T to B i I 50 3 .6 .2 P a ck et Forw arding W hen the setup phase is completed, H a can begin communication. Each packet th a t II a sends to Hb has to be accompanied by a visa-stam p. However, it is not enough to simply sign the packet. The reason for this is twofold. F irst, the protocol m ay need to support m ultiple visas for the same end-system pair. Therefore, a visa-router can not uniquely identify an entry in its table using only the two end-system addresses. For this reason, T S a and TSb are included with each packet. Second, since one of the protocol goals is the detection of stale, (or potentially replayed) packets, H a needs to attach a tim estam p to each packet. In this context, a regular (non-visa) packet is composed of a d ata segment and a network-layer header. A visa-stam p is computed as: (3.5) V IS A - ST A M P = F([H EAD ER, D ATA, TSBl.],S$) where F is the signature function determined by the auth-type agreed to during the setup jphase and T S u a is the tim estam p assigned to the packet by H a. T S n a m ust be unique, ji.e., no two packets should carry the same tim estam p (for a given connection). I j The resulting d ata packet has the following form (see also Figure 3.2): (3.6) D ATA - P A C K E T = [HEADER, DATA, V IS A - STAM P, T S a\ 3.6.2.1 E x itin g A D a As described in Section 3.3, when a packet w ith an attached visa-stam p arrives at G W a it has to dem onstrate authorization to leave A D a as well as authenticity and freshness of its contents. G W a checks the first condition by indexing its visa-table with the [TS^, H a, II b ] tuple. Successful look-up indicates the existence of exit authorization by A C S a. Next, the freshness of the packet is verified by comparing the packet tim estam p, T S u a w ith the stored tim estam p of the last (previous) d ata packet th a t used the same visa (this value is referred to as )• Finally, G W a re-computes the packet signature and compares it to the visa-stam p attached to the packet. If the two values m atch, G W a can safely conclude th a t the packet contents are authentic. The order in which these checks are performed is not arbitrary. In particular, the reason for verifying packet freshness before validating a packet signature has to do with 51 n e tw o r k -la y e r h e a d e r VISA-STAMP « * F < (header,data,3 * ) Figure 3.2: D ata packet form at the cost of the latter operation. Naturally, for authentic packets, the order of these two operations is im m aterial. However, because we would like to detect replayed (i.e., stale) packets at the earliest possible tim e, and because it is significantly cheaper to compare two tim estam ps than to re-compute a packet signature, the freshness test is performed first. 3 .6 .2 .2 E n te rin g ADb The goals of GWb w ith respect to entering packet traffic are similar. Like G W a, GWb checks authorization by indexing its visa-table with the [TSb, H a, Jf&], verifies packet 'freshness by comparing the packet tim estam p with the its T ^ \ and re-computes the signature to verify the authenticity of the packet contents. 3 .6 .3 T ea rd o w n As mentioned previously, a visa may be term inated for one of two reasons: • Normal expiration (tim e, packet or data ceiling reached) 52 • Explicit revocation (by explicit order of an ACS) In the first case, a visa-router simply deletes the corresponding entry from its visa-table. If and when a packet bearing a visa-stam p com puted using an expired visa arrives at the visa-router, it is prom ptly discarded since the table look-up fails. In case of explicit revocation, an ACS may decide for some reason th at a certain visa is no longer trusted and sends a REVOKE packet to the appropriate visa-router and a peer ACS: (3.7) R E V O K E = [Ha, Hb,T S a,T S b, Reason]0K acs T S a and T S b in the REVOKE are the same visa identifiers assigned at the setup time. Since a visa can only be revoked once, there is no need to tim estam p a REVOKE packet as its replay presents no danger. 3 .7 D e sig n Issu es In this section, we discuss several issues leading to the design of Visa protocol presented in this chapter. We also address several im portant features where the current protocol differs from its predecessors. 3 .7 .1 V isa s In the previous Visa protocol versions, each end-point AD issued a visa for authorized communication. Moreover, each visa had an associated visa-key, thereby necessitating the com putation and subsequent verification of two distinct packet signatures. In other words, the end-system computed two packet signatures, D S I G exu and D S I G entr- The former was verified by the exit visa-router in the source AD, and the latter, by the entry visa-router in the destination AD. The setup phase of the protocol consisted of the following steps: 1. H a =► A C S a : H O S T - R E Q U E S T 2. A C S a =► A C S b ■ V I S A - R E Q U E S T 3. A C S b =► G W b : V I S A - G R A N T entr 4. A C S h = > A C S a ■ V I S A - G R A N T entr 5. A C S a = > G W a : V I S A - G R A N T exit 6. A C S a =► H a : V I S A - G R A N T e n tr, V I S A - G R A N T exit 53 T he prim ary reason for each ACS issuing its own visa (one entry and one exit) was the assumed lack of tru st between the two ACSs as far as the issuance of good keys or visas. On the other hand, A C S a still trusts its counterpart, A C S b , enough not to misuse V I S A — G R A N T entr (and the included key). In other words, A C S b issues a visa which lit subsequently releases to A C S a for distribution to H a . This tru st in A C S a seems to contradict the reason for issuing two visas. In the protocol described in Section 3.6.1, only one visa-key and a single visa is used for both exit of A D a and entry of A D b . 3 .7 .2 R e p la y P r e v e n tio n As m otivated by our argum ents in C hapter 1, one of the goals of an effective stub policy enforcement mechanism is the protection of stub AD network resources from unautho- I rized traffic. This includes traffic flowing to and from equipped end-systems. Previous Visa protocol versions [32, 27] dealt with this issue by ensuring d ata integrity and au thenticity of the packets crossing AD boundaries. One deficiency in the previous design was the absence of any provisions for detecting replayed packets belonging to authorized connections. This has been remedied (as evidenced in Section 3.6) by requiring th a t end- systems attach a unique tim estam p to each visa-stamped packet and visa-routers keep a per visa record of a tim estam p for the last packet processed. One im portant insight related to this requirement is the apparent impossibility of effective replay detection w ithout state in visa-routers. W ith some degree of synchro nization, a stateless visa-router may be able to detect very old packets. However, if an intruder duplicates each legitim ate packet and injects duplicates into the packet stream shortly after the corresponding original packets, duplicates can not be detected. 3 .7 .3 V is a E x p ir a tio n The only m ethod for visas to expire in the previous protocol versions is by way of timeouts, i.e., an explicit tim e lim it is negotiated at setup tim e and a visa is invalidated when the itime lim it is exceeded. W hile this is adequate for some types of connections, provisions for other m ethods of visa expiration may be necessary. These include lim its on inactivity periods, num ber of packets and bulk data transferred. Unfortunately, expiration based on lim its other than ju st simple tim eouts is not pos sible without state in visa-routers. In order to expire visas according to any of the above 54 criteria requires th a t a visa-router m aintain running tally of packets, d a ta bytes or the tim e of last packet arrival on a per visa basis. 3 .7 .4 V is a R e v o c a tio n Visa term ination by explicit order from an ACS should be viewed as more of exception than the norm as, ordinarily, visas are term inated by exceeding some lim it negotiated at the tim e of issuance. Nonetheless, in circumstances where there is suspicion of a visa’s compromise an ACS may need to revoke a visa prem aturely, i.e., before its resource limits are reached. In order to revoke an active visa, an ACS contacts the appropriate visa-router and identifies the visa targeted for term ination. Thereafter, the visa-router has to ensure th at no more packet traffic belonging to the revoked visa connection passes through. In a \ jstateful model, a visa-router can simply delete the entry from its table thereby barring any further traffic. In a completely stateless model where each packet carries the entire visa along with the derived visa-stam p, a visa-router has to keep s ta te w ith respect to the revoked visa. (Otherwise, it can not distinguish bona fide visas from revoked ones). A direct consequence of this requirement is the inability of a completely stateless visa-router to support visa revocation. 3 .7 .5 C o v e ra g e o f P a c k e t S ig n a tu r e s In the context of this section, a packet is composed of two portions: network-layer header and data. As discussed in Section 3.3, data authenticity is one of our prim ary goals. Hence, there is no question as to w hether or not the data portion needs to covered by the packet signature. Network header is a different m atter, however. A typical network- layer header contains addressing inform ation such as source and destination end-system j addresses, packet sequence number, packet length and other fields. (Figure 3.3 depicts the IP [73] datagram header, for example). Any header field not covered by the packet signature leaves a potential covert channel, since an intruder could trap a valid packet, change the unchecked field, and forward the modified copy w ithout raising suspicion. We could protect against this by including the entire network-layer header under the packet signature, but in m ost internetworking protocols there are some header fields th a t are modified by the interm ediate routers, and hence cannot be included in the signature. (All routers may have to modify the header, 55 not ju st visa-routers, and we assume th a t non-visa routers do no regenerate the signature. If a public-key m ethod is used, not even visa-routers can do so.) For example, there are two such variable fields in the IP protocol. One is the header checksum; this cannot be forged because it is a function of the other fields in the header, and is already recom puted by each IP router. The other is the 8-bit Time-To-Live (TTL) field, used to prevent packet from looping forever. The TTL m ust be decremented by each IP router, and must never be incremented. An intruder could communicate approximately 6 or 7 bits per datagram by m anipulating the initial value of the TTL field in copies of otherwise validly-signed packets. If this covert channel is a reason for concern, there are a number of steps th a t can be taken. The entry visa-router (GWb) can use the knowledge of its AD topology to reduce the TTL value to the minimum necessary for the packet to safely arrive at Hb, thereby reducing the bandw idth of this covert channel. Alternatively, GWb could always set the TTL to its maximum value. (However, this would violate the letter of the IP specification, and might confound protocols th at use the T TL field to lim it the lifetime of a packet). Another issue has to do with the addressing inform ation in the network header. Recall j i th a t visas are issued on the basis of the source and destination end-system addresses I (sometimes, along w ith the transport-layer protocol num ber). As described in Section 3.6.2, each visa-related d ata packet carries a visa identifier (T S a). This identifier is stored alongside the two end-system addresses in visa-tables of both G W a and GWb• Since a ! visa-router still has to consult its visa-table to look up the visa-key, it can (inexpensively) J verify the H a, Hb addresses as well. Therefore, it can be argued th at end-system addresses and other inform ation (e.g., type-of-service, transport protocol, etc.) th a t is stored in the visa-table entry does not need to be protected by the packet signature. 3 .7 .6 F r a g m e n ta tio n In a number of internetworking protocols (e.g., IP ) a router may have to fragment a packet if it cannot be transm itted in a single unit. D ata signatures complicate the use of fragm entation since the fragments m ust appear to have been signed by H src, but the signatures would have to be computed by the fragm enting router. W ith signatures based on conventional cryptography, fragm entation is a problem because only a visa-router can do it while preserving the d ata signatures. W ith public-key signatures, this is impossible, i |since only the originating end-system can compute the signature. i ! I 56 0 12 3 4 version IR header length type of service total length identification (sequence #) flags J fragment offset time-to-iive transport protocol IP header checksum source address destination address IP options Figure 3.3: IP datagram header Fragm entation is at best a necessary evil [47]; it is almost always better to set packet sizes at H arc, to make the best possible use of the available bandw idth and to provide acknowledgements for each transm ission unit. Although m ethods have been proposed for accommodating fragm entation while preserving d ata signatures [88], we insist th at the source end-system avoid sending packets th at will have to be fragm ented. A router should assist in this by returning an error packet when it is unable to transm it a data packet w ithout fragm enting it; in fact, the IP protocol includes a mechanism for doing so through the use of ICM P Destination Unreachable/Fragmentation Needed message [74]. 3 .7 .7 L o ss o f S ta te Reliable state in visa-routers (i.e., visa-tables) is one of the fundam ental features and requirem ents of Visa protocol presented in this chapter. Nevertheless, it is unreasonable to expect visa-routers to be non-faulty at all times. The im plication is th at loss of state in visa-routers may occur infrequently and provisions m ust be m ade for the reinstatem ent of 57 state after when a visa-router becomes operational. For this reason, an initializing visa- router sends a special ROUTER-UP packet to its local ACS. (Visa-routers are required to keep local ACS address(es) in stable storage). Upon receipt of a ROUTER-UP, ACS replies w ith one or more VISA-LIST packets which contain a set of all currently valid visas issued to the visa-router in question. The form at of a VISA-LIST is similar to th a t of a Visa packet, except th at it contains multiple visa records. ROUTER-UP only specifies the identity of the initializing visa-router.6 In spite of the mechanism described herein, not all state can be effectively recovered. In particular, visa expiration conditions such as inactivity tim eouts, data and packet [limits require m aintaining state (i.e., usage meters) th at is updated on a per packet basis. Unless it is kept in stable storage (an unreasonable requirem ent), this state is irrecoverably lost when a visa-router fails. 3.T .8 S ta te fu l M o d e l In this section, we summarize the reasons for selecting stateful over stateless visa-router model. There are several incentives for m aintaining state in visa-routers: • Replay prevention As discussed in Section 3.7.2, it is impossible to detect replayed packets in a visa- router w ithout m aintaining state. This is best illustrated by a situation whereby an intruder simply duplicates each valid packet and forwards it im m ediately after the original. Because the two packets are back-to-back, even if G W a has some idea of the H a — » G W a delay, it would accept both packets as valid. • Visa expiration by means other than tim eouts In order to expire visas by means of data, packet or idle-time lim its, a visa-router m ust m aintain running tallies. This is impossible to achieve with a stateless router model. • Visa revocation If an ACS decides th at it no longer trusts a previously approved connection, it may need to revoke a visa prematurely. As described in Section 3.7.4, ACS explicitly notifies the appropriate visa-router (via a REVOKE packet) th at a certain visa is no I longer valid. To uphold the revocation of a visa, i.e., to let no more packets bearing | 6 An intruder m asquerading as a legitim ate visa-router m ay generate R O U T E R -U P packets, however, visas contained in the subsequent V ISA -LIST are only intelligible to genuine visa-routers. 58 derived visa-stamps through, the visa-router has to m aintain a record (state) with respect to the revoked visa. • Interplay with transit policy enforcement A final reason has to do with the integration of stub and transit policy enforcement mechanisms. As described in the next chapter, transit policy enforcement in stub ADs also takes place at AD boundaries in entities referred to as Policy Gateways (PG s). As it turns out, each PG in a stub AD m aintains a table of end-system pairs th a t are engaged in inter-AD communication. The purpose of this table is to map end-system pairs into so-called Policy Routes. Although a PG and a visa-router are logically distinct, for the most part, they share the same physical location. 3.8 S ecu rity A n a ly sis In this section we address the security of Visa protocol presented earlier in the chapter. As mentioned before, intra-AD messages and other intra-AD communication is assumed to be secure and each AD is assumed to employ an authentication mechanism of sufficient strength. W hat remains to be shown is the security of the inter-AD communication, i.e., the two messages exchanged among A C S a and ACSb as part of the setup phase and the i 'subsequent d ata packets. ! | For each of these messages, two security issues are of interest: i) whether or not the ! message conveys the inform ation necessary to establish its origin, authenticate its contents and assure freshness, and ii) whether it can be used maliciously (e.g., if it is intercepted by an intruder) to achieve unauthorized or otherwise compromised communication. 3 .8 .1 V IS A -R E Q U E S T The first inter-AD message in the setup phase is the VISA-REQUEST: (3.8) A C S a = > A C S b : V I S A - R E Q U E S T (3.9) V IS A - R E Q U E S T = [ H a,H b, T S a ] D K a c s » Upon its arrival, ACSb has to verify th at A C S a originated th is ex a ct packet recen tly. Once ACSb obtains C ERTACSa, extracts from it EKacSo. an(l re-computes the packet signature it is assured th a t the packet is originated by A C S a and is authentic. Of course, this is very much dependent upon the strength of the signature mechanism. 59 Both timeliness and uniqueness of the VISA-REQUEST are established by examining the T S a held. Recall th at T S a is the tim estam p assigned by A C S a . A C S a is responsible for ensuring th at it has never been used before. As described in Section 2.2.3, ACSs’s clocks are not necessarily closely synchronized, i.e., a certain clock skew is expected. We assume, there exists an upper bound (referred to as A t ) on the clock skew between any two ACSs. By comparing its current clock reading to T S a , A C S b can establish the timeliness of the VISA-REQUEST. However, tim elin ess is relative to A x since an intruder can still delay a VISA-REQUEST for, at m ost, the value of A y. j Uniqueness is a different m atter. In order to establish th at a VISA-REQUEST has not been seen before, each ACS has to keep state in the form of a peer-table. Each entry in the peer-table corresponds to a peer ACS (in a different AD) which has previously communicated w ith the ACS in question. Among other inform ation (such as public key certificates), each entry stores the tim estam p of the last VISA-REQUEST by the corresponding ACS. (We refer to this value as T S l aast). If T S a < T S ! aast, A C Sb can suspect a replay attack. However, it can not be absolutely sure since VISA-REQUEST packets can arrive out of order. If T S a = T S l f st, the VISA-REQUEST packet is obviously a duplicate. As far as the intruder is concerned, there is little value in a VISA-REQUEST packet. It contains no secret fields and it only reveals th a t a visa for communication between H a and \H b has been requested (hence, a VISA-GRANT may flow in the opposite direction soon I !thereafter). Also, modification of packet d ata is unproductive as each VISA-REQUEST jis protected by an unforgeable signature. Replay of a VISA-REQUEST is just as futile j as can be seen from the above discussion. Another security-related aspect is the issue of the implied beliefs carried in a VISA- REQUEST. Specifically, it conveys to A C S b th a t i) A C S a authorizes the [H a, H b] com m unication, and ii) believes th a t the requesting end-system H a is authentic. A C S b has no reason to question or doubt the former (since it is subject to A D a ’s local policy embodied in A C S a), however, w ith regard to authentication of H a, A C S b has to take A C S a ’ s word fo r it. In other words, the end-result is th at: A C S b believes that A C S a believes that IIa is authenticated. This conclusion may be too weak in some circumstances. In order to obtain a stronger conclusion such as A C S b believes that H a is authenticated, either: 1 . A C S b has to conduct a separate, possibly higher-level, authentication dialog with J H a, or I 60 2. A C S a has to include an unforgeable proof of identity for H a as p art of the VISA- REQUEST The second choice is preferable because it does not involve relying on other protocols and introduces no additional communication overhead. However, it has two im portant drawbacks: i) the problem of scale with regard to issuing proof-of-identity certificates at the granularity of end-systems, and ii) the additional overhead incurred by the use of public-key encryption for subsequent communication. This subject is discussed further in Section 3.8.3 below. I I 3 .8 .2 V I S A -G R A N T VISA-GRANT is the second inter-AD message exchanged as p art of the setup phase. (3.10) A C S b = > A C S a : V I S A - G R A N T a c s ° (3.11) V I S A - G R A N T = [Ha,Hb,T S a,(Sb)EKACSa]DKACSi W hen A C S a receives a VISA-GRANT packet, it has to: • m atch the T S a found in the packet with the corresponding T S a stored in its table of outstanding VISA-REQUESTS. A successful m atch, in itself, dem onstrates both freshness and uniqueness of the VISA-GRANT packet. • authenticate the contents of the packet. Since A C S a already knows EK.ACSb- > R can re-compute the packet signature and establish th at ACSb originated this packet and its contents are authentic. As with a VISA-REQUEST, an intruder can capture a valid VISA-GRANT packet and attem p t to attack the protocol. However, since a VISA-GRANT is signed and times- tam ped, no modification or replay is possible w ithout detection. A danger even graver than successful fabrication or replay of a VISA-GRANT packet is the possibility of an in tru d er discovering S%. (This would perm it the intruder to generate arbitrary ’’genuine” packets). Therefore, the effectiveness of Visa protocol depends to a great extent on the i strength of the underlying public-key encryption (signature) function. J3.8.3 D a ta p a c k e ts Recall th at d ata packets belonging to a visa connection have the following structure: (3.12) D A T A - P A C K E T = [ H E A D E R , D A T A , V I S A - S T A M P , T S a] 61 A d ata packet arriving at G W a or GWb, has to show th at: • it originated at H a and is addressed to Hb • it was sent recently • it was not modified in transit We begin by observing th a t the m ethod by which G W a determines the origin of a data packet is the verification of the visa-stam p attached to the packet which is com puted with a secret visa-key, S%. In addition to H a, S% is known to four other principals: H a, A C S a, G W a, ACSb and GWb• This implies th at any of these principals can potentially generate genuine visa-stamps. A fter verifying the visa-stam p, tim estam p and addressing inform ation of a d ata packet, the only conclusion th at G W a can make is: the packet contents are authentic, the packet is not a replay, and its origin can be any o f H a, GWb or AC Sb■ We assume th a t G W a believes in its own goodness, thus it can be sure th a t it did not originate the said data packet, and, G W a trusts A C S a enough to believe th a t A C S a did not originate the packet. Similarly, GWb can establish th a t the origin of a d ata packet can be H a, G W a or A C S a.7 The uncertainty about the exact origin of d a ta packets is, potentially, a reason for concern. Nonetheless, we argue th a t the overall security and robustness of Visa protocol relies on the invulnerability of the ACSs and visa-routers. If the security of an ACS or |a visa-router is somehow compromised, fraudulent visas may be issued and unauthorized communication can transpire. On the other hand, it is worth considering, if only for academic reasons, what it would take to remove the above uncertainty, i.e., allow visa- routers to determ ine the source of each d ata packet unambiguously. To do so would require th at each end-system be able to certify its identity, i.e., be uniquely identifiable by a some property th at can be used to sign d ata leaving no doubt about the identity of the signature creator. The im m ediate consequence of this statem ent is th a t conventional cryptography is unable to solve the problem since it calls for (at least) two principals sharing a key. (If A C S a and H a possess the same key, K n ai any one of them can generate d ata signatures w ith th a t key). The only rem aining choice is the use of public-key cryptography. Suppose th at each participating end-system is issued a public-key pair [E K n a, D K jja] and a corresponding certificate, C E R T jja, by a well-known authority.8 Instead of issuing a secret, conventional rN ote that if the protocol operates correctly, none of G W a, GWb , A C S a and ACSb ever generate data packets signed w ith Sb - 8 The authority can not be A C S a or any other entity in A D a, for obvious reasons. 62 visa-key, A C S b would generate a public-key pair, [EKg, DK%], and a VISA-GRANT packet would take the form of: (3.13) V I S A - G R A N T = [Ha, H b, T S a, , E K £ , (DK%)EKh*)DKacs* > Note th a t S% is replaced by DK%, the secret (signature) component of the public-key pair. Because it is encrypted w ith E K jja, DK% can only be computed by H a. However, anyone (A C S a, G W a, GWb, etc.) can obtain the corresponding public key, EK%. If H a generates d ata packet visa-stam ps w ith DK%, both G W a and G W b can trace the packet source to H a as no other entity can be in possession of DK%. While this approach results in somewhat increased protocol security, its benefits are outweighed by the cost of using public key encryption on a per packet basis. Another drawback is (as alluded to in Section 3.8.1) the issue of scale w ith respect to certification of the individual end-systems. Finally, one of the fundam ental protocol assumptions is the security of the ACSs and visa-routers. Because ACSs are presumed to exercise extensive control over their constituent end-systems, it may be unreasonable to tru st an end-system in an AD whose ACS or visa-router is not trusted. 3.9 P r o to c o l C o sts In this section we address the im pact of Visa protocol on its participants. In particular, we consider the costs incurred per visa as well as per d ata packet. 3 .9 .1 S e tu p a n d D is tr ib u tio n The setup phase involves at least two packets: a HOST-REQUEST from H a to A C S a, and a VISA-REQUEST from A C S a to ACSb- The distribution phase involves at least ifour more packets: V I S A - G R A N T a c s *, V I S A - G R A N T aWb, V I S A - G R A N T aw » 'and V I S A - G R A N T 1 1 *.9 In total, a minimum of six packets are exchanged, yet only i jtwo of the six travel across AD boundaries. I j3 .9 .2 S t a te O v e rh ea d State overhead, consisting of storage costs, is introduced in this protocol mainly by the need for all participants, but especially visa-routers, to keep visa-tables. 9 A dditional exchanges m ay be required in order for H a to authenticate itself to A C S a and ACSb- 63 | In order to facilitate fast packet switching, routers often use specialized hardware jequipped with very fast memory. However, this memory is expensive and, hence its availability is limited. Therefore, storage overhead in visa-routers is of particular im por tance. Its m ajor contributing factor is the maintenance of a visa-table where each entry corresponds to a currently valid visa. As illustrated in Figure 3.4, each entry contains essentially the same inform ation as carried in the corresponding VISA-GRANT packet. The only exception is th at visa-routers must constantly m onitor bandw idth usage of in dividual connections. Also, the tim estam p of the last d ata packet, T S j ^ is kept in order to i) prevent replay of old packets, and ii) m onitor the inactivity time. An ACS m ust also keep a table of active visas. ACS’s visa-table is essentially the same as the visa-router’s visa-table, except ACSs are not required to keep running counters. H a — r J tn L b Time of last packet arrival -- M ^ a .,b last Authentication type Secret key — s a Expiration criteria Usage Conditions Figure 3.4: Visa table entry 3 .9 .3 P e r p a ck et c o sts The per packet costs include the additional fields in d ata packets, table look-ups in visa- routers, and d ata signature com putations. 10See Section 3.8.1. 64 Each d ata packet carries a visa header depicted in Figure 3.2 above. The visa identi fier, T S a is 64-bit quantity (sufficient w idth for a tim estam p) and the end-system tim es tam p, TSffa, is also 64 bits wide. The size of the visa-stam p depends on the signature m ethod, e.g., 128 bits for MD4 secret prefix/suffix or 64 bits for DES-based MAC. The overhead due to d a ta signature operations depends upon the particular signa ture scheme used. It also depends upon whether the operation involves passing over the entire or only p art of, the packet. Furtherm ore, the cost of signature com putation can be significantly more expensive than the cost of signature verification as in some pro posed variations of RSA [76]. In general, there are three operations involved: signature com putation at H a and two signature verifications at G W a and GWb, respectively. 3.10 S u m m a ry In conclusion, Visa protocol presented in this chapter is a simple and powerful mechanism for controlling packet traffic at stub AD network boundaries. The prim ary goal of Visa \ protocol, i.e., protection of stub AD network and end-system resources from unauthorized ! access, is achieved by requiring th a t all communication be first authorized by the ACSs in j end-point ADs. A uthorization to communicate is then embodied in a visa which is issued j to the requesting end-system and distributed to the intervening visa-routers. Subsequent | packets carry unforgeable visa-stamps which are verified by the visa-routers. Visas are i j term inated when the underlying communication exceeds a pre-determ ined resource lim it. I j Visa protocol does not im pact intra-A D communication and has no influence on the I end-systems th a t do not partake in inter-AD communication. Although, as illustrated in C hapter 5, the cost of connection setup is somewhat high, per packet overhead due to the protocol is reasonable, especially, when non-cryptographic packet signatures are used. 65 C h a p ter 4 T ran sit P o lic y E n fo rcem en t: C on trol o f T ran sit In tern etw o rk Traffic An im portant conclusion reached in Chapter 1 is th a t controlling the usage of network resources (such as routers and links) requires additional protocol support because of the need to coordinate routing decisions among all intervening networks. Thus, organizations j ( A D s ) cannot simply enforce policy restrictions on a unilateral basis at packet forwarding jtime. Instead, internetwork routing decisions must be made according to policy-related param eters such as access rights and cost, in addition to the traditional param eters of jconnectivity and delay [13, 26, 53]. Consequently, policies pertaining to network resources m ust either be implicit in the topology of an internetwork, or advertised to the anticipated I Resource users. Only then can entities throughout the internetw ork determ ine the logical, I policy-based connectivity of an internetwork and compute valid routes, j This chapter addresses the design of protocols for se c u re control of transit traffic on an internetwork. Transit control protocols can be designed w ith varying levels of security. In some environments, relatively vulnerable protocols may be used in conjunction with post facto detection mechanisms. Most of the work in policy-based protocol development is being conducted with such environments in mind [13, 53, 34, 54]. We are interested in environments where post facto detection is not adequate or possible in a tim ely manner. In particular, we address the design and costs (i.e., performance and manageability) of incorporating more defensive, preventative security measures into the protocols for controlling internetw ork traffic. The rest of this chapter is organized as follows. Section 4.1 begins by considering the extension of network access control m ethods to control transit internetw ork traffic. In response to some fundam ental deficiencies of both network access controls and traditional, delay-based internetwork routing, the rem ainder of Section 4.1 describes the role of the so- called Policy Routing protocols in providing transit control. Next, Section 4.2 outlines the 66 security concerns particular to the Policy Routing protocols. The discussion of security is continued in the remaining sections on secure protocol design (Section 4.3) and cost ^assessment (Section 4.5). Section 4.6 summarizes our discussion. 4.1 C o n tro llin g T ran sit Traffic jThere are two basic approaches to controlling transit traffic. In the first part of this section, we discuss an approach based on the extension of traditional network access Jcontrol mechanisms and identify its lim itations. Subsequently, we consider alternative approaches based on integrating controls into internetwork routing. 4.1.1 E xten d in g N etw ork A ccess C ontrols One potential m ethod of enforcing transit policy enforcement is the extension of existing stub AD access control mechanisms to the generalized internetwork model. In this section, iwe discuss an extension of Visa protocol th a t incorporates support for transit policy enforcement. O ther network access control schemes are discussed briefly at the end of this section. 4 .1 .1 .1 T ra n s it Visa P ro to c o l As described in the previous chapter, Visa protocol was originally designed to provide ;packet-level control at AD boundaries.1 Recall th a t a secret visa-key is used by the com- imunicating end-system to compute a visa-stam p which is attached to each d ata packet to I assure appropriate border routers th at the transm ission across AD boundaries is autho rized. A visa-stam p is analogous to a stam p on a passport th a t allows a traveler to cross ■international borders. A unique visa-stam p is bound to each packet in order to guarantee the authenticity and the integrity of the data. The process of establishing authorization in visa-controlled transit ADs is essentially the same as for stub ADs in Visa protocol. The m ain difference is th at now the source end-system m ust obtain authorization for each transit AD th a t it traverses, in addition to obtaining authorization from A D src and ADdst- In the worst case, each transit A D ’s ACS will conduct an authentication procedure before establishing authorization. Of course, transit ADs may choose to do so autom atically, or not require any authentication at all xIn a connection-oriented network a sim ilar approach can be applied to stam p packets. However, the establishm ent of a visa-key can be part of the connection setup and several o f the datagram related design issu es do not apply. 67 jwhere transit traffic is concerned. Furtherm ore, stub ADs could program their ACSs jto obtain and issue transit visa-keys in advance of the actual communication. This jwould reduce the setup delay at connection establishm ent tim e. On the other hand, such ■mechanisms increase the problems associated w ith visas expiring before, or while, they are in use.2 4.1.1.2 D iscu ssio n The use of Visa protocol for transit control may be appropriate if: (i) transit policies are as diverse as stub network policies, and (ii) policies change frequently. The former 'limits the practicality of expressing policies in a simple universal syntax. The second Jassumption also makes it impractical to distribute policies in the way that we distribute [connectivity information, for the fear of using stale route information or incurring exces- jsive overhead due to frequent information updates. These assumptions result in several ■interesting features of transit Visa protocol. First, organizational policies are embodied in ACSs and are not propagated outside; hence, a wide range of policy statem ents can jbe accommodated. Moreover, very little coordination among ADs (beyond that in Visa Iprotocol for stub networks) is required to implement this protocol. A lthough the extension of the Visa protocol concept to transit control is rather I [straightforward, the approach does not scale well to an internetw ork where many ADs, ;both stub and transit, want to control traffic flows. For example, acquisition of visa-keys jand route setup m ust be repeated (or adapted) each tim e an involved visa-router goes jdown. Moreover, a source AD has no way of determining if it will be issued a Visa without incurring the overhead of contacting the particular ACS in question. This leads us to a (not unexpected) conclusion th at transit traffic control is intim ately related to internetwork routing. Therefore, controls for transit should be incorporated in to the route calculation itself, not only into the packet forwarding function [13]. O ther network access control schemes such as SP3 [81] and router packet filters [61] face the same lim itation when it comes to controlling transit traffic, i.e., these schemes enforce controls on packet forwarding and do not provide inform ation to the route com putation. For example, SP3’s access control policy is endpoint-oriented. It is concerned m ainly w ith determ ining w hether or not two end-systems may communicate and what type of inform ation they may exchange. 2 More aggressive policies could also be im plem ented such as applying for group visas in advance of use to accom m odate a collection o f end-system s that have a need for com m unication. However, these may im ply significantly more trust am ong th e A D s and require more careful consideration. 68 In summary, Visa protocol and other network access control mechanisms are best suited for their original purpose, stub AD access control. Transit control for large inter networks is more efficiently achieved by integrating policy considerations into the route jcomputation process. After discussing policy-based routing in the next section, we return to the problem of secure control of transit internetwork traffic. 4.1.2 P o licy R ou tin g As described earlier, the central goal of transit traffic control is to allow ADs to indepen dently express and enforce policies regarding transit traffic. The discussion in the previous section dem onstrates th at transit control is intim ately related to Inter-AD Routing. We refer to inter-AD routing th a t incorporates policy constraints as policy routing (PR). Inter-AD routing constitutes the highest level of the OSI routing hierarchy as defined in 45]. In this section we concentrate one approach to policy routing, the Inter-Dom ain Policy R outing (ID PR) proposal [50, 84]. ID PR is designed to support m ore general transit policies than other policy routing m ethods discussed in C hapter 2. (For further discussion of inter-AD routing architectures see [7, 29].) Policy routing operates at the network layer. Only border routers and associated route servers are directly affected by the presence of the inter-dom ain routing protocols. lEnd-systems and interior routers continue employing internetworking protocols desired jwithin their particular ADs. Border routers operate on behalf of the end-systems. For (this reason, the term source hereafter refers to the border router in the AD of the source end-system. 4.1 .2 .1 I D P R A rch itectu re Inter-Dom ain Policy Routing architecture has been developed to support a wide range of policies. It incorporates mechanisms th at represent a rather radical departure from existing routing techniques.3 ID PR allows stub and transit ADs to express and exchange (routing and packet forwarding policies. The m ost distinguishing feature of this approach is the use of AD-level source routing. A Link State algorithm [56] is used to compute source Policy Routes (PRs) at the granularity of ADs. Each AD expresses its policies in I ja standard form, called Policy Terms (P T s), and distributes them to other ADs. Each 3T h is approach was first described by D. Clark in [13]. 69 AD designates special Route Servers (RSs) to collect PT s and compute policy routes for constituent users. The basic assumptions of this model are: 1. Most policies can be classified and expressed in a standard notation. 2. Policies and inter-AD connectivity change relatively slowly. 3. End-point specific policies should be supported. Two prim ary concepts in this proposal are Policy Routes (PRs) and Policy Terms (PTs). A P R is an ordered sequence of ADs, i.e., an AD-level source route. In other words, there may be m ultiple physical realizations of a P R given m ultiple physical connections between ADs and m ultiple intra-AD routes. The actual selection of a particular physical path is done at packet forwarding tim e by each intervening AD, rather than by the source AD at route com putation or route selection tim e. This lazy evaluation provides for a more adaptive protocol and unrestricted AD interconnection. Policy Terms (PTs) are the units of routing inform ation exchanged by communicating ADs. Each P T represents a distinct policy of the AD th a t expressed it. The inform ation distributed in a P T can be represented as:4 (4.1) [(Jl a, A D a, A D ent), (Hb, A D b, A D exit), U C l, Conditions) The purpose of a P T is to specify th at packets from some end-system (or a group thereof), \Ha, in a stub AD, A D a, are allowed to enter the AD in question via some directly con n ected AD, A D ent, and exit through another directly connected AD, A D exiti on its way to or from an end-system, H b, in another stub AD, A D b. User Class Identifier (UCI) allows policies to distinguish between various user classes, e.g., Government, Research, Commercial, Contract. Conditions represent quality of service, billing, and other vari ables, and can reflect the agreements between neighboring ADs. Examples of the Policy Terms can be found in [26, 13]. Policies are expressed by source, destination, and transit ADs. The source AD may select all transit ADs while transit and destination ADs control which source and des tination ADs can communicate via which directly connected ADs. ADs run link state routing algorithm s to compute their respective tables of PRs. There may be multiple PRs listed for the same destination AD, each with a different set of conditions associated w ith its use (e.g., QoS, time-of-day, or UCI). 4T his is a sim plified version o f the actual P T form at used in the protocol. However, the differences are not relevant to this discussion. 70 Note th a t ADs (w ith the exception of the source AD) do not exert control over the entire Policy Route. Referring back to our travel analogy, it is difficult to enforce policies ithat are based on inform ation th a t is not verifiable at the point of reference. For example, 'it is difficult to enforce a policy th a t dictates non-adm ittance to anyone who has ever [passed through country X , since it is very much dependent on X stam ping passports Ireliably. In the environment of interconnected ADs, a transit AD can verify the previous jand next hops because of its direct connections and the feasibility of employing pairwise authentication w ith the relatively small number of neighbors. Verifying other transit components of the PR is difficult, if not impossible. If the end-point authentication described in later sections is not employed, spoofing of end-point addresses en route will result in violation of some end-point specific transit policies and possibly inappropriate billing of the endpoints for transit services. However, the functionality available to the interlopers is lim ited- they can send packets in between the indicated endpoint ADs. In contrast, if the spoofer modifies p ath inform ation other than the end-points and previous and next hop in order to be perm itted by a transit A D ’s p ath specific policies, the spoofer is not constrained in the m anner in which it can ^exploit these policies. ! Each AD has one or more Route Server (RS), an entity th a t collects Policy Routing i inform ation from other ADs, distributes local policy inform ation to other ADs and com putes, as well as issues, PRs to local end-systems. Actual policy enforcement is done at a Policy Gateway (PG ) which, in addition to the usual task of forwarding packets, handles validation and verification of the PRs attached to the incoming packets. A path is established with the first packet carrying the full PR , i.e., the complete sequence of ADs in the route and applicable P T identifiers. PG s along the route make sure th a t the P R agrees w ith the local PT s (through use of tem plates, for example). The result is cached so th at a specified P R handle can be used in the future to refer to the cached entry. Successive packets carry a short PR handle, not a full PR. Many transport level sessions, and even pairs of end-systems, may share a single PR if the ipolicies enabling it are not end-system-specific; this reduces the average latency and state overhead for intervening PG s. PGs use P R handles in the packets to check for cached entries. PGs also may relate return flow packets with forward flow. Given information about the next AD for a particular packet, each PG selects the next PG based on the inform ation exchanged in a traditional up-down protocol. 71 4.1.2.2 D iscussion Policy routing allows ADs to interconnect to the global internet while still protecting network resources from general, unconstrained use. (We described earlier why such a function can not be left to end-systems.) However, policy routing mechanisms do not preclude the need for network access controls in the border routers of ADs th a t wish to control access to individual end-systems. This subject has been extensively discussed in C hapter 1. One essential difference between Visa protocol and policy routing approaches is the per session setup overhead. Transit Visa protocol requires th at a dialog transpire between the source and each transit ADs’ ACS, and th at corresponding keys be distributed. Con sequently, the initial setup delay grows in proportion to the num ber of transit ADs in a PR. For short transactions such overhead is not acceptable. A policy-sensitive approach such as ID PR avoids this setup dialog through background distribution of policy infor m ation th at is used in route com putation. The work th at the Policy Routing protocols do to distribute policy term s and compute authorized routes m ust be done at the tim e of the session setup in Visa protocol. In particular, w ith transit Visa protocol this translates into a dialog w ith an ACS for each AD in the path. Moreover, this assumes th a t the source attem pts communication over a p ath for which it has authorization. If there is a conflict w ith even a single transit A D ’s policy, the process must begin again. Policy Routing incorporates policy into the •route com putation process in advance of the actual communication, thereby avoiding this t Jproblem. I On the other hand, policy-based routing, as described thus far, relies on post-facto detection of abuse, and, is in th a t sense less secure than network access control schemes, such as Visa protocol. The rem ainder of this chapter addresses the integration of preven tative mechanisms into policy routing to achieve secure control of transit traffic for those ADs th a t desire it. 4.2 S e c u r ity Issu es in T ran sit C on trol In this section we identify potential security threats faced by policy routing and detail the steps needed in a secure protocol. 72 4.2.1 Specific T hreats The two basic threats to the security of a P R protocol are falsification of routing infor m ation and falsification of d ata packets. 1. An intruder may distribute false routing inform ation in order to (i) disrupt com m unication, e.g., create routing loops, or (ii) eavesdrop on communication, e.g., re-route traffic to a specific location. This can take the form of distributing falsified or prerecorded PG U P/D O W N inform ation which may cause stub ADs to compute PRs th a t are desired by the intruder. Also, falsified Policy Terms can be similarly distributed which may result in invalid PRs being computed. 2. If routing protocols protect themselves by prescribing an authentication mechanism for validating routing inform ation, the intruder can turn to falsifying control and/or d ata packets. This kind of attack can lead to unauthorized resource usage, unau thorized communication, and inappropriate accrual of charges. We identify three sub-threats: (a) Falsification of control inform ation In addition to the usual network layer inform ation (source and destination addresses, data size, etc.), control inform ation includes the route setup and packet forwarding param eters. An intruder can also steal a P R handle created by an authorized AD and substitute an invalid Charge Code. (b) Falsification of data D ata portion of a packet can be modified or replaced by an intruder. (c) Replay Previously-recorded legitim ate packets can be replayed by an intruder. Two J sources of replay are of equal concern: accidental replay due to the stuttering of a misbehaving machine, and malicious replay due to a misbehaving person attem pting a denial of service attack. In the rem ainder of this chapter we describe and analyze mechanisms to resist these threats. Our approach is not inconsistent with the original proposal in IDPR. The prevention-based (as opposed to detection-based) measures proposed here can be included as optional features w ithin the protocol. 4.2.2 T erm inology The following terminology is used throughout this chapter: 73 • || is the concatenation operator, e.g., X\\Y. • N denotes the length of a PR , i.e., the number of ADs in a PR. • A D i (0 < i < N ) denotes the i-th AD in a PR , A D \ = A D src and ADjy — ADast. • K I denotes a secret key shared by AD i and ADj. • Kdsig denotes a secret key used for computing d ata signatures. • EK{, D K i denote public (encryption) and private (decryption) keys of AD i. • E {D a ta )K and D(Data)K denote encryption and decryption, respectively, of D ata w ith key K . m Fhash(Data) is a one-way hash function digest of D ata. In the next three sections we consider separately security issues pertaining to different phases of Policy Routing: distribution of PT s, PR setup and packet forwarding. In each of these phases we are concerned prim arily w ith d ata integrity and source authenticity. jConfidentiality of user d ata is left to end-to-end mechanisms [90]. Confidentiality of routing control inform ation is a less general requirement than integrity and authenticity, and is discussed briefly. Traffic analysis is not addressed here (per our discussion in C hapter 1). 4.2.3 D istrib u tion o f P olicy Term s In order to provide for secure distribution of Policy Term updates, each AD m ust be able jto sign its own, and authenticate incoming PTs. Because of the Link State nature of the protocol, P T updates m ust be flooded to ADs throughout the internetw ork so th a t all participant ADs can use them in their P R com putation. Before using a new P T , each AD needs to verify the authenticity and integrity of its contents. This is difficult to achieve in a conventional encryption environment, as the number of potential recipients of a PT update can be quite large.5 In general, conventional encryption is not well-suited for an environment such as Link State routing where routing updates are broadcasted to a large num ber of recipients. s Sharing a single com m on key am ong all nodes affords little protection, w hile distributing pairwise keys to each A D -pair is im practical. 74 The alternative is to use public key encryption for the distribution of PT s. At first glance, this might appear problem atic because current public key technology is still infe rior in term s of performance. However, we are not interested in the privacy, but only the integrity and authenticity of routing inform ation. Therefore, signature m ethods described in Appendix A can be used with little performance im pact. Moreover, one of the central 'assumptions in the ID PR proposal is th a t policies change relatively slowly. Any added (processing tim e associated with public key encryption is counter-balanced by the ubiquity and efficiency of being able to generate a single unforgeable packet signature which can be authenticated by any recipient. An example of a Link State routing protocol which uses public key encryption for routing update distribution is presented in [71]. Routing inform ation distribution is one area of policy routing where confidentiality measures may be considered useful. However, it implies th at the entire routing update m ust be encrypted s e p a ra te ly for each anticipated destination AD. In general, this is im practical regardless of the type of encryption used. Since a link state update is flooded throughout the internetwork (in this case, to all ADs), the num ber of potential jdestinations can be quite large. In order to achieve confidentiality in this environment, the source of a link state update needs to encrypt the update N times (where N is the to tal num ber of ADs). Furtherm ore, the traffic due to update propagation will increase JV-fold. For the rem ainder of this chapter we consider environments in which only integrity and authenticity of routing d ata is required and where public key encryption and the certifying jauthority mechanisms described in C hapter 2 are used for this particular function. Although the distribution of PT s raises a num ber of interesting issues, the underlying iconcept of broadcasting signed messages is not unique to Policy Routing.6 O ther aspects of secure Policy Routing, such as P R setup and packet forwarding, require more careful protocol design because of the associated costs and threats. 4.2.4 R ou te Setup P R setup phase requires th at each intervening AD have means to forward subsequent data packets along a specific Policy Route. As described in Section 4.1.2.1, each AD along the route m ust be supplied w ith the next hop AD at PR setup time. The purpose of PR setup jis to establish authorization in all transit ADs and create state in all intervening PGs. I 6W ith th e exception that routing updates are infrequent, thus, favoring the use of public key encryption. 75 Thus, Policy Routing decisions can be m ade in advance of the actual communication, and, subsequent d ata packets can carry a minimum of PR-related inform ation thereby reducing both overhead and latency. In order to recognize a bona fide PR, each AD m ust authenticate and authorize a PR. Authentication means verifying th a t a P R was issued recently by a recognized entity and was not tam pered with. Authorization entails making sure th at a P R conforms to local policy. i jMore specifically, secure P R setup needs to address two types of threats: jT ype 1. Creation o f fraudulent P R s or tampering with existing PRs. In order to defend against this th reat, each P R m ust be traceable to the issuing AD. In other words, it m ust be signed with an unforgeable signature. For all intervening ADs, jthis would provide for non-repudiation of issuance and sender authenticity. jT ype 2. Replay of previously issued setup packets. |This can be prevented if we include a tim estam p within each PR. The signature of a setup packet becomes dependent on this tim estam p, and, makes replay detection possible within jthe granularity of the tim estam p and clock synchronizations. As the number of setups is ■relatively small (in relation to the number of d a ta packets), relatively coarse tim estam p ^granularity (e.g., 1 m s) should be adequate and is preferable to the m anagem ent required jto keep track of unique sequence numbers. We note th a t, detecting replay of P R setup packets is very similar to th a t of VISA-REQUEST packets in Visa protocol (see C hapter 3). As with P T update distribution, we are concerned w ith the d ata integrity and au thenticity of the setup packets. However, unlike P T updates, PRs are set up relatively frequently and increased latency is experienced directly by the end-users. Thus, we are far more concerned w ith the per-signature overhead for P R setup than we are for PT ;distribution. Consequently we will investigate the use of both conventional and public i key encryption signature mechanisms. As discussed earlier, conventional encryption, implies a significant key m anagement burden, since an AD has to share a secret key w ith every other AD th a t it ever com m unicates with. Moreover, it entails computing a PR signature for every AD involved, whereas a single PR signature verifiable by all intervening ADs is sufficient in public key encryption. On the other hand, a typical P R traverses a relatively small num ber of ADs (N is usually much less than the diam eter of the internetwork). This makes conventional encryption a viable choice since a P R would only have to be signed N times. 76 The above discussion is a standard public key verses conventional encryption debate. Both m ethods have beneficial as well as burdensome features. In Section 4.3 we demon strate a PR setup protocol based on public key encryption, a conventional encryption variant is similar. 4.2.5 Packet Forwarding After a P R has been set up, subsequent d ata packets can take advantage of the PR state in interm ediate ADs. F irst, instead of a full PR , each d ata packet carries only an abbreviated version referred to as the P R handle. Second, the state in all intervening jPGs allows them to bypass expensive authorization checks on a per packet basis. A PR handle only needs to contain the inform ation necessary to identify the appropriate state in intervening PGs. Its exact contents are described in the next section. Assuming appropriate security measures to prevent P R setup threats above, there remains the possibility of attacks at packet forwarding time: T y p e 3. A n intruder can copy a valid P R handle from a legitimate packet, attach its own data and send it along a PR, thus, obtaining service fraudulently. This attack can be fully remedied if each d ata packet is signed by the source and the signature is verified at each transit hop. However, even m ore so than in the case of PR setup, processing delay is a critical concern with respect to forwarding of data packets. 'For this reason, m any ADs are likely to forego per-packet signature and verification of m ost traffic. We now discuss a spectrum of possibilities whereby ADs can trade the level of protection for the am ount of overhead incurred. There are three factors th at directly influence the cost of d ata authentication (we discuss them below): 1. Signature com putation m ethod 2. Signature coverage 3. Signature verification m ethod 4.2.5.1 S ig n a tu re c o m p u ta tio n jThe particular m ethod used in the signature com putation influences not only the over head but also the security of the packet forwarding protocol. The choice of a signature mechanism is mainly dependent upon the severity of the anticipated hostile attacks. If hostile attacks are not anticipated, the signature needs only afford protection against occasional non-malicious modification of d ata packets. This can be accomplished by using a simple, relatively weak CRC function (e.g., an IP-style CRC [73]). To protect against tam pering w ith legitim ate d ata packets, the signature function m ust have the property th at modification of d ata results in unpredictable changes in the Isignature. A strong one-way function such as MD4 or MD2 is a good candidate for this .type of protection. Protection against message substitution is more complicated. In addition to strong data integrity protection, the signature m ust be unforgeable, i.e., only a legitim ate entity m ust be able to compute a signature. This is not the case with one-way hash functions since anyone can produce an arbitrary message and compute its signature. In other words, [protection against message substitution m ust incorporate some notion of signature origin authenticity. Consequently, a secret quantity (i.e., a key) m ust be used in signature [computation such th at only the true originator can produce genuine signatures and all recipients can easily verify them. One simple solution is for the source to sign d ata packets in the same m anner as P R setup packets, i.e., using public key signatures. This satisfies our goals in th a t there is but one entity able to generate signatures w ith a given key. Moreover, since transit ADs are already in possession of the source’s public key (after processing setup packets), signature verification requires little additional work. Alas, all the benefits of this approach are overshadowed by the high cost of per packet public key encryption. Another possibility is for the source to m aintain pairwise secret keys w ith the signature verifiers, i.e., transit ADs. Then, every d ata packet would need to be signed N times (where N is the P R length) by the source using a different key each time. This implies significant overhead for long PRs in term s of encryption and added length.7 On the other hand, the security of this m ethod is almost as strong as th a t of public key signatures.8 Alternatively, the source can distribute a secret key during P R setup to be shared by all intervening ADs. (Thereby establishing a simple group channel). Then, only a single signature would be computed by the source and subsequently verified by all transit ADs. This m ethod is efficient in term s of com putation and added packet length. However, 7For long PR s, the overhead may actually equal or exceed that o f using a single public key-based signature! 8Strictly speaking, th e difference between them is twofold: i) public key encryption is generally con sidered m ore resistant to attacks, and ii) public key signatures provide n o n - r e p u d it a t io n o f origin (signatures generated using a shared key can not be unam biguously attributed to any m em ber of the group that shares the key). 78 because the key is shared, it becomes possible for any AD along the route to m asquerade as the source for the duration of the PR. Moreover, the key must be distributed without undue disclosure, i.e., only the intended recipients m ust be able to obtain it. Therefore, the key has to be encrypted N tim es, once for each transit AD. However, this expensive operation takes place only once per PR , at setup time. This subject is discussed further in Section 4.3. 4 .2 .5 .2 S ign atu re C overage Independent of the signature com putation m ethod, is the issue of signature coverage, i.e., jwhat p art of a packet has to be signed. Recall th at an IDPR-encapsulated d ata packet consists of: i) network-layer header, ii) PR header, and iii) data segment. M aximum protection against tam pering can be attained only if the entire packet is covered by the signature. Depending on the signature m ethod used, this may prove to be prohibitively expensive. Consequently, transit ADs may not care about the authenticity of the entire packet. One inexpensive alternative is to compute signatures over the network-layer header only. However, since a P R may be utilized by multiple end-system pairs, assigning sig nature keys per end-system pair complicates signature verification in transit PG s. This is because transit ADs m aintain state on a per P R ,‘not per end-system pair, basis. To rem edy this scaling issue, a single signature key m ust be shared for all end-system pairs utilizing a given PR. (Actually, since signatures are always generated by the source PG , 'little additional security is afforded by using signature keys on a per end-system pair basis, over per P R signature keys). If the source PG signs the network-layer header, an intruder can still tam per with the d ata segment. The utility of this type of attack is 'limited since the intruder is not able to alter end-system addressing inform ation. Another possibility is to sign only the P R header. This leaves the network-layer 'header and the d ata segment unprotected, but we can guarantee th at packets will travel jalong established, authorized PRs. The exact contents of a P R header are im portant in ’ assessing the vulnerabilities of this method. F irst, we suppose th at a PR header contains only a P R identifier th a t helps each transit AD locate the appropriate entry in its PR table. Then, all packets belonging to a given P R carry the same PR header and the same P R header signature. An intruder can attack in two ways: i) modify d ata segments of existing data packets, and ii) inject its own d ata packets complete with P R headers copied from valid d ata packets. The first attack is impossible to counter with this m ethod since d ata segments are not covered by 79 jthe signature. We can, however, address the second attack by m aking each PR header junique. The originator PG can include a unique tim estam p in the PR header of each jdata packet, which makes the signature dependent on the packet tim estam p. Hence, each packet carries a distinct signature. Furtherm ore, if we require transit PGs to record and i keep track of most recent packet tim estam ps on a per P R basis, duplicate and reordered packets can be easily detected [72] as described in Section 4.2.5.4 below. The accomplishment of this m ethod amounts to restricting the bandw idth available jto a potential intruder to, at most, th e b a n d w id th u tiliz e d b y th e le g itim a te traffic so u rce. In other words, an intruder can still intercept every legitim ate d ata packet, [substitute (or otherwise mangle) its d ata segment and inject it back into the traffic stream . Such fraudulent packets will not be detected in transit. However, an intruder is unable to: i) create its own P R headers, since it has no means of generating signatures, and ii) use any of the captured PR headers more than once, since transit PGs can detect duplicate and stale P R headers. Finally, both network-layer and P R headers can be protected. In this case, the desti nation stub AD is assured of the addressing authenticity, while transit ADs are satisfied th at packets flow along authorized PRs. We note th a t, insofar as transit ADs, the secu rity of this approach gains little protection over signatures covering only the P R header because network-layer headers are ’’transparent” to PGs. The above discussion leads to an im portant observation th at a typical transit AD may only be concerned w ith traffic not violating its policies, i.e., it m ay not care about the authenticity of the d ata therein as much as it cares about the traffic flowing to, from or through appropriate locations. In other words, as long as the packet indexes a valid PR, it is authorized to travel to its intended destination. To summarize our discussion, Table 4.2.5.2 illustrates the resilience of the various signature coverage methods to a range of hostile attacks. One curious detail in the above table is the sim ilarity between the cases of no signature protection and PR header signatures (without tim estam ps). These two methods differ only insofar as P R header modification is concerned. However, when a P R header does not include a tim estam p, i.e., it is constant for the lifetime of a given PR , its contents are reduced to a P R handle alluded to earlier. A P R handle is, essentially, an identifier th a t indexes an appropriate P R table entry in each transit PG .9 If the intruder modifies 9See Section 4.3.4 below. 80 R e p la y D a ta S e g m en t m o d ific a tio n A d d re ssin g m o d ific a tio n P R h e a d e r m o d ific a tio n N one N N N N* N e tw o rk h e a d e r N N Y N* P R h e a d e r N N N Y P R h e a d e r (tim e s ta m p e d ) Y N N Y N e tw o rk a n d P R h e a d e rs N N Y Y N e tw o rk a n d P R h e a d e rs ( tim e s ta m p e d ) Y N Y Y E n tir e p a c k e t N Y Y Y E n tir e p a c k e t (tim e s ta m p e d ) Y Y Y Y Table 4.1: Resilience of signature coverage m ethods the unprotected P R handle of a d ata packet, when this packet reaches its next-hop PG , two outcomes are possible: 1. The modified PR handle can not be m apped into a valid P R entry and the PG is forced to discard the packet. In this case, we conclude th a t the attack did not succeed. 2. The modified PR handle is m apped into a valid P R entry and the PG switches the ’’fraudulent” packet to the next hop (specified in the entry). The intruder’s goal in this attack is to generate fraudulent packet traffic, specifically, to send packets along PRs th at it has no authority to use. B ut, even if d ata packets carry signed P R headers (w ithout tim estam ps), the intruder can achieve the same result by recording PR headers (along w ith the corresponding signatures) of genuine packets and composing any num ber of fraudulent packets by concatenating any recorded PR header w ith an arbitrary d ata segment. Consequently, as long as data packets do not carry unique P R headers, P R header signatures do not contribute to the security of the protocol.10 4 .2 .5 .3 S ig n a tu re V erific a tio n A nother factor contributing to both the security and the overhead is the question of who checks the signature and how often. E n d p o in t If authenticating d ata in transit is prohibitively expensive, end-to-end data integrity similar to th a t in Visa protocol may be appropriate. Every d ata packet is signed 10T he only benefit afforded by header signatures is the ability to detect non-m alicious header m odifi cations, e.g., those due to noisy lines. 81 a t the source but is checked only at the destination. This approach has lim itations, most notably the fact th a t an intruder located at some point along the route can modify d ata in each packet and the forgery will not be detected until the packet reaches the destination AD. This can result in unauthorized use of transit resources and inappropriate billing of jthe source. On the other hand, per packet latency is low and independent of the P R ’s length. This approach provides preventative control for stub ADs, but only detection- based control for transit ADs. 'Full T ra n s it In environments where security concerns outweigh the overhead of extra iprocessing, the data portion of every packet is subject to forgery and must be checked j(for authenticity and integrity) at each hop on its way to the destination. Every data packet is signed at the source and checked at each AD hop en route. The protocol for this Jclass of environment has the highest overhead, commensurate with security requirements. The per-packet processing in this variant is similar to transit Visa protocol.11 jD esig n ated T ra n s it If Endpoint exposes transit resources to excessive misuse, yet Full Transit is too expensive, the source AD can designate at P R setup tim e a specific transit AD to perform d ata integrity checks. Every d ata packet is still signed at the source, but only one transit and the destination check the signature. The positioning of the ^designated AD in the P R is im portant: having it too close to A D src is almost equivalent |to no checking at all, whereas having it too close to AD^st is equivalent to the Endpoint variant. The designated AD can be reassigned from tim e to tim e in order to reduce the chance of its exploitation by an intruder. P a tte r n e d Instead of each transit AD having to authenticate each packet, it may suffice to authenticate every m -th packet. In the simplest version of this patterned authentication scheme, A D src would choose m at random from a locally defined range of values and then specify m during route setup. In this scheme only 1/m d ata packets are signed at the source and the same 1/m packets are checked. Transit ADs would either accept or reject the proposed m . If all ADs accept the proposed value for m, then every AD will check d ata integrity of every m -th packet. If any AD does not accept m (if it is considered too large or too small) then the source and all other ADs m ust choose a different m. In return for reduced overhead, if the value for m is discovered by an intruder then (m -l)/m of the P R ’s bandw idth can be abused. “ However, the Full Transit approach avoids the per-session setup dialog associated.w ith visa acquisition. 82 Moreover, the synchronization inherent to this protocol implies th at care m ust be taken to recover from lost and out-of-order packets. Alternatively, instead of the source choosing m , every tran sit AD i can choose its own rrii and elect not to disclose it. Or, a transit AD i could choose to authenticate each packet jwith probability pt . In this scheme all d ata packets are signed at the source, but only 1 /m -th (or p%) of the packets are checked per AD hop. This m ethod has the advantage of being flexible and robust in th at coordination among transit ADs is not required. An im portant disadvantage common to all patterned variants stems from the poten tially large variance in delay between ’ ’checked” and ’’unchecked” packets. Applications expecting little variance in delay (e.g., packetized voice) may therefore suffer. •R ound R o b in This scheme achieves constant per packet overhead by using round-robin (lata authentication. Transit ADs take turn authenticating packets. In general, packet num ber K is authenticated by a PG in AD^KmodM] where M is the number of ADs in jthe PR. All d ata packets are signed at the source but only one check is done en route to the destination. D estination checking can be added for extra assurance at the cost of a single additional decryption by the destination. Moreover, unlike Source Patterned jvariant, lost and out-of-order packets can be accommodated easily. On the other hand, AD independence m ust be sacrificed due to the coordination required to set up the round- robin arrangem ent. W hile this approach benefits from fair sharing of encryption costs {among transit ADs, it is only w orth considering in cases when the number of transit ADs is large, i.e., the P R is long. 4 .2 .5 .4 P r e v e n tin g R e p la y o f D a ta P a c k e ts The final type of attack considered is the replay of d ata packets: T y p e 4. A n intruder can replay previously recorded data packets, which can lead to unjustified charging and/or denial o f service. There are other, more serious threats posed by malicious replay. However, we are concerned prim arily w ith protecting network-layer resources; other replay attacks are assumed to be handled by the end-points. Also, we only need to protect against replayed packets within the life-span of the associated PR. After a P R expires or is closed all packets carrying the expired P R identifier will not be processed. Two sources of replay deserve equal consideration. The first is accidental replay due jto a misbehaving machine stuttering and generating replayed packets. The second is malicious replay due to an intruder intentionally replaying prerecorded packets in order 83 jto deny resources (or inflate costs) to the rightful owner. Neither kind of replay can be handled on a purely end-to-end basis because by the tim e a duplicate packet is discovered, jthe resources are consumed and associated charges are incurred, e.g., the bill reflects the replayed packet and the rightful user of the afflicted charge code can no longer obtain service due to an overdrawn account. In some circumstances, the post facto approach of replay detection and cost recovery may be adequate. This includes auditing packet counts, setting a lim it on the number of packets th a t can use a P R and other ad hoc methods. However, in sensitive environments, more aggressive prevention is required, albeit at some cost. Since our goal is to analyze jthe im plications of secure control of transit traffic, we present a m ethod for preventing replay. There are two basic approaches for countering replay attacks: i) nonce identifiers, and ii) tim estam ps.12 The m ain disadvantage of using nonces is the difficulty in their jverification. In particular, each relevant entity (each PG , in our case) needs to keep a complete history of past nonces which makes the verification inefficient. Tim estam ps are much better suited for this application. First, clocks need not be continuously synchro nized between the source and the transit PGs. This is because a P R setup packet is jtimestamped; its tim estam p can be used as a lower-bound for subsequent d ata packets in all intervening PGs. (It can also serve as an indication of the clock skew). Furtherm ore, if intervening PG s m aintain a more current lower-bound tim estam p (tiower), opportunities for replay can be reduced further. Consider the following protocol: 1. W hen a P R is issued, the originator PG tim estam ps the P R setup packet, and distributes the tim estam p, tsetup5 in & secure fashion to all intervening PG s in transit ADs. All transit PGs initialize their tiower values for this P R to t setup- 2. W hen a d ata packet is sent, the originating (first-hop) PG , tim estam ps its PR header. (Let tj.ata denote this value). 3. W hen this data packet reaches a transit PG , its PR header is examined and the tdata is compared to tiower. Three outcomes are possible: 12It can be argued that tim estam ps of sufficient w idth and granularity are nonces as well. However, a true nonce is a random ly chosen number that is hard to predict. 84 (a) tdata < tiower • The difference between the two values is examined. If it is small, i.e., less than some (locally defined) threshold, deltat , the packet can be forwarded. Otherwise, the packet is discarded. (b) tdata > tiower. In th at case, the packet is forwarded and tiower is set to tdata- Of course, a PG may get suspicious if the difference is too large. (c) tdata = tiower ■ This can occur when two successive d ata packets belonging to the same PR stream carry the same tim estam p. To distinguish between such packets, it would be necessary to keep additional inform ation, e.g., a packet signature, for the last d ata packet processed. However, it is desirable for the clock rate to be at least as fast as the maxim um packet rate. This would preclude duplicate tim estam ps on d ata packets. This protocol prevents m ost, but not all, replay attacks. In order to prevent all replay attacks, deltat values m ust be set to zero in all transit PG s, which would essentially disallow any out-of-order d ata packets. This is a choice th a t will not be practical for internetwork environments where out-of-order packets are a frequent occurrence. 4.3 P r o to c o l D e sc r ip tio n Based on the above discussion of security issue, this section describes the secure policy routing protocol. The following design choices are made: • All P R setup control packets are protected by signatures computed w ith the private key of the originating entity. • A secret key is distributed to all intervening PG s as part of P R setup. (This key is subsequently used to compute d ata packet signatures). As described in Section 4.2.5.1, the key is enciphered N tim es, once for each intervening AD using th a t A D ’s public key. • D ata packet signatures can be computed a range of signature methods. The par ticular m ethod, is negotiated at the tim e of PR setup. • Signatures cover either the entire packet or only the (tim estam ped) P R header. The choice is m ade at the tim e of P R setup. • A transit ADs is free to choose on a per PR basis w hether or not to authenticate d ata packets. 85 • All packets (control and data) are tim estam ped at the origin. No two packet of the same origin and type can hear identical tim estam ps. Clocks are assumed to never run backwards. After describing protocol participants and packet handling rules in the next two sections, protocol details are presented in Sections 4.3.3 and 4.3.4. 4 .3 .1 P a r tic ip a n ts Policy Gateways (PG s) are the principal participants in both P R setup and packet for warding protocols. In P R setup, a Route Server (RS) is initially consulted for a route, however, the PG-RS interaction is strictly intra-A D , which makes it of little interest in jthe context of our discussion. Unlike Visa protocol, end-systems need not be involved in |the protocol; P R setup and PR-based packet forwarding are completely transparent to them. W ith respect to a single PR , there are three types of PG s:13 • O rig in a to r is the first PG in a PR. Its task is to associate outgoing packets with appropriate PRs. W hen the originator receives a d ata packet it first looks up the source and destination network addresses in its end-system table. Each entry in this table points to a P R entry in the PR table. Using the inform ation from the PR table, the originator constructs a PR header and attaches it to the packet. • T ra n s it is any interm ediate PG in a PR. A transit P G ’s m ain task is to route d ata packets to next-hop adjacent PG s. Each d ata packet carries a P R handle (see below) which a PG uses to lookup a corresponding entry in its PR table. Each entry contains (among other things) the next-hop PG address. • T a rg e t is the last PG in a PR. Its task is complementary to th a t of the originator PG , i.e., it has to remove PR headers from d ata packets and forward them to the destination end-systems. In summary, the requirements for a PG are as follows: • m aintenance of active PRs • m aintenance of local P T s (for validating SETUP packets) 13See also Figure 4.1. 86 • a means for computing and verifying public key signatures (for all control packets) • support for a range of signature methods |The above is in addition to the more traditional routing-related requirem ents, e.g., mon itoring the reachability status of adjacent PG s:1 4 4 .3 .2 P a c k e t H a n d lin g Protocol participants distinguish between two types of packets: control and data. Control ipackets are used for route setup and m aintenance, dissemination of link-state P T updates jand PG status messages , i.e., all packets intrinsic to ID PR. Of these, only control packets ipertaining to route setup and m aintenance are relevant to our discussion.15 The balance of the internetw ork traffic consists of data packets. Control and d ata packets differ in the m anner they are processed by the PG s. Control packets are transm itted reliably. Each control packet is acknowledged on a hop-by-bop basis (i.e., between adjacent PG s). If a control packet is not ACK-ed w ithin a predeter mined interval, the sender retransm its. After attem pting n (n is a locally defined value) successive retransm issions, the sender PG gives up and informs the control packet’s source of the failure to deliver. All control packets are uniquely identified by the com bination of: i) packet type (SETUP, REFUSE, A C C EPT, etc.), and ii) PR handle which refers to a particular PR. This combination is guaranteed to be unique, i.e., no two control packets of i the same type carry the same PR handle. Every control packet is signed with the secret key of its originator, so as to allow all interested parties to authenticate its contents. After receiving and authenticating a control packet a PG replies to the previous hop PG with an ACK packet containing the identifier of the control packet being acknowledged. An ACK is used only between adjacent PG s. It is protected by a signature of its sender and contains the packet type and the P R handle of the control packet being acknowledged (see Figure 4.3.2). It does not, however, include the address or any other identifier of the sender. This is because the intended recipient of an ACK can unambiguously associate a P R handle w ith an adjacent PG which, in turn, determines the key to be used for signature verification. Unlike control packets, d ata packets are not acknowledged at every PG hop. Their transm ission is inherently unreliable, since a P R may traverse a number of lossy datagram 14O nly PG s in stub A D s are expected to com pute routes. A lso, since local policy serves as one of the inputs to route com putation, A D s are expected to use different procedures for route selection. (See [84, 28] for more inform ation). 15For a detailed description, see ID P R A rchitecture and ID P R Specification docum ents [50, 84]. 87 subnets. One sim ilarity between control and d ata packets is th a t both carry P R handles. PR handles allow transit PGs to associate d ata packets with P R table entries and route d ata packets according to the inform ation stored therein (i.e., the next hop PG ). 4 .3 .3 P R S e tu p iThe protocol begins w ith a data packet arriving at a PG in A D src. W hen this PG jdiscovers th a t it has no active P R for the source-destination end-system pair in th at packet, it contacts a local RS and asks for a new P R to the destination AD. (Hereafter, the requesting PG is known as the originator.) RS replies w ith the full path: (4.2) P R = [ S E G M E N T t , S E G M E N T 2, ..., S E G M E N T n ] 'Each segment contains: S E G M E N T i = [ A D i , V A L I D i ] for (0 < i <= N ) where V A L I D i is the inform ation th a t A D i can use to validate the PR (e.g., a list of applicable Policy Term s).16 Now, the originator composes a new P R SETUP packet. Included in the packet is the unique tim estam p, T S src■ SETUP also contains the Authentication-type and Expiration fields which serve the same purposes as their respective counterparts in Visa protocol, i.e., authentication m ethod for subsequent data packets, and, P R expiration conditions, respectively. A SETUP packet is protected by the signature of its originator: (4.3) S I G src = [Fhash( P seiup)]D K - where D K src is the secret (signature or decryption) key of A D src and one-way hash function (such as MD4) and a strong encryption function (such as RSA), the signature is sufficient to m aintain the integrity of the PR SETUP packet. Freshness is attained by T S src w ithin the SETUP packet. In order to allow for the authentication of subsequent d a ta packet traveling along this PR , the originator PG needs to generate a new d ata signature key, ICdsig, for use in w hatever per-packet variation is used.17 K d sig must be communicated in secret to each 16N ote that a P R carries no inform ation regarding individual end-system pairs. T his is because all PR s | are in itially validated on the basis of A D src, ADdst and usage conditions. If a transit A D ’s policy terms are end-system specific, that A D can verify end-system addresses at the tim e of packet forwarding. 17A ctually, Kdsig is not necessarily a key, per se. It is a secret quantity to be used in data signature com putation. 88 A D i ■ This requires th a t A D src encrypt Kjsig N tim es, i.e., compute E{Kdsig)EK' for all AD i. The resulting P R SETUP packet is depicted in Figure 4.3. As the PR setup packet propagates along the route, each transit PG in the PR performs the following checks: 1. Validates the tim estam p, T 5 src* 2. Recomputes and verifies S IG src- 3. O btains Kdsig by decrypting E(Kdsig)DK' ■ 4. Validates the PR by checking the V A L I D i held in the corresponding route segment field. At this point, if the setup packet passes all checks, the transit PG is assured th at: (i) the P R is valid, i.e., does not violate local policy, (ii) the P R is authentic, i.e., issued by a recognized entity; and, (iii) the PR is fresh, i.e., issued recently. In other words, each A D { is protected against attacks of T y p e 1 and T y p e 2. Finally, the PG creates a new table entry for the new P R and computes the next hop PG using the next hop AD specified in the next PR segment. If the setup packet fails one of the above checks, the transit (or target) PG in question informs the originator via a REFUSE packet. (See Figure 4.4). Unlike a SETU P packet, a REFUSE bears no tim estam p of its own, since there can be at most one REFUSE packet for a single SETUP packet. Instead, a REFUSE packet contains the tim estam p and the A D src field of the corresponding SETUP packet which helps the originator in identifying the exact SETUP packet being rejected. A REFUSE packet is protected by a signature of its creator, so th a t all interested parties can verify th a t it has been generated by a recognized entity, i.e., by one of the PG s in the route. (S IG i in Figure 4.4 refers to the signature generated by the i-th hop transit AD). Upon receipt of a REFUSE all PGs tear down the state inform ation pertaining to the P R mentioned therein and forward the REFUSE to the next PG in the direction of the originator PG. A fter a SETUP packet successfully passes through all transit PGs, it finally reaches the last-hop, target PG. After validating the PR, the target PG informs the originator of the setup completion by means of an A C C EPT packet (Figure 4.5). An A C C EPT packet carries only the P R handle. Unlike a REFUSE, it does not need to include the identity of the originating AD. This is because an A C CEPT can be generated only by a target PG in the destination AD. 89 As an A C C E PT propagates through each transit PG on its way to the originator, it enables the (hereto dorm ant) corresponding PR table entry. In other words, an A CCEPT signifies th a t the P R has been fully authorized by all parties involved. W hen the A CCEPT finally reaches the originator PG , d ata packets can, at last, start flowing along the newly established PR. Failure to receive an A C CEPT w ithin a pre-determ ined period of tim e, causes the originator to generate and re-send a new SETUP packet for the same PR. The new SETUP is essentially the same as the original one except for the T S src field which must reflect the current clock reading. This is done so th at all parties involved can distinguish between successive setup attem pts for the same route. For example, if the originator times out prem aturely and generates a new SETUP while the A C C EPT for the original SETUP is still en route, it will be able to decide unambiguously th a t the A C C EPT corresponds to the original SETUP packet, not the retransmission. 4.3.3.1 P R Setup Summary In summary, P R setup involves the following steps:18 1. A D src = *► A D 2 : S E T U P 2. A D 2 =$■ A D src : AC K grc 3. AD i => A D i+i : S E T U P 4. A D i+1 =► AD i ■ ■ A C K \+ 1 5. A D n- t =► A D dst : S E T U P 6 . A D dst = ► A D n— \ : A C K ^ 7. A D dst => A D n- i : A C C E P T 8 . A D n- i = > A D dst : A C K n d~x 9. A D i = * • A D ^ : A C C E P T 18T he notation A = > B : P A C K E T m eans ”A sends P A C K E T to B 90 10. ADi-1 =► ADi : ACK\~x 11. A D 2 =>- A D src : A C C E P T 12. A D Src =► AT>2 : A C ir|rc 4 .3 .4 P a c k e t F o rw a rd in g In order to make use of an existing PR , the originator PG must be able to supply infor m ation necessary to associate each d ata packet w ith a specific PR. This inform ation is placed in the PR header: (4.4) PRhdr = [ADsrc,TSsrcTSpackety D S IG \ The combination of A D src and T S src forms the PR handle m entioned above. Transit PGs are able to look up the appropriate PR in their tables using the PR handle, [A D src, T S'srcL as a look-up key. T S packet is an optional packet-level tim estam p used for detecting old and out-of-order d ata packets. Finally, D S IG is the (also optional) packet signature used to protect against T y p e 3 attack. D S IG 's verification is subject to the authentication m ethod agreed to upon PR setup. 4 .4 S ecu rity A n a ly sis We now discuss the security of the proposed protocol considering separately the route setup and packet forwarding phases. 4 .4 .1 P R S e tu p Successful P R setup involves the transm ission of a SETUP packet from the originator PG along the PR and the subsequent transm ission of an A CCEPT packet from the target PG along the inverted PR. 91 4 .4 .1.1 SE T U P P rocessing 'A SETUP packet is signed w ith the secret key of the originator and tim estam ped with a unique tim estam p. This allows any transit PG to establish th a t the SETUP packet i) was sourced in A D src,19 ii) was not modified in transit, and iii) was generated recently. \ J In addition, a transit PG can attem pt to verify th at the P R being installed does not violate local policy by checking the SETUP packet for compliance w ith the PT s referenced therein. A P T can restrict any one of the following (see expression 4.1): i 1. Source AD 2. Source end-system 3. D estination AD 4. D estination end-system 5. E ntry AD (i.e., previous AD hop) 6. Exit AD (i.e., next AD hop) 7. User Class, Type of Service and other characteristics [84] Of the above, only items (1) and (6) can be effectively verified. Source AD is established as part of validating the SETUP packet’s signature. Exit AD is established by the com bination of: i) checking the next AD segment within the P R and ii) physically forwarding the SETUP packet to th at next hop AD and receiving ACK in response. Although, in theory, PT s can be used to restrict source or destination end-systems, such restrictions are generally im practical. The reason for this is twofold. F irst, it is im practical for transit ADs to be concerned with large numbers of objects at the granularity of end-systems. Second, (also because of scale) it is difficult to authenticate traffic on the basis of signatures generated by individual end-systems, since m any end- system pairs can be associated w ith a single PR. If a transit AD still decides to include end-system restrictions in its PT s, it has to t r u s t the end-point PG s to issue PR s only to appropriate end-systems. Nevertheless, an AD m ight restrict access for a small number of select end-systems using this method. Verification of the previous AD hop is complicated by the fact th a t a SETUP packet does not reflect the actual traversed route (which m ay be different from the one it car ries). In other words, a PG in a transit AD receives a SETUP packet which specifies i 19For sim plicity, we assum e that all PG s in the sam e A D share the sam e public-key pair. some adjacent AD as the previous hop. However, this gives no assurance of the SETUP 'packet having actually passed through the adjacent AD in question. For example, a link connecting two adjacent ADs may also be shared by other entities, any one of which could jhave forwarded the SETUP packet. | Even the destination AD is not verifiable at SETUP processing tim e. A transit AD can merely conclude th a t the last AD hop in the P R is the apparent destination. Stronger .conclusion can be made only upon receiving a corresponding A C C EPT packet (see below). I For transit ADs, this uncertainty may serve as grounds for not accepting any d ata packets for a P R before receiving ACCEPT. Finally, verification of User Class, Type of Service and other restrictions based on traffic characterists is not possible at PR setup time. For example, if a P T contains User Class restrictions, the originator can lie about the User Class of the intended traffic source. Unfortunately, a transit AD has no means of detecting such abuse. A sole exception is the D ate/T im e restriction which specifies the tim e intervals when a certain P T can be used. It is trivial to establish compliance with a D ate/T im e restriction at SETUP processing time. 4 .4 .1 .2 A C C E P T P ro cessin g An A C C EPT packet is signed by the target PG (in the destination AD) and bears the PR handle of the corresponding SETUP packet. This allows all transit PGs and the originator PG to verify its origin and contents. Timeliness is derived from the presence of the P R handle, i.e., since the SETUP bearing the same P R handle was observed recently and the P R handle is unique, the A CCEPT packet is also unique, hence, it must have been recently generated. W ith respect to the overall validity of a PR , a bona fide A C CEPT packet adds the following: • By virtue of checking the packet signature, the destination AD is finally verified. • The A C CEPT packet itself implies th a t the destination AD validated the PR. Little else can be derived from an ACCEPT. We observe th at the beliefs derived from a bona fide A C CEPT packet fall short of assuring the originator th a t A L L transit ADs (PG s) have validated the PR and established the necessary state. Since the A C CEPT is signed by the target PG (and carries w ithin it the P R handle of a recently sent SETUP packet), the originator PG is assured th a t the SETUP packet somehow reached the ADdst 93 .and th a t A D dst validated the PR. Nonetheless, there is no direct evidence to support the i ;claim th at the SETUP passed through (and was approved by) all transit ADs. In other ; 'words, either (or both) SETUP or A C C EPT packets may have traveled along a route 1 different from th at specified in the PR . This type of anomaly appears unlikely as it 'requires active interference on the p art of one (or more) transit ADs. 1 ' < In order to derive stronger beliefs about setup completion, the originator must be assured by each transit hop individually. This can be accomplished if we require each ' .transit PG to sign the A C CEPT as it travels towards the originator. Then, upon verifying all of the trailing signatures, the originator can be satisfied th a t all transit AD have, in ■fact, authorized the P R and established the necessary state. The main drawback of this mechanism is, of course, the additional overhead due to signature com putations and verifications (as many as there are ADs in the PR ). Moreover, the added complexity of this mechism is only worthwhile if subsequent data packets are treated similarly. 4 .4 .2 P a c k e t F o rw a rd in g As discussed in Section 4.2.5, unless a strong authentication m ethod is used in conjunction w ith replay prevention, a transit PG can derive very little insofar as the goodness of a data packet. If a packet’s PR handle indexes a valid P R in the P R table, the only conclusion th a t a transit PG can make is th at the traffic flow which this packet purports to be a part of, has been previously authorized. Stronger beliefs are unattainable without a stronger . proof of the relationship between the packet and the P R th a t it indexes. W ithout any authentication, only packets bearing invalid PRs can be detected. If only PR header is authenticated (w ithout replay prevention), no additional security is gained. ■ Since all packet belonging to the same P R carry the same ” authenticated” PR header, an intruder can duplicate this header indefinitely (for the lifetime of the PR ) attach its own ‘ d ata and inject the resulting traffic into the stream unnoticed! If replay prevention is used, each P R header is distinct by virtue of carrying a unique tim estam p (hence, a unique P R header signature as well). A transit PG can establish the origin and timeliness of each d ata packet,20 however, the authenticity of the d ata segment is still suspect. Since the intruder is no longer able to duplicate P R headers, the only venue of attack left is to mangle existing d ata packets (e.g., substitute d ata segments). Still, this level of protection is relatively inexpensive and quite effective considering th at it makes it impossible for the intruder to i) replay old packets and ii) create more packets 20As described in Section 2.2.3, tim eliness depends on the particular A t used. 94_j than generated by the true source. The latter protects against inflated charges and packet ; storms. Finally, akin to SETUP and A C C EPT packets, d ata packets convey no inform ation about the actual route taken. Moreover, because d ata packets are not acknowledged on hop-by-hop basis, neither previous nor next AD hop can be verified. 4.5 A sse ssm e n t an d C ost Our purpose in this section is to investigate bounds on achievable d ata rates w ith the security schemes described above. Previous work in the area of performance and cost evaluation of secure protocols [27] identifies four im portant overhead contributors (listed in the order of magnitude): • Per Packet Signature • Increased Packet Length • Setup Overhead • O ther Additional Per Packet Processing In the rem ainder of this section we analyze each of the above contributing factors in several variations of the general scheme. 4 .5 .1 P a c k e t S ig n a tu r e s As discussed earlier in this chapter, per packet signature costs are largely dependent upon the particular variation of packet signature checking, signature com putation m ethod, and signature coverage. Previous results in measuring Visa protocol overhead [32, 27] suggest th a t, whenever encryption or encryption-based signatures are used, the overhead becomes quite noticeable. In C hapter 5, we illustrate experim ental results using non-cryptographic packet authentication techniques. Replay prevention can be used independent of the d ata authentication m ethod. The cost of replay prevention am ounts to one additional P R header field (32-64 bits depending on the tim estam p granularity) and several instructions for implementing the protocol [described in Section 4.2.5.4. 4 .5 .2 C o sts D u e t o In c r e a se d P a c k e t L e n g th 'Increased packet length is incurred by the P R header carried in every d ata packet. Recall l(see 4.4) the P R header carries the AD identifier of the source and the tim estam p of the ^original setup packet. Assuming 32 bits for A D src and (at m ost) 64 bits for T S src, these jtwo fields add up to 96 bits. Depending on the requirements for data authentication and replay prevention, P R header may include a packet tim estam p and a d ata signature. The ■former is a 64-bit quantity. The length of the d ata signature depends on the particular Jsignature m ethod and can vary between 64 bits (e.g., DES MAC) to 128 bits (e.g., MD4). Thus, we can anticipate th a t the length of the P R header will range between 96 and 288 bits. Previous m easurements of Visa protocol im plem entations [27] show th at this overhead ranges from 20% for small (e.g., 16 bytes of user data) packets to less than 4% for larger, e.g., 1Kbyte, packets. (The length of a visa header is roughly the same as th at of a P R header). 4 .5 .3 S e tu p O v e rh ea d ■PR setup is accomplished by composing and sending a packet containing the entire PR ;as described in Section 4.3. The costs include: • N conventional encryption operations by A D src to encrypt Kdsig for all intervening ADiS, if d ata packet authentication is desired. • A hash function com putation over the entire P R setup packet followed by a single public key signature com putation over the hash function value. • N hash function com putations and N public key signature verifications for verifying the setup packet signature era route (one at each A D i). • N decryption operations by each AD i to decrypt Kdsig- However, this can be done after the setup packet is forwarded to the next hop and so does not contribute j directly to the setup latency. i The above is the worst case scenario. Some ADs may not care to authenticate PRs upon setup. Furtherm ore, if P R authentication and integrity requirem ents (or lack thereof) are expressed in a transit A D ’s PT s, the source AD can avoid unnecessary signature com putation and reduce the setup overhead. M easurements of PR setup overhead are presented in C hapter 5. 96 4 .5 .4 O th er P er P ack et P r o c e ssin g C osts Additional (other than encryption) processing costs are incurred mainly by the added ^ logic in routers for processing of PR-based packets, in particular, table lookups. • | Each PG m aintains a P R table where each entry corresponds to an active PR. Not ; 'all PGs look up this table directly. A PG in a stub AD acts m ainly as an originator and does not search its P R table; instead it searches the end-system table with source- 'destination end-system addresses. Each entry in the end-system table points directly to the corresponding PR table entry. Transit PGs, on the other hand, have to perform : direct PR table lookups. P R tables in transit PGs are anticipated to be several orders of m agnitude larger than those in stub PGs. Therefore, lookup costs are of concern. However, if entries are hashed on PR handles using a uniform hash function [41], the cost of a P R table lookup can be expected to be negligible (on the average). In addition to authentication and lookup costs, there is also the cost of P R m ainte nance. For each d ata packet switched, a corresponding PR table entry is updated. This includes increm enting several counters and refreshing two tim estam p values (see Chapter 5). The cost of these operations is greatly overshadowed by other overhead-contributing factors. 4.6 C o n clu sio n s Transit control mechanisms are needed by interconnected ADs to retain their autonomy in setting and enforcing policy while still achieving desired connectivity. The problem of interconnecting A dm inistrative Domains and navigating across them is im portant be cause the policies in question concern control of resource access and usage. Moreover, the security of the transit policy enforcement is im portant, especially, in sensitive envi ronm ents. On the other hand, the security measures, as can be expected, take a toll in overall system complexity and performance. The purpose of this chapter was to investigate the design of tran sit policy enforce ment mechanisms for sensitive environments, to analyze their security and to evaluate the performance overhead. We began by attem pting to extend existing network access control m ethods to the more general transit environment. Subsequent evaluation identi fied several basic deficiences of the resulting extension. These deficiencies m otivate the integration of policy enforcement into the internetwork routing, route com putation, and 97. packet forwarding protocols. We used Inter Domain Policy Routing (ID PR) as the foun- I dation for the protocol design. After identifying potential security threats we presented the secure Policy Routing protocol and analyzed its security and performance im pact. | i ; Security of the transit control mechanisms should be approached from an integrated ' perspective. It exists in the context of end-system and network access control, hence, ; the division of labor deserves careful consideration. In this chapter we proposed th a t Policy Routing be equipped to prevent unauthorized use of network resources, and exert control over routing across AD boundaries. Network access controls are responsible for finer grain control (e.g., on an end-system, as opposed to AD basis) and end-systems for protection of non-network resources. The proposed mechanisms were designed to support inter-operability across ADs with heterogeneous policies to the extent th a t their combined policies allow. Legend: inter-A D link O RIGINATO R intra-AD path T R A N SIT A D boundary TARG ET Figure 4.1: Policy Gateways in ID PR Packet type (=A C K ) Ack-ed packet type PR handle S I G sender Figure 4.2: ACK packet Packet type (=SETUP) A D ,rc T S s Authentication-type Expiration PR E{Kdsig) ^ EjKdsig)^ E ( K dsigf ^ S IG Src Figure 4.3: SETUP packet Packet type (=R EFU SE) A D src T S S rc AD i Reason S IG i Figure 4.4: REFUSE packet Packet type (=A C C EPT ) A D s t c T S src SIGdst Figure 4.5: A C CEPT packet C h a p ter 5 E x p e r im e n ta l R e su lts ‘ In Chapters 3 and 4 we presented the design of stub and transit policy enforcement •mechanisms, respectively. In order to support onr design choices and to dem onstrate the feasibility of deployment, this chapter describes the experiments conducted w ith proto type im plem entations of the proposed protocols. The purpose of the experiments was twofold: i) to verify the functionality of the im plem entation, and ii) to measure the overhead imposed by the respective protocols. This chapter is organized as follows. We begin w ith a brief description of the ex- iperimental environment in the next section. In Sections 5.2 and 5.3 we describe our 'experiments with Visa and ID PR protocols, respectively. 5.1 E x p e r im e n ta l P la tfo r m For the purposes of functionality and performance testing, both Visa and ID PR protocols were implemented w ithin the SunOS 4.1 environment which is substantially similar to the Berkeley 4.3 UNIX. Sun SparcStation 1+ workstations were used as the hardware platform throughout the experiments. (SparcStation 1+ scores 15.8 MIPs on the well- known Dhrystone benchmark). All experim ental workstations were equipped with 8 to 12 Mbytes of m ain memory. The workstations directly participating in the experiments were interconnected with Ethernet segments to form a topology depicted in Figure 5.1. However, a number of other workstations were used as secondary, non-essential nodes (i.e., end-systems in ID PR testing and visa-hosts in Visa protocol experim ents). In all experim ents, MD4 was used as the integrity mechanism for all packet traffic. D ata packet authentication in both Visa and ID PR protocols was performed using the ■secret prefix m ethod in conjunction with MD4 as described in Appendix A. 101 and off-campus nets. | IDPR /VISA T est S e tu p at USC / To campus network Big sur AD 333 Ent ty 2 Excaiifcur AD 111 Entity 2 AD 111 Entity 1 Santorin Entity Pfsmo AD 333 Entity 1 thin ether thick ether Figure 5.1: Laboratory Test Environment Signatures based on public-key encryption were not implemented. Also, we did not implement secure key distribution which is part of both connection setup in Visa and P E setup in ID PR. The main reason for this is the apparent lack of fast public key encryption im plem entation. Unfortunately, existing state-of-the-art public-key software im plem entations are excruciatingly slow. Even the fastest RSA hardw are can only attain a meager 2-4 K bits/second throughput [19]. Faster, scaled-down variants of RSA have been proposed [51]. For example, Privacy-Enhanced Electronic M ail specifies an RSA variant where signature verification costs significantly less th an signature com putation. This is achieved by using a large (e.g., 512-bit) secret exponent in conjunction with a very small (e.g., 8-bit) public exponent. Although signature verification becomes much cheaper (on the order of milliseconds), the cost of signature com putation remains quite (high (e.g., 4-5 seconds for a 512-bit modulus) [51, 36]. Future versions of Visa and ID PR [protocols will take advantage of such m ethods as they become available. 5.2 V isa E x p e rim en ts In its previous incarnation [27, 61], Visa protocol was implemented w ithin the network (layer which required modifications to IP. All visa-related inform ation was carried within IP option fields. This had several unpleasant side-effects: i) the visa option fields exceeded 40 bytes which is the maximum IP option length, and ii) IP options were not transparent ito IP routers (even those th at do not implement Visa protocol). The former lim its the 'length of visa-related data and control messages, while the latter contributes to increased processing delay at all (including non-visa) IP routers. In contrast to its predecessor, the current version is implemented as a self-contained protocol entailing no modifications to other protocol software. All visa control packets are processed inside the kernel. This speeds up connection setup (as compared to out-of-kernel im plem entations [61]). Recall th a t connection setup ■ is the most ’’overhead-intensive” phase of Visa protocol. It involves the exchange of at (least two inter-AD packets: VISA-REQUEST from A C S a to A C S b and VISA-GRANT from ACSb back to A C S a■ Moreover, at least four inter-AD packets are exchanged (one HOST-REQUEST, and three VISA-GRANTs). For the purpose of measuring the overhead we define connection setup tim e as the interval between the arrival of a RED IRECT packet from a visa-router to the arrival of a corresponding VISA-GRANT from the ACS (as shown in Figure 5.2). We measured the setup tim e for directly connected ADs as well as for ADs separated by one transit AD hop. For the directly connected case, the timings ranged between 100 and 180ms (averaging around 130ms). In the case of one transit AD hop, the timings ranged between 110 and 200ms (averaging around 150ms). These results show th at the overhead is still quite high. However, we expect th a t perform ance-tuning of the code should be able to cut these numbers down by about a third. Encapsulation of d ata packets is performed by all protocol participants. Normally, all outbound d ata packets are passed from the transport protocol to IP where each packet is prepended w ith an IP header and handed over to the interface output function. Visa encapsulation is interposed between IP and the interface driver. (See Figure 5.3). This is done transparently so th a t neither IP nor any higher-layer protocol is aware of the encapsulation. Encapsulating a packet requires the following steps: 103 REDIRECT from visa-router create new entry, HOST-REQUEST to ACS REFUSE from ACS or timeot ctr exceeded destroy entry P E N T > IN < 3 vtsa expiration or REDIRECT destroy entry timeout to ACS resend HOST-REQUEST increment timeout ctr. VISA-GRANT from ACS _ create and activate new entr^ VISA-GRANT from ACS activate entry a. visa-host HOST-REQUEST from visa-host create new entry, ACS-REQUEST to A timeout to neer ACS resend ACS-REQUfcST, increment timeout ctr. REFUSE from ACS or timeot ctr exceeded destroy entry, REFUSE to source host P E N D IN G ACS-REQUEST from peer ACS activate entry, VISA-GRANT to local visa-router, peer ACS and desL host VISA-GRANT from peer ACS tivate entry, VISA-GRANT to visa-router and source host b. ACS VISA-GRANT from local ACS create and activate new entry IDLE ACTIVE visa expiration or REVOKE from ACS aestroy entry c. visa-router Figure 5.2: Visa State Diagrams 1. V isa-table lookup using [SRC , D S T , P R O T , T o5*] fields extracted from the IP header. 2. Visa-stam p com putation. Packet switching at visa-routers involves the following operations: 1. Visa-table lookup w ith a visa identifier attached to each packet 2. Visa-stam p verification (i.e., integrity/authentication check) 3. Light bookkeeping, i.e., recording tim e of packet arrival, updating resource usage m eters, etc. ■'Unfortunately, this has to be done for all packets, even those that m ay not require a visa. 4 4 5 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 4 4 4 4 4 4 4 4 4 4 { 4 4 | Transport layer protocols^ Internet Protocol (IP) Interface Drive] network a. encapsulation of data packets in a source visa-host i Internet Protocol (IP) Interface Drivei Interface Drivei network b. packet switching in a visa-router Figure 5.3: Visa encapsulation and packet switching We measured the overhead incurred by d ata packets flowing across previously established visa connections. The overhead measurements are derived using the ICM P Echo protocol [74]. In this protocol, a packet travels from the source to the destination end-system where it is immediately reflected back to the source. The results in Table 5.1 represent the the round-trip times (in milliseconds) for packets traveling between directly connected ADs. In other words, each packet travels across three ethernet segments: i) H a to G W a, ii) G W a to GWb, and, iii) GWb to fib where H a refers to pism o, G W a to bigsur, GWb to kos, and, Hb to excalibur as depicted in Figure 5.1. The first row shows the timings w ith Visa protocol inactive. The second row shows the timings for the same packet traffic, but, using Visa protocol w ithout any integrity , checking. These timings help us in identifying purely protocol-related overhead. The third row shows the results for Visa protocol w ith full integrity checking. Packet size (bytes) 16 64 256 512 1024 No Visa 5 5 8 10 15 Visa w /o integrity 6 6 8.5 11 16 Visa with integrity 7.5 8 11 14 20 Table 5.1: Visa connection setup overhead (in ms) First and foremost, these numbers clearly illustrate the relatively low cost of encap sulation and switching of visa packets. Another comforting aspect of our results is what appears to be insignificant additional overhead imposed by packet authentication and in tegrity checking. This may be due to the nature of MD4; since it is implemented entirely in software, d ata rates are constant independent of the packet size. (Hardware devices tend to offer much lower rates for small d ata units; mostly because of the fixed device initialization costs). 5.3 I D P R E x p e rim en ts In this section we describe the experiments with the ID PR architecture based on the initial prototype im plem entation. The ID PR architecture was originally put forward by the Internet Inter-Dom ain Policy Routing Working Group (ID PR-W G )2 of the Internet Engineering Task Force [50, 84] The software development is a collaborative project be tween the University of Southern California (USC), Bolt Beranek and Newman (BBN), and Sparta, Inc. Before proceeding with the discussion of experim ental results, the following subsection provides additional background for the ID PR architecture. 5 .3 .1 A d d itio n a l B a ck g ro u n d In C hapter 4, we addressed the high-level design issues pertaining directly to policy en forcement in ID PR , i.e., installation of Policy Routes and subsequent packet forwarding. However, ID PR architecture includes much more th an just policy enforcement mecha nism s. Five protocols form the core of the ID PR architecture: 1 • V irtual Gateway Protocol (VGP) A Virtual Gateway (VG) is a set of PGs interconnecting a pair of adjacent ADs. A 2O f which the author is a member. 106 _ simple VG consists of two PG s, one in each of the neighboring ADs. All PGs within j an AD use VGP to exchange status information with respect to their outside links, ! 1 i.e., the status of their constituent VGs. • U pdate Protocol (UPDATE) [ ! Each AD uses UPDATE to distribute both configured and dynamic status informa tion about its VGs and the associated Policy Terms. The inform ation is dissemi nated in a link state fashion, i.e., it is flooded throughout the internet. • Route Synthesis (RSYNTH) Each AD has one or more Route Servers (each a distinct logical entity often co located w ith a PG ) th a t is responsible for m aintaining the connectivity database of the entire internet and computing PRs for its constituent users. Strictly speaking, RSYNTH is not a protocol, but, rather, a route com putation algorithm superim posed w ith a set of AD-dependent heuristics used in selecting optim al PRs. It embodies w hat we referred to in C hapter 1 as route selection policies. • P ath Setup (SETU P) As described earlier, SETUP is responsible for the installation and maintenance of PR-related state in PGs. • Kernel Packet Switching (KERNEL) Switching of ID PR d ata packets at a PG involves m apping individual d ata packet into PR s and forwarding them according to the next PG hop established at route setup time. Because of the high throughput requirements, d ata packet switching is implemented within the kernel. In addition, there is a high degree of inter-dependence among the various ID PR protocols. The particulars of this interplay are illustrated in Figure 5.4. ID PR architecture also provides a uniform mechanism for the reliable (i.e., timely, sequenced and error-free) delivery of ID PR control packets between PG s and between the different protocols within a PG. This function is implemented by the Control Message Transport Protocol (CM TP). VGP, UPDATE and RSYNTH are not addressed below; for a complete description of ID PR architecture and protocol specifications the reader is referred to [50, 84, 7, 28]. _ 1 0 7 _ Kernel | Boundary ID PR P a c k e t S w i t c h i n g (KER N EL) _ network Figure 5.4: Interplay of ID PR protocols 5.3.1.1 P o lic y R o u te s The foremost purpose of ID PR is the m aintenance of PRs. Therefore, in order to under stand the inner workings of ID PR , it is crucial to understand the P R life-cycle. W ith respect to a given PR, there are three types of PGs: i) ORIGINATOR, ii) TARGET, and iii) TRANSIT. ORIGINATOR is the exit PG in the source AD th a t initiates the installation of the P R (i.e., originates the SETUP packet). TARGET is the entry PG in the destination AD (i.e., the last PG hop in the PR ). All other PG s involved are TRANSIT; for every TRANSIT PG both PG -N EX T and PG -PR EV are defined. A P R can be in any one of the seven states: 1. P R -E M B R Y O N IC (ORIGINATOR) SETUP-REQUEST from KERNEL is received and ROUTE-REQUEST is subse quently generated to RSYNTH. 2. P R -IN IT IA L (ORIGINATOR and TRANSITs) ROUTE-RESPONSE is received from RSYNTH and SETUP is forwarded to the next hop PG (PG-N EX T). * 3. P R -W A IT IN G (ORIGINATOR and TRANSITs) SETUP is ACK-ed by PG -N EX T, but A C CEPT has not yet been received. 4. P R -A C T IV E (TRANSITS and TARGET) A C CEPT is received and forwarded to PG-PREV; P R is now functional. 5. P R -C O M P L E T E (all PG s) A C CEPT is ACK-ed by PG -PREV (except for ORIGINATOR). 6. P R -D Y IN G (all PGs) • TEARDOW N is generated or received from some PG in the path. • REFUSE is generated or received from some PG (via PG -N EX T) in the path. • CM TP TIM EOUT on A C CEPT to PG-PREV. • TIM EOUT (not CM TP) on receiving A CCEPT from upstream . • ERROR on processing SETUP. 7. P R -F R E E (all PGs) P R entry is freed. 5.3 .1 .2 P ro to c o l D e sc rip tio n : O R IG IN A T O R P G A P R is first conceived at the ORIGINATOR PG when the ID PR encapsulation module receives a packet and fails to locate a corresponding HOST-TABLE entry for it. It then composes a SETUP-REQUEST packet which consists of a short pream ble followed by the IP packet itself. Once SETUP receives this request it first checks to see whether there is an existing PR which can be used for the new host-pair. If such a P R exists, SETUP fills in the pi field in the SETUP-REQUEST and installs a new HOST TABLE entry via a system call (IDPR-TABLE: Put-host-entry). If no existing P R can be used, the ORIGINATOR generates a ROUTE-REQUEST to Route Synthesis, RSYNTH. It is assumed (for the tim e being) th a t RSYNTH is always co-located w ith the SETUP component, i.e., it is present at each PG. Therefore, there is (as of yet) no tim eout on ROUTE-REQUESTs. The reply from RSYNTH comes in the form of a ROUTE-RESPONSE packet, whose form at is identical to th a t of ROUTE- REQUEST. ROUTE-RESPONSE is physically trailed by the PR itself. It is composed of two or more segments where each segment corresponds to exactly one AD hop. i A special case of ROUTE-RESPONSE is ROUTE-RESPONSE-NONE which carries a value of zero in the hops field.3 In this case, an ICM P HOST-UNREACHABLE packet ) is generated to the source host. If RSYNTH computes a valid route, the ORIGINATOR proceeds to compose a SETUP packet. The form at of a SETUP packet is very similar to th a t of ROUTE- RESPONSE. It also consists of a pre-amble followed by the sequence of route segments. The sequence of segments is copied directly from ROUTE-RESPONSE. After a SETUP has been forwarded, the ORIGINATOR expects to receive an AC C EPT from the TARGET PG , or a REFUSE from any of the intervening PGs. If neither event takes place, ORIGINATOR prom ptly times out and attem pts to set up the route again, however, not before selecting a new path id. This is done to prevent any confusion w ith regard to stale state in TRANSIT PGs. If the ORIGINATOR times out n (defined locally) tim es, it gives up and sends an ICM P HOST-UNREACHABLE packet to the source host. If a REFUSE is received, the ORIGINATOR logs it and, once again, sends an ICMP HOST-UNREACHABLE packet to the source. This is clearly less than optim al; in the future, perhaps SETUP (depending on the reason for REFUSE) should ask RSYNTH for another route. The arrival of an A C CEPT signals th at the P R is fully operational. At this tim e the ORIGINATOR installs a new P R entry in the kernel PR-TABLE and also installs the corresponding HOST-TABLE entry for the host-pair th a t caused the setup originally. Figure 5.5 illustrates the ORIGINATOR PG state diagram as discussed above. 5 .3 .1 .3 P ro to co l D escrip tion : T R A N S IT and T A R G E T P G s From the point of view of a TRANSIT PG , a P R is born when a valid SETUP packet is received from a recognized PG neighbor. A SETUP packet is considered valid only when the following conditions are satisfied:4 1. The route m ust contain a segment corresponding to the local AD. 2. The local AD m ust appear only once in the route (i.e., no AD loops). 3A ctually, a route of length one is also treated as a negative response from R SY N TH . 4T im eliness, integrity and authenticity are verified by CM TP. no. : PR_FREE Delete PR l> K J.M B I{\C )N 1 C Delete PR Timeout or REFUSE from PQJEJEXT. Delete PR g 4 * - TIMEOUT on ACCEPT l’R _('O M PI i-11-: ACCEPT from target PG (via PG_NEX l'j Install PR in kernel 5 Figure 5.5: ORIGINATOR state diagram 3. The PRid m ust not be currently in use. 4. There m ust be enough space in the PR-TABLE for a new entry. 5. The previous VG must be such th at there is at least one PG neighbor th at belongs to it. 6. The source address in the IP header of the SETUP packet m ust m atch one PG neighbor th a t is a member of a previous VG. 7. The next VG m ust be such th at either: i) this PG is a m ember of it, or ii) there is a PG neighbor which is a member. In the former case, there m ust be a PG neighbor which is also a member of the said VG. 8. PT s referenced in the local AD segment m ust agree w ith the characteristics of the route. 9. O ther P R usage conditions must be acceptable. This includes: UCI(s), ToS, au thentication type and expiration conditions. Only TRANSIT PG s th at are used for entering an AD need to be concerned with this check. If a SETUP packet fails to meet any of the above conditions, a REFUSE w ith the appro priate reason code is generated to the PG -PREV . After the REFUSE is ack-ed (or times out), the P R entry is freed. ' If the SETUP packet is valid, a new P R entry is created. If the last hop is reached (i.e., this PG is TARGET), A C CEPT is sent back to the ORIGINATOR and the PR is considered operational. Otherwise, the SETUP is forwarded to the PG -N EX T. If PG- NEXT fails to acknowledge the SETUP packet (tim eout), TEARDOW N is sent back to the ORIGINATOR and the PR is destroyed. After PG -N EX T acks the SETUP packet, the PR is put into a dormant state until the A C C EPT passes by on its way to the ORIGINATOR. The A C CEPT m ust satisfy the following conditions: • It arrives via PG-NEXT. • It is sourced by the TARGET PG. If the A C CEPT fails to meet these conditions, it is discarded and not acknowledged. However, the P R is not destroyed. This is because a valid A C CEPT may still come through (if it does not, the P R is tim ed out; see below). A valid A C C EPT is forwarded to PG -PR EV and, once ack-ed, the PR is installed in the kernel PR-TABLE and considered fully operational. Failure to ack an A CCEPT is grounds for TEARDOW N (see below). State diagrams for TRANSIT and TARGET PGs are illustrated in Figures 5.6 and 5.7, respectively. 5 .3 .1 .4 P R T eardow n A P R can be term inated for several reasons: 1. Lifetime exceeded 2. Packet lim it reached 3. D ata lim it reached 4. M aximum idle tim e exceeded 5. Previous-hop PG fails to ACK an A C C EPT packet 112 _ I I n sta ll P R in k ern el Figure 5.6: TRANSIT state diagram 6. VGP reports th at either previous- or next-hop PG is down In the initial im plem entation, the first four types of teardown are initiated by KERNEL via a TEARDOW N-REQUEST packet th a t is delivered to SETU P (encapsulated with a dummy CM TP and IP header). Upon receiving TEARDOW N-REQUEST, SETUP sends a TEARDOW N packet to both PG-NEXT and PG -PR EV (if defined). TEARDOW N- REQUEST and TEARDOW N have the same simple form at consisting of the PRid and the term ination code. A TEARDOW N packet can arrive via PG -PREV or PG -N EX T. If it arrives via PG- ; NEXT, it must be forwarded to PG -PR EV and vice-a-versa. A TEARDOW N must also be sourced at one of the intervening PG s, however, this is difficult to verify since PGs w ithin a PR do not all necessarily have a means for m utual authentication. ..113 i PR_COMPLETfi Timeout (no ACK from PO_PREV) Figure 5.7: TARGET state diagram 5 .3 .2 E x p e r im e n ts Experim ents w ith the ID PR im plem entation were conducted in order to evaluate the over head incurred by P R setup and ID PR data packet processing. This section summarizes our results. We define PR setup overhead as the tim e interval between the arrival of a SETUP- REQUEST packet at the ORIGINATOR PG and the arrival of a corresponding A CCEPT packet at the same PG . Equivalently, it can be viewed as the transition tim e between the PR -FR E E and PR-CO M PLETE states as depicted in Figure 5.5. We m easured the PR setup overhead for routes ranging from 2 to 5 PG hops.5 (The laboratory topology was re-configured for the case of 5-hops). We m easured the overhead in relation to the number of PG , not AD, hops. This is because traversing an AD m ay involve physically traversing one or more PGs. Therefore, it is more meaningful to m easure per-PG , rather than per-AD setup overhead. The results are illustrated in Table 5.2. They include MD4-based integrity check com putation (for both SETUP and A C CEPT packets) at every PG hop. The first row 5See Figure 5.1. # of PG hops 2 3 4 5 Per-hop overhead 50 57 54 58 Route com putation 20 20 30 30 Setup overhead 50 170 215 290 Total overhead 70 190 245 320 Table 5.2: PR setup overhead (in ms) shows the average per PG setup overhead which is based on the to tal overhead in row 4. Because route com putation is a relatively expensive operation incurred only at the first ihop, we decouple the overhead due to route com putation from the purely setup-related overhead (as shown in row 3 and 4). These results show th a t the per PG setup cost averages about 55ms. This number is quite low considering th a t it includes the following sequence of events at every transit PG: 1. Context switch from Kernel to User mode to receive SETUP 2. MD4 digest com putation 3. Validity checking (including: timeliness, previous and next hop reachability and PT validation) 4. Context switch from User to Kernel mode to forward SETUP 5. Context switch from Kernel to User mode to receive A C C E PT6 6. MD4 digest com putation 7. PR table lookup to locate the P R in question 8. Context switch from User to Kernel mode to forward A C C EPT Although the results appear reassuring, a real-world, deployable im plem entation would ■include encryption-based signatures which will greatly increase the P R setup overhead. Also, since the number of ADs in our concocted internetwork is small and the topology is simple, overhead due to route com putation and P T validation is kept artificially low. On the other hand, this im plem entation was not tuned for performance. 6T his does n ot occur im m ediately after the previous step. Internet Protocol OP) j Interface Priver| network a. encapsulation of data packets 1DPK lVickei l-orv. arthnj; Internet Protocol Interface Driver Interface Drivei network b. transit packet switching Table 5.3: ID PR encapsulation and transit packet switching We also measured the overhead incurred by ID PR d ata packets in traversing previ ously established PRs. (Figure 5.3 depicts the placement of the encapsulation and packet switching functions). As before, we used the ICM P Echo protocol. The results in Table 5.4 represent the the round-trip times (in milliseconds) for traversing paths of variable length. For each p ath length we began by tim ing d ata packets w ithout ID PR (subcolumn A). These numbers provide a basis for comparison. We then tim ed the same packet flows across ID PR-controlled paths (subcolumn B). This was done to isolate as much as pos sible the overhead due to additional packet length and ID PR-related processing in PGs. Finally, we plugged in MD4-based integrity checking to obtain the timings of full-blown ID PR packet switching (subcolumn C). Unlike P R setup overhead, the numbers for d ata packet overhead are quite realistic since all protocol features have been implemented. The only exception is the P R table lookup. Recall th at a PG uses the PRid field present in each d ata packet to locate an 116 # of PG hops 1 3 4 5 a b c a b c a b c a b c 1 6 4 4 4.5 5 6 7 8 7.S 9 lO lO 12 6 4 4 5 5.5 5 7 8 8 9 lO lO 12 16 2 5 6 6 7 8 8 9 10.5 1 3 12.5 16 14 17 18 5 1 2 8 9 10.5 10 1 1 13.5 1 7 1 7 22 1 9 20 26 1 0 2 4 12 14 1 5 1 5 1 7 20 23 23.5 30 28 33 35 < t > o > .a J2 P -. a. without IDPR. b. IDPR (no integrity checking) c. IDPR with MD4 integrity checking Table 5.4: Packet round-trip delay (in ms) appropriate PR table entry. Because the volume of traffic on our expirem ental ”internet- work” was kept artificially low, PR table lookups were relatively fast. On the other hand, our table lookups were performed sequentially. W hereas, a more perform ance-tuned im plem entation able to support large volumes of inter-AD traffic would necessarily use some kind of a fast hashing technique for table lookups. Judging by the above results, the overhead introduced by ID PR encapsulation and transit packet switching, while not negligible, appears to be sufficiently low to be of little hindrance to existing transport layer protocols. Even for large packets (e.g., 1Kbyte) ID PR packet switching delay am ounts to less than 1ms per PG hop. This is especially encouraging considering th at the MD4 digest com putation (performed at each hop) alone takes approxim ately 0.7ms. C h a p ter 6 C o n clu sio n s and F u tu re W ork i I This final chapter summarizes the contributions of this thesis and concludes w ith a dis cussion of outstanding issues and future work. 6.1 C o n trib u tio n s o f T h is T h e sis This thesis represents the first in-depth treatm ent of access control and policy enforcement in internetworks. Its main result is the design of an architecture geared towards enforcing a broad range of policies. The contributions of this research can be divided into three m ajor parts: • A framework for access control in internetworks • Design of stub AD policy enforcement • Design of transit AD policy enforcement In addition, design choices are reinforced by experim ental results obtained from functional im plem entations of the proposed mechanisms. 6 .1 .1 F ra m ew o rk In C hapter 1, we introduced the problem of policy enforcement in the internetwork envi ronm ent. It was shown th at different types of controls are necessary for controlling access to three m ain objects of policy (resource types): i) end-systems, ii) network resources, and iii) internetwork routes. Owing to the nature of service provided and the types of po tential threats, we m ade a further distinction between the protection of stub and transit AD network resources. For each object of policy we considered a number of design param eters: 118 • Security services required • Enforcement location • Enforcement protocol • Principal granularity • Enforcement granularity and mode I In making design choices we applied the well-known end-to-end argum ent which essen tially states th a t the placement of controls (policy, in this context) should be at the highest protocol layer at the end-points of communication. W hen the resource in ques tion is an end-system th a t engages in inter-AD communication, the end-to-end argument j suggests th a t this end-system should be able to protect itself. By the same token, other network resources, including unequipped or strictly-internal end-systems, m ust be pro tected at AD boundaries by border routers. Similarly, access to inter-AD routes must also be controlled before any traffic is allowed to cross the AD boundary. Therefore, to the extent th a t network resources require protection, the highest relevant endpoint is the border router and the associated packet-forwarding and routing protocols. In this sense, the end-to-end argum ent supports implementing controls at the network layer. 6.1.2 Stub A D P olicy E nforcem ent Chapter 3 addressed the design of policy enforcement for stub AD communication using the guidelines outlined in our framework. The goal of stub AD policy enforcement is to perm it only authorized, authenticated and timely communication to take place across stub AD boundaries. Earlier, in C hapter 2 we discussed, several existing approaches for controlling internetwork communication and concluded th a t they provide solutions th at are either too restrictive, insecure, or not general enough. Visa protocol presented in C hapter 3 is a simple, yet powerful mechanism for control ling packet traffic at stub AD network boundaries. The prim ary goal of Visa protocol is the protection of stub AD network and end-system resources from unauthorized ac cess. This goal is achieved by requiring th a t all communication be first authorized by the ACSs in end-point ADs. A uthorization to communicate is then embodied in a visa which is issued to the requesting end-system and distributed to the intervening visa-routers. Subsequent packets carry unforgeable visa-stamps which are verified by the visa-routers. Visas are term inated when the underlying communication exceeds a pre-determined re source limit. 119 ■ One of the m ain advantages of Visa is th a t visa-routers do not bear the brunt of j the responsibility for making access control decisions. By issuing a visa, an ACS has i pre-com puted an authorization decision. The task of a visa-router is thus reduced to j ensuring th a t a visa is valid and is being used appropriately; the expensive p art of policy : enforcement is done once per connection, by the ACSs of the end-point ADs, rather than 1 once per packet, by the border routers. In addition, Visa does not im pact intra-A D traffic and has no bearing upon end-systems th a t do not partake in inter-AD communication. As p art of the design process, we evaluated the security of the proposed Visa protocol i using the m otivation and some terminology (but not the m ethods) from the well-known j BAN logic [9]. The protocol was shown to be resistant to hostile attacks (assuming a ■ strong underlying cryptosystem .) The security analysis also dem onstrated the lim itations to the beliefs and assurances attained by protocol participants. For the purpose of quantifying the costs of stub AD policy enforcement, we conducted experiments w ith a prototype Visa protocol im plem entation. As illustrated by the ex perim ental results in Chapter 5, the cost of the initial setup phase is still somewhat high. I However, d ata packet overhead was dem onstrated to be quite insignificant for the case of non-cryptographic packet signatures. 6.1.3 Transit A D P olicy E nforcem ent Relative to stub AD access control, access control with respect to transit network re sources is a new phenomenon. It has been brought about by (among other factors) the increasing commercialization of transit internetwork facilities. The framework discussion in C hapter 1 suggested th a t controlling the usage of (i.e., access to) transit network resources (such as routers and links) requires a new generation of routing and packet-forwarding protocols because of the need to coordinate transit policies among all intervening ADs. This rules out unilateral policy enforcement at packet- . forwarding tim e. Instead, internetw ork routing decisions m ust be m ade according to policy-related param eters such as access rights and cost, in addition to the traditional ' param eters of connectivity and delay. C hapter 4 addressed the design of protocols for se c u re control of transit internet- I work traffic using Inter Domain Policy Routing (IDPR) as the design foundation. We concentrated on PR setup and packet-forwarding protocols. We began by identifying potential security threats facing ID PR and discussed a num ber of defense mechanisms. Special attention was paid to the costs of im plementing security services. In particular, we considered (and evaluated) a range of d ata integrity 120 i scenarios varying in both strength and cost. The flexibility to select a desired tradeoff between security and performance is built into the architecture. After specifying PR setup and packet-forwarding protocols we conducted a thorough analysis of their security. As in Visa protocol, this analysis identified the exact beliefs attained by the protocol participants, i.e., PGs. At the same tim e, it revealed th at certain goals are ultim ately unattainable, e.g., reliable verification of the exact path a packet traverses. Experim ental results obtained from actual protocol im plem entations appear very re assuring. The cost of PR setup was shown to be tolerable, at around 55m s per PG hop. The overhead cost of d ata packet switching in ID PR is of greater concern than the cost of PR setup. However, our measurements indicated th a t even for large packet sizes (e.g., 1Kbyte) packet-switching overhead per PG hop amounted to less than 0.5ms. 6.1.4 Security .vs. C ost Security and performance are always at odds. This is neither surprising nor easily reme died. Throughout this thesis, we attem pted to reduce as much as possible the adverse effects of our protocols (namely, added costs) w ithout sacrificing security. Certain types of overhead are difficult, if not impossible, to avoid. For example, reducing the number of packets exchanged during connection setup in Visa protocol or P R setup in ID PR is not feasible without sacrificing security. On the other hand, using light-weight d ata authentication methods can greatly influence packet-switching overhead in visa-routers and PGs. An im portant contribution of this thesis is the development of encryption-free methods for verifying d ata authenticity. In Appendix A, we describe two m ethods for computing MD4 message digests based on a secret quantity. We believe the strength of these methods to be at the very least equal to the strength of the underlying one-way hash function. 6.2 F u tu re W ork This thesis represents a first attem pt at consolidating policy enforcement mechanisms. There rem ain numerous opportunities for future research; a few of them are discussed below. 6 .2 .1 M u ltic a stin g M ulticasting is a useful and convenient technique for communication w ithin node groups [86]. M ulticasting support for the internetwork environment have been proposed in [18]. Two types of m ulticast predominate: 1. M ulticasting within small, static and short-term groups, e.g., for the purpose of tele- or video-conferencing. This type of communication typically has high bandw idth requirements. 2. M ulticasting within large, dynamic and long-term groups, e.g., name or tim e servers. Typically, communication is infrequent and not bandwidth-intensive, e.g., global tim e server updates can take place once every hour. Visa protocol, as specified, provides no special support for either type of multicasting. Consequently, n separate visas would be required for a m ulticast group member to com m unicate with n peers assuming type 1 m ulticast. Things get much worse when n is not known in advance ( type 2 m ulticast) and the exact locations of the peers are not known. We believe this to be a problem not unique to Visa protocol but inherent to any strong network access control mechanism. ID PR is also not equipped w ith m ulticast support. In order to achieve type 1 mul ticast using the protocols specified in Chapter 4, every group member m ust set up n distinct PRs, one to each peer. Moreover, subsequent traffic would have to be replicated individually for every such PR. Ideally, we would like to avoid unnecessary replication and excessive state in PGs. This can be made possible if ID PR is augm ented to allow setup of m ulti-destination P R "trees” in addition to regular, single-destination PRs. Fur therm ore, subsequent data traffic m ust be multiplexed along every tree branch in transit PGs. Supporting type 2 m ulticasting is more complicated because of large group sizes and volatile group membership. One possible solution is to treat such m ulticast traffic as being ’’exem pt” from certain controls. For example, we could restrict uncontrolled m ulticast to well-known groups such as tim e or name servers. The main drawback is th a t an intruder can use this back-door as an opportunity for abuse by flooding an AD w ith fraudulent traffic. Alternatively, m ulticasting can be restricted to destinations (peers) th a t have existing PRs. Full support of m ulticasting in the presence of policy enforcement m ay prove to be impossible, however, it remains subject to future work to determine exactly to what extent m ulticasting can coexist with policy enforcement. 122 6 .2 .2 F au lt T oleran ce Fault tolerance in Visa and ID PR has not been extensively considered in this thesis. This !does not imply th at the subject is unim portant, quite the contrary. In this section, we consider the issues of state recovery and connection repair. 6.2.2.1 State Recovery State recovery is the problem of reestablishing lost state whenever a visa-router or a PG crashes and reappears shortly thereafter. When a visa-router crashes, its visa-table is lost. Visa protocol description incorpo rates a means for an ACS to reestablish a visa-table in a ”re-incarnated” visa-router. I However, the im portant drawback of this m ethod is th at ACSs, unlike visa-routers, do not keep up-to-date visa-tables, i.e., a visa-table entry in an ACS does not reflect any re source usage since a corresponding visa was originally issued. This is because, all records of resource usage are irrecoverably lost when a visa-router crashes. Therefore, simply refreshing a visa-router may not be an optim al decision. ID PR does not currently specify any mechanism for the recovery from PG crashes. 'Below, we outline one possible solution. If a PG crashes, it loses its entire P R table. However, we assume th a t all PGs have reliable (perhaps, stored in stable storage) knowledge of their neighbor PGs. When a 'PG recovers from a crash it first announces itself to the neighbors. Each neighbor then (proceeds to search its PR table for all entries th at specify the said PG as either previous or next PG hop. Having collected all such entries, each neighbor composes a special REFRESH packet which it forwards to the PG in question. Upon receiving REFRESH packets from all of its neighbors, a PG should be able to reconstruct its PR table with high accuracy, including even such details as packet and d ata meters. This approach works best for recovering PRs for which the crashed PG is TRANSIT. This is because both previous and next hop PGs are defined for TRANSITS. Therefore, in order to fully recover a lost PR , a PG must receive two REFRESH packets (from two of its neighbors) such th at each containing a m atching record for the said PR. By combining the inform ation in the records, a PG can recreate an entry in its P R table. Resource usage meters can be recovered by taking the smaller set of values from the two REFRESH packets. It is slightly more problem atic to recover PRs th at specify the failed PG as either ORIGINATOR or TARGET. Since there is but a single source of inform ation, only one 123 REFRESH can be expected. Hence, there is no longer the assurance from two independent sources. Moreover, in both cases, a REFRESH always comes from a neighbor in a different (though directly-connected) AD. This raises the issue of trust, i.e., w hat kind of assurances are necessary for a PG to reestablish its P R table reliably? Perhaps every PG should store copies of signed SETUP packets for each active PR just in case a neighbor crashes and subsequently demands strong evidence of PR s’ existence. 6.2.2.2 Connection and Route Repair An issue related to state recovery is connection and route repair. W hen a visa-router or a PG crashes and then fails to recover, previously authorized traffic will be unable to propagate as expected. In Visa, unless an alternate visa-router is available, connection repair will not succeed. To allow for on-the-fly adaptation to crashes, all potential ’ ’backup” visa-routers must replicate the necessary state. In ID PR , when a PG crashes, it may still be possible to utilize the original PR. This is because a P R specifies ADs, not physical PG s. Hence, if there is an alternate PG, parallel to the one th a t failed (i.e., a PG in the same AD and the same AD), route repair may succeed, especially if P R state is replicated in parallel PGs at setup time. Barring replication, the previous hop PG may attem pt to repair the P R by setting up appropriate state in the alternate PG ; however, it m ust be able to produce a copy of the original SETUP packet. If a PG crashes and no parallel PG s are available, the issue of route repair becomes more complicated. Suffice it to say th a t, because of policy considerations, a transit PG can not attem pt route repair unilaterally. In other words, a PR can not be modified w ithout prior authorization from its original source. One solution is to tear-down the P R and let the source recompute an alternate route. This approach is simple and requires no special protocol support. However, it involves a significant am ount of overhead. Alternatively, the source can pre-compute a number of different PRs for the same destination and bundle them together in a single SETUP packet. All of the enclosed PRs can then be set up simultaneously. W hen a a transit PG becomes unavailable, the previous hop PG can switch to a ’’sibling” PR transparently. This technique is known as Adaptive M ulti-Path Source Routing and is subject of current and future research [8]. 124 J6.2.3 A cco u n tin g and B illin g Internetw ork communication has been, until now, treated mostly as a free (or fixed-cost) good [13]. This is likely to change with the advent of internetwork policy enforcement jand commercially-owned and operated transit facilities. If communication is to he charged for on a usage-sensitive basis, accounting must take place in transit ADs. Considerations for usage accounting are extensively discussed in [33, 16]. ID PR , by virtue of m aintaining state in policy gateways, can easily support accounting on the basis of packets, or P R duration1. Cost recovery is an entirely different m atter. As Clark points out in [13], it is a very complicated problem with many unresolved issues. One of the more difficult ones 'is the problem of reliable billing. Looking to the real-world for an analogy, credit card billing statem ents often include itemized charges th at help the consumer in identifying and verifying individual charges. Furthermore, most credit card companies are willing to provide copies of signed receipts to customers who have trouble remembering certain purchases. In other words, a customer can choose to m aintain a sort of a ’’stateless” model with respect to the purchases m ade and still be assured of the validity of individual items billed at the end of the m onth. Ideally, a transit AD billing for service would provide an equivalent of a signed state ment to its stub AD subscribers. W hether or not this billing integrity can be accomplished remains to be seen. 6.2.4 Integration In C hapter 1, we argued for dividing the discussion of security according to the type of resource being protected. However, from a technical and policy perspective, it is essential for these two types of policy enforcement to be coordinated and consistent.2 To this end, we discuss an integrated view of policy enforcement support. We focus on two opportunities for integration - border routers and specialized servers. 6.2.4.1 Border Routers The heaviest burden of policy enforcement falls on the border routers. This is particularly true of border routers in stub ADs which need to implement controls at the granularity of both ADs and end-systems, i.e., Visa and IDPR. ■ ‘A ctually, ID P R already supports packet, data and tim e counters on a per PR basis. 2T his is similar to the integrated layer processing argument presented in [14]. 125 For locally originated traffic, the border router needs to control: i) source end-system access to the outside, ii) destination AD and end-system, and iii) inter-AD route access. Traffic coming in from the outside has to be controlled on the same basis, w ith the exception of route selection (if routes are composed at the source). However, it is possible .for a border router in a destination AD to refuse incoming traffic based on the route it followed. No attem pt has been made in this thesis to integrate and streamline the two types of enforcement mechanisms. This does not imply th at integration is not possible or desirable. On the contrary, significant performance benefits can be gained through integration. Visa and ID PR can benefit substantially from sharing many types of inform ation. For example, a visa-router m aintains a visa-table where every entry refers to a connection between two end-systems. Similarly, a PG in a stub AD m aintains a host-table where every entry points to a PR. If a router implements both Visa and ID PR, it is more than likely th at the same information is duplicated in the two tables. Merging these two tables into one can save a lot of storage space. Moreover, processing overhead can be reduced if only a single table lookup is performed for both protocols. 6.2.4.2 Specialized Servers Network adm inistrators need to create consistent policies across all three types of controls addressed. This may involve more than one server function. In a stub AD, network adm inistrators will define which end-systems will be reachable from the outside. These policies are then enforced by the particular Access Control Server (ACS) used. The ACS controls the inclusion of particular principals and objects (e.g., end-system addresses) in router access control lists. For those end-systems th at are made accessible, network adm inistrators will want to m onitor the end-system controls employed to make sure th at unreachable end-systems are not vulnerable to external access. These same network administrators will create policies to be used in selecting routes. The same inter-AD relationships and trust levels th a t determine the end-system and network resource access policies will determine route selection criteria. Once routes are selected for possible use by the AD, route servers are responsible for handing out routes to end-systems (or border routers) within the AD. Therefore, network adm inistrators must also specify access control lists to control distribution of the route servers’ routes. A route server, therefore, is involved in all three types of policy - network resource control policies are considered in route com putation, followed by route selection policies, and finally by end-system policies th at control distribution of routes. Finally, for hybrid ADs 126 jthat support some transit traffic as well as end-system access, transit routing policies, advertised via the inter-AD routing protocol, must be coordinated with stub-AD network resource controls. In the case of transit ADs, there is less of a concern w ith coordinating several types of policy. However, network adm inistrators will need tools to assist them in composing juseful transit policies. Such policies must on the one hand realize the AD’s control requirem ents, and on the other hand, be as compatible as possible w ith the policies of all other ADs. If no attention is paid to compatibility, then the transit service may be of i little use to anyone in the internetwork. 6.2.5 O ther P olicy R ou tin g A pproaches I jThe ID PR architecture described in this thesis is not the only possible paradigm for 'Policy Routing. O ther existing proposals reviewed in C hapter 2 are no m atch for IDPR insofar as the range of policies supported. Nevertheless, it is conceivable th at other, radically different approaches may be more suitable to Policy Routing. (Alternative 'Policy Routing approaches are discussed in [7].) For example, it has been suggested that 'IDRP (not ID PR) be augmented to include full AD-level paths coupled with associated (policies along the distance vector tables it already exchanges3. It is unclear at the time bf this writing whether the resultant architecture can contend w ith IDPR. 3D. Estrin, private com m unication, March 1990. 127 R efere n c e L ist [1] Advanced Micro Devices, Inc., AM D M O S Microprocessors and Peripherals Data Book, A d v a n ce d M icro D ev ices, In c ., Sunnyvale, CA. 1987 [2] ANSI, Intermediate System to Intermediate System Inter-Domain Routeing Infor mation Exchange Protocol, A N S I D o c u m e n t X 3 S 3 .3 /9 0 -1 3 2 , June 1990. [3] E. Biham, A. Shamir, Differential Cryptanalysis of DES-like Cryptosystems, P r o ceed in g s o f C R Y P T O ’90, August 1990. [4] M. Bishop, A Security Analysis o f Version 2 o f the Network Time Protocol (N TP), D a r tm o u th C ollege T ech n ical R e p o r t P C S -T R 9 1 -1 5 4 , January 1991. [5] Blacker Front End Interface Control Document D D N P ro to c o l H a n d b o o k , V ol. 1, DDN Network Information Center, SRI International, 1985. [6] A. Birrell, B. Lampson, R. Needham, M. Schroeder, A Global Authentication Service Without Global Trust, P ro c e e d in g s o f 1986 IE E E S y m p o siu m o n S e c u rity a n d P riv a c y , May 1986. [7] L. Breslau and D. Estrin, Design o f Inter-Administrative Domain Routing Protocols, P ro c e e d in g s o f 1990 A C M S ig co m m C o n fe re n ce , September 1990. [8] L. Breslau, D. Estrin, and L. Zhang, Adaptive M ulti-Path Source Routing, D R A F T , in su b m issio n to 1991 A C M S ig co m m C o n fe re n ce , April 1991. [9] M. Burrows, M. Abadi, and R. Needham, A Logic of Authentication, P ro c e e d in g s o f A C M S y m p o siu m o n O p e ra tin g S y ste m P rin c ip le s, December 1989. [10] C C ITT , The Directory, Part 1: Overview o f Concepts, Models, and Services, C C IT T R e c o m m e n d a tio n X .5 0 0 , December 1988. [11] C C ITT, The Directory Authentication Framework, C C IT T R e c o m m e n d a tio n X .5 0 9 , 1988. [12] D. Clark, Design Philosophy o f the D ARPA Internet Protocols, P ro c e e d in g s o f 1988 A C M S IG C O M M S y m p o siu m , August 1988. [13] D. Clark, Policy Routing in Internet Protocols, J o u r n a l o f In te rn e tw o rk in g : R e s e a rc h a n d E x p e rie n c e , Vol. 1, No. 1, October 1990. 128 [14] D. Clark and D. Tennenhouse, Architectural Considerations fo r a New Generation o f Protocols, P ro ceed in g s o f 1990 A C M S IG C O M M Sym p osiu m , September; 1990. [15] D. Clark, D. Wilson, A Comparison of Commercial and M ilitary Computer Security1 Policies, P ro ceed in g s o f 1987 IE E E S ym p osiu m on S ecu rity and Privacy,' May 1987. [16] R. Cocchi, D. Estrin, S. Shenker, L. Zhang, A Study o f Priority Pricing in Multiple Service Class Networks, D R A F T , in su b m ission to 1991 A C M SIG C O M M S ym p osiu m , April 1991. [17] D. Davies and W . Price, Security For Computer Networks, N ew Y o rk , N Y :W iley , 1984. [18] S. Deering, Multicast Routing in Internetworks and Extended LANs, P roceed in gs o f 1988 A C M SIG C O M M S ym p osiu m , August 1988. , [19] W. Diffie, The First Ten Years o f Public-Key Cryptography, P roceed in gs o f th e IE E E , Vol. 76, No. 5, May 1988. [20] W. Diffie and M. Heilman, New Directions in Cryptography, IEEE T ransactions on Inform ation T heory, Vol. 22, No. 11, November, 1976. [21] Digital Equipment Corporation, Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol, October 1989. [22] E. Dijkstra, Self-Stabilization in Spite o f Distributed Control, C om m u nication s o f th e A C M , November 1974. [23] T. El Gamal, A Public Key Cryptosystem and a Signature Based on Discrete Log arithms, IE E E T ransaction on Inform ation T h eory, Vol. 31, July 1985. [24] D. Estrin, Controls fo r Inter-Organization Networks, IEEE T ransactions on Softw are E ngin eering, February 1987. [25] D. Estrin, Interconnection Protocols fo r Interorganization Networks, IE E E Jour nal on S elected A reas in C om m u n ication s, December 1987. i [26] D. Estrin, Policy Requirements fo r Inter-Administrative Domain Routing, C om p u ter N etw ork s and IS D N S ystem s, To appear in 1991. [27] D. Estrin, J. Mogul, G. Tsudik, Visa Protocols fo r Controlling Inter-Organizational Datagram Flow, IEEE Journal on S elected A reas in C om m u n ication s, May 1989. [28] D. Estrin and M. Steenstrup, Inter-Domain Policy Routing: Overview o f Architec ture and Protocols, A C M C om p u ter C om m u n ication s R ev iew , January 1991. [29] D. Estrin and G. Tsudik, Secure Control o f Transit Internetwork Traffic, C om p u ter N etw ork s and IS D N S ystem s, To appear in 1991. ' ________ 1 2 9 ., - [30] D. Estrin and G. Tsudik, End-to-End Argument fo r Network-Layer Access Controls, Journal o f Internetw ork ing: R esearch and E xp erien ce, Vol. 2, No. 2, May ; 1991. [31] D. Estrin and G. Tsudik, Security Issues in Policy Routing, P ro ceed in g s o f 1989 , IE E E S ym p osiu m on S ecu rity and P rivacy, May 1989. ; i [32] D. Estrin and G. Tsudik, Visa Scheme fo r Inter-Organization Network Security, P ro ceed in g s o f 1987 IEEE S ym p osiu m on S ecu rity and P rivacy, April I 1987. ; > I [33] D. Estrin and L. Zhang, Design Considerations fo r Usage Accounting and Feedback > in Internetworks, SIG C O M M C om p u ter C om m u nication s R ev iew , October 1990. [34] European Com puter M anufacturers Association, Inter-Domain Intermediate Sys tems Routing, T echnical R ep ort E C M A /T C 3 2 -T G 1 0 /8 9 /5 6 , May 1989. [35] L. Ford and D. Fulkerson, Flows in Networks, P rin ceto n , N JrP rin ceton U n i v ersity P ress, 1962. [36] J. Galvin, K. McCloghrie, J. Davin, Secure M anagement of SN M P Networks, P ro ceed in gs o f 1991 In tegrated N etw ork M anagem ent S ym p o siu m , April 1991. [37] M. Gasser, A. Goldstein, C. Kaufman, B. Lampson, The Digital System Security Architecture, P roceed in gs o f 1989 N a tio n a l C om p u ter S ecu rity C onference, Noveber 1989. [38] D. Gomberg, A Model o f Inter-administration Network User Authentication and Access Control, M IT R E C orp. T echnical R ep ort M T R -87W 00003, Decem ber 1987. [39] S. Hares, D. K atz Administrative Domains and Routing Domains, a Model fo r Rout ing in the Internet, R F C 1136, SR I N etw ork Inform ation C en ter, December 1 1989. [40] C. Hedrick, A n Introduction to IG RP, R u tgers U n iv ersity T echnical R ep ort, O ctober 1989. [41] E. Horowitz and S. Sahni, Fundamentals o f Computer Algorithms, R o ck v ille, M D :C om p u ter S cience P ress, 1978. [42] IEEE 802.10, Standard for Interoperable LAN Security, L A N S ecu rity W orking G roup, P 8 0 2 .1 0 /D 6 , September 1989. [43] International Standards Organization, Information Processing System s - Open Sys tem s Interconnection - Basic Reference Model, ISO 7498, 1977 i [44] International Standards Organization, Security Architecture, ISO 7498-2- 1988(E ), 1988 .130 [45] International Standards Organization, O SI Routeing Framework, IS O /T F 9575, January 1989. [46] P. Karger, Authentication and Discretionary Control in Computer Networks, C om p u ter N etw ork s and IS D N S y stem s, January 1986. [47] C. Kent and J. Mogul, Fragmentation Considered Harmful, P roceed in gs o f 1987 A C M SIG C O M M S ym p osiu m , August 1987. [48] S. Kent, Protocols and Techniques fo r Data Communication Networks, E nglew ood C liffs, N J :P ren tice H all, 1980. [49] A. Konheim, Cryptography, a Prim er N ew Y ork, N Y :W iley , 1981. [50] M. Lepp and M. Steenstrup, A n Architecture for Inter-Domain Policy Routing, B B N R ep ort N u m b er 7345, July 1990, BBN Corporation, Cambridge, MA 02138. [51] J. Linn, Privacy Enhancement fo r Internet Electronic Mail. Part I: Message Enci pherment and Authentication Procedures, R F C 1113, SR I N etw ork Inform a tion C enter, January 1989. [52] M. Little, Dissimilar Gateway Protocol (DGP'), W orking P ap er, 1988. [53] K. Lougheed and Y. Rekhter, Border Gateway Protocol, R F C 1163, SR I N e t w ork Inform ation C enter, June 1990. [54] K. Lougheed and Y. Rekhter, Border Gateway ProtocolBIFC 1105, SR I N etw ork Inform ation C enter, June 1989. [55] J. M cQuillan, Adaptive Routing Algorithms for Distributed Computer Networks, B B N Inc, B B N T R 2831, May 1974. [56] J. McQuillan, I. Richer, E. Rosen, The New Routing Algorithm for the A R P A N E T, IEEE T ransactions on C om m u nications, May 1980. [57] R. Merkle, One-way Hash functions and DES, P ro ceed in g s o f C R Y P T O 89, August 1989. [58] D. Mills, On the Accuracy and Stability o f Clocks Synchronized by the Network Time Protocol in the Internet System, A C M C om p u ter C om m u n ication s R eview , January 1990. [59] D. Mills, Internet Time Synchronization: the Network Time Protocol, R FC 1129, SR I N etw ork Inform ation C enter, October 1989. [60] P. Mockapetris, Domain Names - Implementation and Specification, R FC 1035, SR I N etw ork Inform ation C enter, November 1987. [61] J. Mogul, Simple and Flexible Datagram Access Controls fo r Unix-based Gateways, P ro ceed in gs o f S u m m er 1989 U S E N IX T echnical C onferen ce, August 1989. __________ 131 [62] J. Moy, The Open Shortest Path First (OSPF) Specification, R F C 1131, S R I N e tw o rk In fo rm a tio n C e n te r, October 1989. [63] J. Mracek, Network Access Control in M ulti-Net Internet Transport, S .B . T h e sis, M IT D e p a rtm e n t o f E le c tric a l E n g in e e rin g a n d C o m p u te r S cience, June 1983. [64] S. Mulender et al, Amoeba: A Distributed Operating System for the 1990s, IE E E C o m p u te r, Vol. 23, No. 5, May 1990. [65] T. N arten, Internet Routing, P ro c e e d in g s o f 1988 A C M S IG C O M M S y m p o siu m , August 1989. [66] N ational Bureau of Standards, Federal Information Processing Standards, National Bureau of Standards, Publication 46, 1977. [67] R. Needham and M. Schroeder, Using Encryption fo r Authentication in Large Net works of Computers, C o m m u n ic a tio n s o f th e A C M , Vol. 21, No. 12, December 1978. [68] R. Needham and M. Schroeder, Authentication Revisited, A C M O p e ra tin g S ys te m s R ev iew , Vol. 21, No. 7, January 1987. [69] D. Nessett, Factors Affecting Distributed System Security, IE E E T ra n s a c tio n on S o ftw are E n g in e e rin g , Vol. SE-13, 1987. [70] M. Padlipsky, The Elements o f Networking Style, E n g lew o o d C liffs, N J :P r e n tic e H all, 1985. [71] R. Perlm an, Network Layer Protocols with Byzantine Robustness, P h .D . D isse r ta tio n , M IT L C S T R -4 2 9 , October 1988. [72] R. Perlm an, Fault-Tolerant Broadcast of Routing Information, C o m p u te r N e t w o rk s a n d IS D N S y ste m s, December 1983. [73] J. Postel, Internet Protocol, R F C 791, S R I N e tw o rk In fo rm a tio n C e n te r, September 1981. [74] J. Postel, Internet Control Message Protocol, R F C 792, S R I N e tw o rk In fo rm a tio n C e n te r, September 1981. [75] R. Rivest, The MD4 Message Digest Algorithm, P ro c e e d in g s o f C R Y P T O ’90, August 1990. [76] R. Rivest, A. Shamir and L. Adleman, A Method for Obtaining Digital Signatures and Public Key Cryptosystems, C o m m u n ic a tio n s o f th e A C M , February 1978. [77] E. Rosen, Exterior Gateway Protocol (EGP), R F C 827, S R I N e tw o rk In fo rm a tio n C e n te r, October 1982. [78] J. Saltzer, D. Reed, and D. Clark, End-to-End Arguments in System Design, A C M T ra n sa c tio n s o n C o m p u te r S y ste m s, June 1984. 132 [79] J. Saltzer and M. Schroeder, Protection of Information in Computer System s, P r o ceed in g s o f th e IE E E , September 1975. [80] M. Satyanarayan, Scalable, Secure, and Highly Available File Access, IE E E C o m p u te r , Vol. 23, No. 5, May 1990. [81] SDNS Protocol and Signaling Working Group, SP3 Subgroup, SD N S Secure Data Network System Security Protocol 3 (SP3), S D N .301 R ev isio n 1.5 1989-05-15 [82] A. Shimizu, S. Miyaguchi, Fast Data Encryption Algorithm (FEAL), P ro c e e d in g s o f E U R O C R Y P T ’87, April 1987 [83] K. Soilings, Cascaded Authentication, P ro c e e d in g s o f 1987 IE E E S y m p o siu m o n S e c u rity a n d P riv a c y , April 1987. [84] M. Steenstrup and Open Routing Working Group, Inter-Domain Policy Routing Specification, B B N R e p o r t N u m b e r 7346, December 1990, BBN Corporation, Cambridge MA 02138. [85] J. Steiner, The Kerberos Network Authentication Service Overview, M IT P r o je c t A th e n a R F C , D ra ft 1, April 1989. [86] A. Tanenbaum, Computer Networks, E n g lew o o d C liffs, N J :P r e n tic e H all, 1981. [87] P. Tsuchiya, Efficient and Robust Policy Routing using Multiple Hierarchical Ad dresses, D R A F T , in su b m issio n to 1991 A C M S IG C O M M S y m p o siu m , April 1991. [88] G. Tsudik, Datagram Authentication in Internet Gateways, IE E E J o u r n a l on S e le cted A re a s in C o m m u n ic a tio n s, May 1989. [89] U.S. D epartm ent of Defense, Trusted Computer System Evaluation Criteria, S ta n d a rd 5 200.28-S T D , December 1985. [90] V. Voydock and S. Kent, Security Mechanisms in High-level Network Protocols, A C M C o m p u tin g S u rv ey s, June 1983. [91] S. Walker, Network Security: the Parts o f the Sum, P ro c e e d in g s o f 1989 IE E E S y m p o siu m o n S e c u rity a n d P riv a c y , May 1989. 133 A p p e n d ix A M essa g e A u th e n tic a tio n w ith O n e-W ay H ash F u n ctio n s jln this appendix, we discuss some potential applications of fast one-way hash functions to the problem of message authentication. Several methods for protection against message substitution are presented. The security of the proposed methods is conjectured to be equivalent to the strength of the underlying one-way hash function. A .l In tro d u ctio n In recent years, some im portant advances were made in the area of fast one-way hash functions for message integrity. One of these functions, Rivest’s Message Digest algorithm (MD4)[75], is considered by many in the security community to be the most promising (and hereto unbroken) method. Due to its structure, MD4 lends itself to software imple m entations th a t can perform at speeds significantly higher than earlier, encryption-based integrity methods, e.g., DES-based MAC[66, 17]. In brief, MD4 computes a 128-bit digest of an arbitrary length message. Its basic input unit is a 512-bit data block. It is conjectured th at MD4 possesses the following properties: 1. The difficulty of computing two distinct messages, M i and M 2 such th a t M D 4(M i) = M D A {M 2 ) is on the order of 264 operations. 2. Given a message digest, M D , the difficulty of computing a message, M such that M D 4(M ) = M D is on the order of 2128 operations. The second property is of particular interest. It is based on the fact th at MD4 maps 2512 512-bit blocks into 2128 1 28-bit digests. Consequently, on the average, [2512/2 128 = 2384] blocks are hashed into the same 128-bit digest. Therefore, given a message digest, it takes, on the average, 2128 trials before discovering one of the 2384 messages th at maps into th at digest. A . 2 M o tiv a tio n In the realm of secure communications, message integrity alone does not provide sufficient defense against some attacks. While a strong one-way hash function protects against data modification, protection against message substitution requires th a t the message integrity 134 value be irreproducible. Encryption-based integrity methods provide this service since one of the inputs to the integrity function is a secret key (e.g., DES). This is not the case w ith MD4. Since MD4 implementations are readily available, anyone can produce an MD4 value of an arbitrary message and insert [msg, M D 4(m sg)\ into the stream . One simple solution is to require th at the message source encrypt the MD4 value of each message. In a public key cryptosystem, this can be done with the sender’s private key. jln a conventional cryptosystem, the sender can use the secret key shared amongst the appropriate parties. W hile this simple approach solves the message substitution problem, it has some drawbacks. Even though the use of expensive encryption is limited to signing a short ■fixed-length message digest, encryption still takes its toll. Even the fastest commercially (available cryptographic devices operate at rates about an order of m agnitude behind MD4, especially, for small d ata units [1]. Drawing from the discussion above, an ideal scenario for countering both message substitution and message modification attacks would: i) avoid encryption altogether, and ii) produce unforgeable integrity values. Initially, these two properties appear to be at odds, however, some innovative application of fast one-way hash functions may be able to reconcile them. A .3 P r o to c o l D esc rip tio n We suppose th a t two principals, A and B , would like to communicate over an insecure channel. Furtherm ore, there exist secure means of principal authentication [67, 90, 85]. At the tim e of session initiation, after m utual authentication is achieved, one of principals, say, A , generates a random 512-bit value, S a b • A then communicates S a b to B in secret (using encryption, if necessary). W hen A has a message M to send to B , it computes M D m — M D A (M \\S a b )1 ■ It then sends [M, M D m ] to B . Since B possesses S a b , it can re-compute M D 4 (M \\S a b ) and verify M D m • We refer to this m ethod as the secret suffix technique. Alternatively, A and B can agree to compute M D m as M D 4{S a b \\M ) and use S a b as a secret prefix. The secret prefix m ethod was developed independently by the Internet Security and Privacy Working Group (SPW G)2 for use in Simple Network Management Protocol (SNM P) [36]. A .4 In form al A n a ly sis Throughout the following discussion it is assumed th a t an intruder has the ability to record and analyze messages as well as insert fraudulent messages into the message stream. In order to mount a successful attack or effectively break the protocol, an intruder has to be able to produce a fraudulent message and an accompanying digest such th at the {m essage, digest) pair is accepted as genuine by any of the legitim ate principals. 1J ) denotes concatenation. 2S. Crocker, S. K ent, Private Com m unication, December 1990. 135 The following observations are based on the second property3 of the MD4 algorithm: • C la im 1: Given a message digest, M D , and a message M \, the difficulty of com puting a message, M 2 such that M D4(M 2\\M \) — M D is on the order of 2128 operations. • C la im 2: Given a message digest, M D , and a message M \, the difficulty o f com puting a message, M 2 such that M D A{M \\\M 2 ) = M D is on the order of 2128 operations. | Assuming these two claims hold, the only venue left to the intruder is the brute force 'attack. For most purposes, attacks th at take on the order of 2128 are considered fu tile , i.e., the system being attacked is considered secure4 Still, understanding the details of possible attacks is of interest. As described below, the two seemingly similar methods proposed differ in their ability to w ithstand brute force attacks. A .4 .1 D e fin itio n s • Given two 512-bit blocks, M \ and M 2 , we say th at M \ = M 2 if M D A {M \) = M D 4(M 2). The ’= ’ symbol denotes th a t M \ and M 2 are prefix-equivalent. For a given 512-bit block M , let P E C m denote the prefix-equivalence class of M . • Two 512-bit blocks, M \ = M 2 if for all blocks M , M D A {M \\M \) = M D A (M \\M 2 ). The ’= = ’ symbol denotes th at M \ and M 2 are su ffix-equivalent. Let S E C m denote the suffix-equivalence cla ss of a 512-bit block M . A .4 .2 S e c r e t P r e fix A naive intruder wishing to discover the secret prefix would first record a message M accompanied by its integrity value, M DA(Sa b \\M ). He would then need to try on the average 2128 possibilities before discovering a prefix string S where S = S a b - One im portant observation th at can be made by a more astute intruder is th a t the secret prefix, S a b , is not really what is needed to break the protocol. In other words, the secret prefix is sufficient, yet not necessary, for a successful attack. Instead, to attain the goal of composing genuine messages, the intruder needs only the interm ediate MD4 value of Sa b , i-e- > M DA(Sa b )- The length of M D A (S a b ) is 128 bits regardless of the length of S a b - Nevertheless, the number of operations required to find M D A (S a b ) remains a hefty 2128. The subtle difference between the n a ive and the more educated brute force attacks is th at, in the latter, the intruder is guaranteed to discover M D A (S a b ) (hence, successfully attacking the protocol) in at most 2128 operations. This is in contrast to the former where on the a v erag e 2128 operations are required. In summary, the shortcut makes the attack d e te r m in is tic as opposed to p ro b a b ilistic. 3See Section A .I. 4 Brute force attack on DES requires o n ly on the order of 2s6 operations. 136 A .4.3 S ecret Suffix i A brute force attack on the secret suffix variant is similar in th at the intruder would need to try on the average 2128 possibilities before discovering an S such th at MD4(M\\S) — MDA(M\\S a b ) ■ However, the probability th a t S — Sa b is only 1/2384 ( since there are, on the average, 2384 512-bit blocks which are hashed into the same 128-bit MD4 value). On the other hand, finding an 5 such th a t 5 = Sab is> f°r 3 -1 1 purposes, equivalent to , finding SAb - At this point in tim e, because of MD4’s relatively recent introduction, and, hence, i lim ited analysis thereof, little can be said with certainty about the average size of suffix- 1 equivalence classes. One conjecture th a t can be made w ith some degree of certainty is th at the size of an average suffix-equivalence class is no greater than th at of an average prefix-equivalence class. This does not imply, however, th at it takes at most 2128 operations to find S = X S ab ■ Note th a t the intruder has to record multiple genuine messages and compute their respective digests at each step of the attack. Thus, the number of operations required to find 5 is IV X 2128 where N is the size of the intruder’s message test pool. We also note th a t, in the suffix variant, there appears to be no counterpart to the shortcut described in the previous section. A .5 C ost It is evident from the above discussion th at, provided M D4’s conjectured properties hold, both secret suffix and secret prefix variants provide strong protection against unauthorized message fabrication and tam pering. Just as there are some subtle differences among the two variants with respect to their ability to w ithstand attacks, there are also differences in their respective cost. The prefix variant costs close to nothing, since the interm ediate MD4 value of the secret prefix can be pre-computed and used as a sort of a initialization vector for verifying message signatures. Furthermore, the concept of a prefix can be abandoned altogether in favor of a 128-bit MD4 initialization vector. Secret suffix costs slightly more as no pre-com putation can be done. The cost amounts to exactly one extra 512-bit block MD4 com putation per message. A .6 A n E x te n sio n A t this tim e, any protocol requiring on the order of 2128 operations to defeat is considered strong, i.e., secure. Nevertheless, it is conceivable th at a need for stronger protocols may arise in the future. For this reason, we consider a combination of the secret suffix/secret prefix variants. In this third variant, the MD4 value of a message is computed by using a secret initialization vector and by appending an (also secret) 512-bit suffix. The cost of this variant is equivalent to the cost of the suffix m ethod alone5, while the brute force 5 A s m entioned above, the secret prefix m ethod adds no cost to digest com putation. 137 jattack would require 2256 operations. This is significantly stronger than either of the two ■methods discussed thus far. A . 7 A p p lic a tio n s |The secret suffix/prefix methods are particularly applicable to environments where high bandw idth and low delay requirements have, until now, m ade the im plem entation of certain security services prohibitively expensive, e.g., packetized voice and video applica tions. Also, network layer protocols, e.g., Inter-Dom ain Policy Routing (IDPR) [84] and Visa protocol [27], can benefit substantially from encryption-free message authentication. A .8 S u m m ary lln conclusion, fast one-way hash functions such as MD4 can be used as a foundation for Isome novel implementations of security services. In particular, simple and inexpensive jsecret prefix and secret suffix methods provide protection against message substitution 'attacks when used in conjunction with a strong one-way hash function (which protects ^against message modification). The strength of the methods presented herein is largely dependent on the ability of the underlying hash function to w ithstand hostile attacks. 138

Abstract (if available)

Linked assets