Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
00001.tif
(USC Thesis Other)
00001.tif
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
D ESIG N IN G AND REA SO N IN G A BOU T IN T E R C O N N E C T E D A U TONOM OUS REG IO N S by Sharon Anderson A D issertation Presented to the FACULTY O F T H E G RAD U A TE SCH O O L U N IV ER SITY O F SO U TH ERN C A LIFO R N IA In P artial Fulfillm ent of the R equirem ents for the Degree D O C T O R O F PH ILO SO PH Y (C om puter Science) A ugust 1993 Copyright 1993 Sharon Anderson UMI Number: DP22858 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. UMI Dissertation Publishing UMI DP22858 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 ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, MI 48106- 1346 F V v D . UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90007 A 5 41 £ps This dissertation, written by Sharon Regina Anderson under the direction of h&r. 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 D O CTO R OF PHILOSOPHY Dean of Graduate Studies D a te.... DISSERTATION COMMITTEE P reface In May 1989, Sharon Anderson died tragically in a sky diving accident. The admin istration at U.S.C. has graciously agreed to accept this document, an early draft of her thesis, as fulfillment of the requirem ents for the degree of Doctor of Philosophy, to be awarded posthumously. This degree is being awarded both because her work deserves this recognition and because it is a fitting tribute to her as a person. C o n te n ts P refa ce ii A b str a c t v 1 In tro d u ctio n 1 2 In terco n n ected A u ton om ou s R eg io n s 4 2.1 T he Research I n t e r n e t ...................................................................................... 4 2.2 A dm inistrative H e te ro g e n e ity ........................................................................ 5 2.3 Technological H e te ro g e n e ity ............................................................................ 6 2.4 E v o lu tio n .............................................................................................................. 7 2.5 A utonom y and In terd ep en d en ce..................................................................... 7 3 T h e M o d el 11 3.1 Basic Components ...................................................................................................11 3.2 Graphical R epresentation........................................................................................ 12 4 D escrib in g P ro p erties o f IA R s 17 4.1 Algebraic S p ecificatio n ............................................................................................18 4.2 Horn Clause Specification of B e h a v io rs ............................................................ 21 4.3 L a rc h ............................................................................................................................. 22 4.4 State-D ependent B e h a v io r........................................................... 24 5 T h e M eth o d o lo g y 28 5.1 Applications of the Methodology ...................................................................... 29 5.2 Overview of the M e th o d o lo g y ............................................................................. 31 5.3 Applying the Methodology to Existing ARs .................................................. 37 5.4 Partitioning a Flat S y s te m .................................................................................... 44 5.5 C hapter Summary ..................................................................................................45 6 N a v ig a tio n 47 6.1 O verview ......................................................................................................................48 6.2 C lark’s Policy Representation N o ta tio n ............................................................50 6.3 A Representation of a research in te r n e t............................................................51 6.4 T he N av ig ato r............................................................................................................56 iii 6.5 Application of the Navigator to the research internet example . .. . 60 7 V erification o f a P o licy R o u te P ro to co l 67 7.1 Formal Description of a Secure Policy Route P ro to c o l................................. 68 7.2 The S p ecificatio n ....................................................................................................70 7.3 Verifying a Security P r o p e r t y ............................................................................79 7.4 D iscu ssio n .................................. 83 8 S im u latin g Form al D escrip tio n s 85 iv A b stra ct Modern internets, in which government, commercial, and academic networks inter operate and share resources, form a new class of computer systems. The prim ary characteristics of such systems are th at their components are adm inistratively au tonomous, their implementations are technologically heterogeneous, and they evolve over tim e. The goal of this thesis is to lay the foundation for an environment for the design, analysis, simulation, and im plem entation of such Interconnected Au tonomous Regions. There are two prim ary facets of this work. First, we introduce a model of Interconnected Autonomous Regions. We give this model a graphical representation th at is analogous to the various structured diagrams used in most software engineering methodologies. This representation serves as the basis for au tom ated design tools, such as a navigation simulator, th at manage the internet de velopment process. Second, we provide a means for formally stating and reasoning about properties of a given design. v C h ap ter 1 In tro d u ctio n Today there is much more to network and internet design than simple physical con nectivity. Increasingly, government, commercial, and academic networks need to interoperate and share resources. The interconnection of these systems must sup port electronic mail; file transfer for the exchange of graphics, voice, and text; and resource sharing such as of a database or a supercomputer. Such systems, called Interconnected Autonomous Regions, form a new class with characteristics th at are not found in, and often specifically precluded by, most other classes of systems. The three critical differences are a u to n o m y , h e te ro g e n e ity , and e v o lu tio n . Tradi tional systems assume a single governing domain, where ail constituents adhere to a single, usually hierarchical, policy. Technological uniformity (all nodes must speak TC P) is a requirem ent and diversity is discouraged. Furtherm ore, once a system architecture is defined, it is fixed for the life of the im plem entation. Even dis tributed systems share a common com putational goal, or at least a ccrnraon policy and homogeneous mechanisms for resource control and inform ation sharing. Increased risk results from perm itting users who are not under the adm inistra tive control of a given system to access part or all of that system. As a result, access control and auditing functions are needed to constrain and m onitor external users. Network resource management and control requirements arise from the need to ac count for usage and to he able to prevent denial of access to resources. Ultimately a great diversity of usage policies and enforcement mechanisms will emerge that must be supported within the context of both autonomy and inherent interdependence. The need for adm inistrative autonomy makes it unacceptable to implement usage controls and security policies with simple global mechanisms and m andates. More over, ad hoc internet design will ultim ately force a loss of desired connectivity in order to prevent unauthorized resource usage. The most cost-effective way to integrate policy into internet design is to incor porate policy into the design process, since it is difficult or impossible to retrofit security into a system. To achieve this, designers must be able to express policy as an integral part of the network design. Tools must be provided to allow the network designer to study the im pact of local policies on logical connectivity. Since these tools deal with issues of secrecy and trust, they must be built on formal founda tions, and must provide support for formal descriptions of network properties and mechanisms. Existing models and methodologies for building secure systems do not provide a means for describing or analyzing modern internets. Generally speaking, such models are geared towards expressing design requirements at a single level of abstraction, assume a technologically uniform implementation, and do not provide adequate support for changing the system topology and analyzing the results of the change. The goal of this thesis is to define an environment for the design, analysis, simu lation, and im plem entation of Interconnected Autonomous Regions. There are two prim ary facets of this work. First, we introduce a model of Interconnected Au tonomous Regions. We give this model a graphical representation that is analogous to the various structured diagrams used in most software engineering methodolo gies. This representation serves as the basis for autom ated design tools, such as a navigation simulator, th at manage the internet development process. Second, we provide a means for formally stating and reasoning about properties of a given de sign. Our notation is based on the Larch [GHW85] ”two-tiered” approach to formal specifications. Unlike Larch, we combine Horn-clause logic with algebraic data type specifications to achieve executable specifications. This thesis is organized as follows. C hapter 2 describes the relevant charac teristics of Interconnected Autonomous Regions. Chapter 3 introduces our model of Interconnected Autonomous Regions and presents our graphical representation. C hapter 4 introduces our formal notation for describing properties of an internet design. C hapter 5 integrates the graphical notation, and the formal notation into a methodology for designing and reasoning about interconnected autonomous regions. 2 C hapter 6 presents two detailed designs at different levels. The first example deals with integrating usage policies in the design of the Research Internet. The second example is concerned with specifying interconnected autonomous region behavior at the level of network protocols and describes a secure policy route protocol. C hapter 7 describes tools for analyzing systems designed using the methodology described here. Specifically, an analysis of the research internet design provided by the naviga tion sim ulation tool is presented, and the secure policy route protocol is discussed. C hapter 8 discusses related research. C hapter 9 presents conclusions and examines future directions for the research. 3 C h ap ter 2 In terco n n ected A u to n o m o u s R egion s This chapter explores the dominant characteristics of Interconnected Autonomous Regions and the resulting constraints on our ability to model, design and implement them . As a first step, we introduce a specific example, the Reseach Internet, which will be discussed throughout this thesis. We then, in turn, discuss adm inistrative heterogeneity, technical heterogeneity, evolution, and autonomy and interdepen dence. Of these characteristics, adm inistrative heterogeneity is the most significant, and can be viewed as the source of many other attributes of these systems. 2.1 T h e R esearch In tern et The United States government has recognized the economies of scale to be gained by resource sharing. Thus, it has required th at its agencies make their resources avail able to one another to maximize the usage of more expensive resources. Resources to be shared include backbone services, circuits, gateways, expert information services, and user information services. The interconnection requirements are, currently, that the agencies carry traffic for other agencies on a resource available basis, and that accounting mechanisms for metering m ajor resources be implemented. This internet is referred to as the Research Internet, or Internet. The Internet has evolved from a single backbone network (the A rpanet) with connected campus networks, to an internet of multiple peer backbones (NSFnet, A rpanet, NASA, DOE), and regional access networks (e.g., Los N ettos, NEARnet, etc.), each of which connect to many commercial, university and government local networks. The Research Internet per se is composed of end and interm ediate systems 4 th at speak IP [Pos81]. In addition, there are application level relays to non-IP networks such as B ITnet/E A R N and CSNET Phonenet. The Internet is growing larger and more diverse. An unavoidable side effect of this growth is the pressing need for management and control of network and computing resources, in particular access control and accounting. For example, commercial and government organizations must protect their private computing resources from unauthorized access and account for the use of both communication and network resources On the surface, academic organizations are less concerned with access control and accounting than m ilitary or even commercial systems, but they too must pro tect themselves from denial of service resulting from malfunctioning external hosts and nodes, and must also be able to control traffic if they are connected to other organizations th at are concerned with these issues. 2.2 A d m in istra tiv e H etero g en eity As already noted, one of the key attributes of interconnected autonomous regions is th at each different region may belong to different and independent authorities. Each adm inistration controls and is responsible for its own resources th a t are shared with the rest of the internet. The adm inistration determines and sets the policies defining who may access what resources on what basis and at what rate of compensation. For example, in the Research Internet, one agency may decide to carry all transit traffic for any other agency, company, or university, as long as the traffic is for research or Internet support activities. Another agency may decide th at it will carry no transit traffic, and th at it will perm it connections only with other agencies; no communication with universities or commercial companies will be perm itted. Once the policies are set, several things must happen: the policies m ust be communicated to the other elements of the system, there must be a way to determine what the connectivity of the system is based on the policies controlling usage, and mechanisms must be implemented to ensure th at the policies are enforced fairly and accurately. This implies th at adm inistratively defined resource control, as opposed to globally defined resource control, must be a part of the internet design process. 2.3 T echn ological H etero g en eity Technological heterogeneity is largely a by-product of adm inistrative heterogeneity. Different adm inistrations have different computing needs, budgets, and biases that result in a diversity th at will not be eliminated by standards. Protocols, operating systems, and services are developed independently to support hardware features, provide special purpose services, and to support research into new computing mech anisms. For example, in the Research Internet, a university will be much less concerned with controlling access to its data or resources than say the D epartm ent of Energy (DOE), which m ust ensure th at sensitive information is accessible only by those users authorized to see or modify the information, and must also ensure th at critical re sources are available when needed; this is sometimes referred to as assured service or prevention of denial of service. Thus, the DOE will require hardware and software tailored to enforce its access control and usage policies that are not required for the university. This clearly adds unavoidably to technological heterogeneity since, with out these controls, the DOE could not perm it interconnection with the Internet, and yet the universities should not be required to pay the overhead costs of mechanisms they do not need. Because component systems arise independent of the eventual interconnected system, technological heterogeneity also occurs through the im plem entation of sim ilar functions in diverse technologies. The most common example in networks is the diversity in communication protocols (e.g. ISO OSI and SNA). Standards and uniformity cannot entirely solve the problem, partially because of the sometimes prohibitive cost of retrofitting new standards and because standards and uniformity lead to inadequate mechanisms and discourage advances in technology. The result is that, not only do m ultiple adm inistrations (i.e. rules) need to be supported, but also diverse technology must be integrated. Technological hetero geneity m ust be supported; it cannot be eliminated. In addition, evolution, as will be discussed in the next section, adds to the technological complexity of the systems by introducing new mechanisms and new solutions to existing requirements. 6 2.4 E v o lu tio n Interconnected autonomous regions are generally dynamic systems. New regions enter the system as old ones leave. Individual regions expand and contract. For example, in the Research Internet, a new company or government agency could join the internet. Administrations themselves may acquire new hosts or network re sources; other hosts may loose access privileges or term inate. The resulting changes can be both technological and adm inistrative. New computing resources must be integrated to achieve interoperability with existing peers. As new regions enter, their usage policies m ust be supported and be m ade known to affected regions, their technologies integrated, and requirements supported. The new system may also have to incorporate new mechanisms in order to provide controlled access to the resources it wishes to share and to prevent access to resources it does not want to share. In addition, the incorporation of new regions may cause existing regions to mod ify their policies to perm it or deny access. As a result, both logical and physical connectivity may change. These changes must be communicated to the components and the components must be able to determ ine the im pact of the changes on their local policies and resource needs. Finally, as technology evolves and new computing needs are identified, new services may be added to the system. 2.5 A u to n o m y and In terd ep en d en ce Autonomy and interdependence are highlighted here because previous work in dis tributed systems has tended to support one in favor of the other. In fact, it is often the case th at the design goal is to exclude one in favor of the other. In the design of interconnected autonomous regions, however, a compromise between autonomy and interdependence must be achieved, rather than the simple elimination of one or the other. As we have seen, one cannot simply m andate, for example, that all systems will adhere to the same usage or security policies (elimination of autonomy), nor can is be m andated th at external access be prohibited (elimination of interdepen dence). This results from the fact th at autonomy is not just lack of dependence on the correct functioning of other components, it is also self governance through local 7 definition and control of resources and information (e.g. billing and access control). Interdependence, on the other hand, implies compromise of autonomy and has as its goal interoperability. A successful design, then, will provide sufficient interdepen dence to achieve the desired level of communication and sharing while minimizing the impact on autonomy. Attaining a reasonable balance between autonomy and interdependence is diffi cult. Local decisions concerning external users access and usage privileges often have unpredictable global effects. For example, a local decision not to accept transit traf fic routed through a given region may result in an unintended loss of communication between regions. However, achieving desired connectivity and policy enforcement at a given point in tim e does not ensure th at the existing set of policies may rem ain static. Be cause policies are w ritten for a specific topology of adm inistrative regions, when the topology evolves, desired connectivity may be lost and/or undesired connectiv ity may occur. For example, when a new adm inistration enters the system, those adm inistrations wishing to communicate with the new adm inistration may have to modify their policies to include the new adm inistration. The adm inistrations to which the new one is directly connected must decide whether or not they will carry transit traffic for the new adm inistration and modify their policies accordingly. The new adm inistration may be an unreliable carrier or may be malicious, i.e., may at tem pt to access resources for which it is not authorized or may even attem pt to steal authorizations. This case may necessitate both changes in policy (e.g. if you route through the new adm inistrative region, I will not accept your packets) and changes in enforcement mechanisms, such as encrypting and then cryptographically sealing authorizations to packets. The need to support both autonomy and interdependence gives rise to a number of research questions. Given th at one has a policy to enforce for a particular adm in istrative domain, what mechanisms provide suitable enforcement? W here should these mechanisms be placed for minimal cost and greatest effectiveness? How can local policies be enforced without precluding desired interdependence? How are ac ceptable routes determined given the complex web created by autonomously defined policies? One partial solution to the latter problem is the policy routing protocol developed by Clark [Cla90]. Navigation must also address security issues such as 8 preservation of navigation data and the trade-off between assurance and perfor mance [ET91]; and determining the appropriate granularity at which to perform navigation. Finally, and most fundamentally, there is the question of how to represent, or model, interconnected autonomous regions and their policies so th at there can be a meaningful and useful bridge from policy representation to technical enforcement mechanism [AE88]. The representation should aid the design and development of mechanisms to achieve interconnected autonomous regions from the description of the autonomous regions, their policies, and their direct connections. Furtherm ore, the model should help designers study the global im pact of local decisions. Most existing models of distributed systems are inadequate because their views and underlying assumptions preclude the interconnection of autonomous regions. Until recently, models have been constructed for ’ ’systems” that are essentially sin gle host com puters with negligible external communication. Even those models that do attem pt to address networks assume th at the networks are both adm in istratively and technologically uniform and are static. (A notable exception may be the Ulysses/M altheis and Hook-up security work of Odyssey Research.) Thus, existing models are designed to meet the requirem ents of systems that are tech nologically uniform, essentially unchanging over time, and are contained within a single boundary. Most methods model systems at a level of granularity th at is inappropriate for interconnected autonomous regions, and do not support non-uniform granularity of abstraction at a given level. While it is not the object of a specification to represent every detail of the system, part of the power of specifications is the ability to abstract away from detail. The problem is always, however, finding the appropriate level of detail. One of the difficulties in applying existing methodologies is th at they are generally designed for expressing fine-grained properties of programs and systems, e.g. atom ic operations on simple data structures. However, we need the ability to express very large grain properties, e.g. at the granularity of ARs, hosts and routers, and then express specific, finer grained properties within the larger grained context. For example, instead of modeling the detailed semantics of router to router message passing, we wish to model the packet forwarding function within the context of routers belonging to different ARs. The informal model must provide support 9 for representing system properties at various levels, and for refining abstractions to increasingly lower levels of detail. Some simplifying assumptions must be made in the construction of any model, but the assumptions must be appropriate to the systems modeled. While the as sumptions of homogeneity and non-dynamism have worked well in the past, they are not appropriate to interconnected autonomous regions. 10 C h ap ter 3 T h e M o d el In this chapter, we develop an informal model of interconnected autonomous regions. This model is an abstraction of the basic characteristics of such systems; it consists of a set of prim itive entities, their properties, and the rules governing their behaviors and interactions. This model will be used as the foundation for describing general properties of Interconnected Autonomous Systems; for building a collection of inter net design tools that provide support for integrating various classes of policies into an internet design and reasoning about the im pact of those policies on the internet connectivity; and for building tools th at support specification and implementation of mechanisms and services of interconnected autonomous regions. 3.1 B a sic C om p on en ts Our model recognizes two categories of operations: adm inistrative operations, which are concerned with managing the internet components, and host/user operations, which relate to the use of the internet services and resources. A dm inistrative op erations can be subdivided into two additional classes: those th at manage network resources and those th at control hosts. Network management operations include defining and enforcing resource usage policies, providing types of service, and ac counting and billing for resource usage. Host control operations include providing identification of hosts to other ARs; authorizing the privileges of internal hosts and external ARs and hosts; authenticating the identity of hosts; and validating the asserted privileges of hosts requesting resource access. 11 Based on these two categories of operations, we define two prim ary objects in the model: Autonomous Regions and hosts. The term Autonomous Region, or AR, is borrowed from C lark’s terminology [Cla90], and models adm inistrative domains. Host objects model th at set of entities th at use the internet resources and are under the control of some adm inistration. Every host and network resource in the internet m ust belong to exactly one AR. We model the situation where a host belongs to more than on adm inistration as th at host being granted special privileges by another AR. In addition to ARs and host objects, we have services, also called processes, and communication links. Services are resources that perform a specific function for the invoking entity. For example, a host may invoke a Policy Server process to determ ine if there is a valid policy route from that host’s AR to the destination host. Services belong to and are under the control of their encompassing AR. The owning AR determines the usage privileges for the service. Communication links define connectivity between the ARs. These links are es sentially points of interdependence where interoperability must be achieved. Directly connected ARs are communication neighbors. Note that communication links con nect ARs to ARs; a communication link cannot connect a host to a host, a host to a process, two processes, or a host to an AR. Host communication paths are always defined in term s of the ARs that contain the hosts and any transit ARs. The set of ARs, with their hosts, and communication links forms a topology of a system of interconnected autonomous regions. 3.2 G raphical R ep resen ta tio n In this section, we present a graphical notation for our model of interconnected autonomous regions. Our prim ary interest is in supporting reasoning about global implications of local policies, so that appropriate internet mechanisms can be de signed that will effectively realize the desired connectivity and achieve the desired controls. However, global implications of local decisions, policies, and requirements can only be analyzed and understood within the context of a specific instantiation of the system ’s adm inistrative interdependencies. T hat is, to fully understand how 12 a given policy statem ent im pacts connectivity, for example, the current intercon nection of ARs must be known For example, in the Research Internet, the inter-AR dependencies are defined by usage policies. So in a graphical representation of the Internet, each connection would be annotated with a corresponding policy state m ent th a t governs the use of that connection. Thus our notation must include a representation for ARs, interconnections, and hosts. This graphical notation will also be used to provide an effective, easy to learn, efficient interface to autom ated tools. The same ease of expression th at applies to paper designs applies to the use of autom ated tools. Using the same notation for expressing our designs on paper as interface to tools, makes it is easier for designers to learn to use the tools, to transfer their paper designs to the tools, and finally to transfer the results into an implementation. Thus, by using the notation developed here as the foundation for the methodologies autom ated tools, we achieve an economy of scale. As the notation is used to describe more systems, and as the graphical interfaces for the support tools are developed, it is anticipated that new symbols will be added to extend its expressiveness. In addition, a complete set of syntax rules will be needed both to aid designers in mechanically checking the well-formedness of their designs, and also as the basis for an autom ated syntax checker. In the following sections we present the basic symbols for representing the inter connection of autonomous regions: boundaries, spanners and illustrations. B o u n d a ries Boundaries are the graphical representation of autonomous regions. A boundary is drawn around the entities belonging to the AR and labeled with the name of the AR. The entities that we model within the boundary for purposes of reasoning about navigation include hosts, the services the AR provides to its hosts (e.g. usage policy route synthesis) and services the AR offers to the rest of the system (e.g. email routers). Examples of operations include routers, mail relays, and transmission facilities. AR elements are represented as labeled circles contained in a boundary symbol. AR NASA 13 + + + + iHost A I + + + + I Host B| + + + + A boundary may represent multiple, i.e., non-uniform, levels of policy. For example, the policies governing host mail privileges, transit routing services, and inter-AR authentication services can all be represented in a single boundary. There are some basic rules for using boundaries. 1. Boundaries may not overlap since they represent autonomous regions; points of interdependence are represented by spanners as discussed below. Thus boundaries form a flat representation of interconnected autonomous regions. 2. No symbol may overlap a boundary; all other symbols m ust either be distinct (such as other boundaries), completely contained within a boundary, or con nected to the outside of the boundary. This reflects the fact that boundaries represent areas of autonomy. If, in real life, a resource is jointly controlled by two independent agencies, a boundary representing the joint policy controlling th at resource would be drawn. 3. AR elements m ust be contained in a boundary. S p an n ers Spanners represent an interdependence, usually a ”communication agreement” , be tween directly-connected neighbor ARs. Each spanner is, therefore, a combination of two m utually complementing policies issued by two adjacent ARs. Note th at while each boundary may represent multiple policy levels, represented by multiple spanners, any single spanner represents policy at a single level of abstraction. For 14 example, a spanner may represent either a packet switching policy or an email policy, but not both. Thus spanners have an implicit ’ ’type” which has two components: the policy class of the communication agreement represented by the spanner, and the level of communication. A route is represented by a ’ ’spanner chain.” A spanner chain is a sequence of spanners th at constitute a path from a source to a destination. A legal spanner chain forms a ’ ’consistent” policy for the entire chain, and hence does not violate any of the spanned boundaries’ policies, at a single level. Alternatively we say th at for a spanner chain to be valid, all the spanners must be of the same type. The graphical notation for a spanner is a unidirectional arrow. Only directly connected boundaries will have spanners between them . Two-way spanners repre sent bi-directional communication policies and are drawn as double-headed arrows. Spanners may be annotated with an expression of the policy agreement. AR NASA AR USC + + + + 1 +------------+ I iHost A I | +------------+ | +----------+ 1 IHost B| 1 1 1 1 | <-------- 1 1 1 --------> | +------------+ | I pollux) I +------------+ 1 +--------------- + 1 | +----------- h 1 1 +------------------------------ 1 1 1 --------+ 1 1 1 1 1 e c la I I +----------------+ | + + There are some basic rules for placing spanners. 1. A spanner always connects exactly two ARs. 2. A spanner may not cross a boundary. 3. Spanners may only connect boundaries; they may not connect elements inside a boundary, and they may not connect other spanners. 4. Spanners may be labeled with an identifier. 15 5. Spanners may be annotated with a well-formed policy statem ents, as discssed below. 6. There may be multiple spanners between a pair of ARs. A n n o ta tio n s Initially, annotations consist of labels to uniquely identify spanners, boundaries, and boundary elements, and policy expressions. Labels are the usual alpha-numeric character strings. There are many ways to express usage and security policies; from natural languages, to first order logic, to special purpose languages. Because we wish to provide autom ated support for the design process and tools to support reasoning about designs, we require that policy statem ents be expressed in either sentential logic, first order logic, or a policy expression language, for example, we use C lark’s policy expression language for representing usage policies. There are some basic rules for using annotations. 1. Policy expressions may be labeled. 2. AR labels must begin with the characters ’’AR’ ’. 3. Labels m ust be unique. 4. Policy expressions must be well-formed statem ents in a valid policy expression language of first order logic. Illu str a tio n s An annotated set of boundaries, boundary elements, and spanners forms a represen tation of a specific topology of interconnected autonomous regions. We call such a representation an illustration. An illustration is well- formed if all boundaries, span ners and boundary elements are labeled; if all policy representations are expressed in an acceptable representation language; and if none of the rules for boundaries, spanners, or annotations are violated. 16 C h ap ter 4 D escrib in g P ro p erties o f IA R s It is widely recognized th at formal tools are needed not only to provide assurance of functional correctness, but also to provide a high level of assurance that policies, such as security and integrity, are properly enforced. As a result, a number of lan guages, e.g., [SH89, Goown, Unkwn] have been developed for formally specifying and proving th at desired properties hold of programs and systems. In addition, de velopers of the languages have also built an assortment of autom ated tools to aid the specification and verification process. However, the interconnection of autonomous regions is a new application for formal methods. Issues of evolution, autonomy and interdependence have not been significant factors in the systems addressed by formal m ethods to date. These characteristics, we believe, do impact the requirem ents for a formal design methodology. In addition, not only are we addressing systems whose characteristics differ fundamentally from the assumptions of most existing models, we also want to extend the traditional roles of formal design languages and tools to provide support for a wide variety of design aids from executable specifications to ’ ’navigation” tools. In this chapter, we examine properties th at a formal language must express and present the approach we have taken to formally describing properties of inter connected autonomous systems. In particular, we have found th at a ”tw o-tiered” approach to specifying the abstract operations is well suited to the class of systems at hand for several reasons. We have found it particularly useful to m aintain a separation of the specification concerns relating to the underlying data structures and the im plem entation specific system behaviors. We take the Larch approach of specifying abstract data types algebraically, and behaviors operationally. In Larch, 17 however, behaviors are specified axiomatically, which supports non-uniform imple m entations but not executable specifications. We have chosen instead to specify program behaviors with a Horn clause logic based notation. This approach allows us to support heterogeneous implementations, execution of behavior specifications, and the generation of system design tools with a formal basis. 4.1 A lgeb raic S p ecification In this section, only a brief overview of the fundamentals of algebraic specifications are introduced; the interested reader is referred to [GHW85] and [EM85] for more details. Specifications generally abstract away from im plem entation details to ease the considerable burden of reasoning about desired properties, and to enhance generality. A commonly used abstraction is to view programs as a finite set of operations on a collection of values. This view of programs corresponds with the construct referred to as a data type: a collection of d ata objects and operations on those objects. The abstraction of programs viewed as data types is referred to as abstract data types, or ADTs. A bstract data types are independent of specific values and represent classes of data types, thus providing the structure for program specifications. We wish to extend this view to interconnected autonomous regions. The problem is that interconnected autonomous regions evolve over tim e. How ever, at any given instance in time, the system is composed of a finite set of resources and a finite collection of operations on those resources. Furtherm ore, while we are interested in supporting evolution from the perspective of understanding the impact of evolution on the system, rather than on actually modeling the process of evolu tion, in general we wish to support the design and im plem entation of an instance of this class of systems. In other words, evolution is not a part of the operations of these systems, rather it is a characteristic of their environment, or life cycle. (We are building systems th at may change overtime, not building systems th at change as a part of their operational requirements.) Thus it is natural, we claim, to extend the model of programs as data types to a system modeled as a collection of data types. 18 The goal of a formal specification language or notation is to be able to determine when programs are ’ ’good”; th at is, when they are sound (no erroneous behavior), complete (provide outputs for all expected inputs), and composible (when can two programs be joined into one correct program). Algebras have a first order theory and, when properly constructed, are sound, complete and composible. When alge bras are expressed in terms of operations over sorts and equations th at define the behavior of the operations, they provide a semantics well-suited to abstract data types. Thus in the algebraic sem antics/abstract data type specification paradigm we have algebras as semantics of abstract data types specifications of programs modeled as d ata types. We have stated that we wish to unify algebraic semantics with Horn clause logic semantics. To achieve this we must address several issues: how can a theory se mantics be unified with a model semantics, such as we have for horn clauses; how can algebraic semantics be extended to express properties of polymorphic abstract data type specifications (these are needed to support specification m odularity and composability); how can algebraic theories be extended (e.g. to allow greater power in distinguishing between ground terms) and how can algebraic semantics for poly morphic specifications be integrated with Horn Clause least model semantics. There are several approaches to these issues with varying trade-offs in complexity, express- ibility, and ease of use. A classical algebra consists of a base set of symbols, one or more operations on th at set of symbols, and (possibly) some properties of those operations. For the purpose of providing semantics for A bstract D ata Type Specifications (ADTS), algebras are represented in a slightly different notation. Instead of a single base set of symbols, we have a set S of symbol sets referred to as sorts; a set of operations OP; and a set of equations EQ that describe the properties of the operations. The sorts are the domains and ranges of the operations. All operations (functions) must be total and the equations are implicitly universally quantified. The pair (S,OP) is referred to as the signature of an algebra A. The semantics provided by algebras is a theory (a closed set of well formed formulas, or wffs) rather than a model. The theory is generated by the equations which describe the properties of the operations over the ’ ’sorts” (sets) of the algebra. 19 An algebra is said to be complete when it contains enough equations to derive all the equations th at are valid for th at algebra. Theories contain ’ ’ground expressions.” A ground expression is defined to be either a constant or a function whose term s are all constants. An algebra is typical for a class of algebras when the ground expressions (terms) th at are in th a t algebra’s theory are just those ground terms that are true in theory of every algebra in the class. It is more common to use the ’ ’initial algebra,” however, as the model for an ADT specification. All initial algebras have the property th at they are typical. Further, in initial model semantics, the composition of two theories cannot result in a theory th at contains wffs th at are not in either of the composed theories on their own. However, for param eterized abstract data type specifications (as they are con structed in Ehrig and M ahr) there is no initial algebra. The formal param eter of the param eterized data type has no operators and only one distinguished constant. Thus the set of ground terms is trivial and no meaningful initial algebra can be constructed for the class of algebras denoted by the param eterized specification. There are several approaches to constructing a semantics for param eterized spec ifications. Ehrig and M ahr chose the initial functor as the semantics for the param eterized specification. A functor maps classes of algebras onto classes of algebras. W ith this approach, a specification is valid if the theory of the specification is valid in every algebra in the class. The advantage of loose semantics is th at it supports monotonicity. T hat is, of specifications are carefully composed so th at the resulting specification removes nothing from the theories of the composed specifications, then m onotonicity is preserved. A potential advantage of loose semantics is th at the specifier can compose specifications whose composition results in a larger theory than the simple union of the two theories. It is not yet clear what the advantage is over initial semantics for unparam eterized specifications. However, the loose semantics approach appears to be a bit more accessible that appealing to category theory and functors on classes of algebras. For this reason, we will assume a loose semantics for param eterized types with unactualized, formal param eters. W hen a param eterized specification is actualized, and the resulting specification is a conservative extension (i.e. the inclusion of the actual param eter type in the 20 param eterized type does not add any new wffs to the theory of the actual param eter type) then we can construct an initial algebra of the composed specification, (this is the hope, will need to prove it.) 4.2 H orn C lau se S p ecification o f B eh a v io rs In this section, we briefly introduce the fundamentals of Horn Clause logic. The reader is referred to [Llo84] more details. Larch and its role in our design notation is discussed. Several simple processes are specified. We begin by reviewing the basic terminology and definitions of Horn Clause logic (HCL). Horn clauses are defined over a standard alphabet consisting of variables, constants, functions, predicates, connectives, quantifiers, and punctuation symbols. Terms are defined inductively as the set of all variables and term s plus, for any function f and term s ti, the function f(tl,t2 ,...,tn ). Terms th at are composed entirely of constants or functions and constants is referred to as a ’ ’ground term .” Atoms and well formed formulae are defined in the usual way in term s of predicate symbols and the logical connectives. A literal is defined to be an atom or the negation of an atom. Since we are interested in the operational semantics of HCL, we will be con sidering Horn clauses of a special form called program clauses: A j- B l,B 2,...B n where A and Bi are literals. The Bi constitute the body of the program and A is referred to as the head. The program clause is equivalent to: (forall xl,x2,...,xm (A (xl,x2,...,xm ) j- BI and B2 and ... and Bn). Informally, this statem ent says that for every substitution of ground terms for the variables occurring the body, if the Bi are all true, then A is true. This is the basis for resolution, and will be our only operational rule of inference. The unit clause (A j- ) asserts th at for every substi tution of ground term s for the variables of A, A is true. The clause (j- B l,...,B n) is called a goal clause. A Horn clause, then is defined to be either a program or a goal clause. R estricting our specifications to the special Horn clause form provides a simpler semantics with no effective loss of expressibility. In standard first order logic (FOL) to show th at a statem ent (or a set of statem ents) S is valid only in the case that every interpretation of is a model of S. The im pact of this is the following. We do not want 21 program statem ents (specifications) that are correct (true) sometimes and incorrect (false) other times. To prove that a program (specification) is always correct (true), we must show that all the statements are true for every possible interpretation of the statem ents (equivalently the program always runs correctly for every expected set of inputs). For example, consider the statement (p(x) V q(y)). This has three models, one where p holds and not q, one where q holds and not p and one where both p and q hold. Thus sometimes p (or q) is true and other times not. However, The restricted form of our specification allows ”Least Herbrand Interpretations” or least models. T hat is, to determine if a set of statements is valid, one need consider only a single interpretation of the statem ents, the least Herbrand. Least Herbrand models contain exactly that set of ground terms that are found in every model of the set of clauses. Since Horn clause logic is equivalent to first-order logic, there is no effective loss of expressibility, though there is undeniably a loss of ease of expression. As already mentioned, when an algebra is typical for a class of algebras, then those ground expressions (terms) that are in that algebra’s theory are just those ground terms that are true in theory of every algebra in the class. Thus the theory of the typical algebra in a class can be used as the least model semantics for an abstract data type specification (a program specification) expressed in horn clause form. Recall that the semantics of any set of wffs written in Horn Clause form has as its model just those ground terms that are true in every model of the wffs. This is the least model. 4.3 Larch Because Larch provides part of the basis for our language, we provide a very ab breviated overview here. The reader is encouraged to see the references for more details on Larch. Larch takes a ”two-tiered” approach to specifying programs based on the sep aration of the state-independent and the state-dependent properties of a program or system. State- independent properties are defined in the bottom tier. Since the properties of the data structures upon which a program operates are independent of the current state of the program, these properties (called ’ ’traits”) are written 22 in a language that is common to all programming languages (i.e. a ’ ’universal” specification language) called the Larch Shared Language (LSL). The LSL is an algebraic specification language and defines the equivalence of term s appearing in the interface specification language. The use of traits provides modest support for non-uniform specifications granularity. The creators of Larch used the loose semantics approach. The Larch creators choose this approach because loose semantics supports monotonicity. We now illustrate a spanner ’ ’tra it” in our Larch based language. We have chosen the queue as a simple data abstraction for message passing. Note th at we have modified the syntax slightly. In particular, we explicitly param eterize the data type specifications to emphasize the need to supply actuals in a final specification. Spanner(data) O perations empty: -> spanner i n s e r t : spanner d a ta -> spanner head: spanner -> d ata t a i l : spanner -> spanner isempty: spanner -> boolean IsInSpanner: spanner d a ta -> boolean Equations d , d l : d ata; s , s l , s 2 : spanner; h e a d (in s e rt(e m p ty ),d )) = d; h e a d ( i n s e r t ( s ,d ) ) = i f isem pty(s) then d e ls e h e a d (s ); t a i l ( i n s e r t ( s , d ) ) = i f isem pty(s) then empty e ls e i n s e r t ( t a i l ( s ) , d ) ); isempty(empty) = tr u e ; is e m p ty ( in s e r t( s ,d ) ) = f a l s e ; isInSpanner(em pty, d) = f a l s e ; is I n S p a n n e r ( in s e r t ( s ,d ) ,d l ) = i f (d=dl) then tr u e e ls e is In S p a n n e r(s ,d l) A ’’family” of specification languages is used to specify the state-dependent prop erties of a program in the top tier of Larch. As the authors note, how a program interacts with its environment is closely tied to the kinds of constructs in its imple m entation language. Thus, a specification language that reflects the constructs of 23 the im plem entation language produces specifications th at are more concise, easier to use and clearer to implementers and readers alike than specifications w ritten in some ’ ’universal” specification language. Thus, the Larch Interface Language (LIL) is actually a collection of axiomatic specification languages th at are modeled on their respective implementation languages. This family of interface languages is a nice solution to supporting technological heterogeneity. There are two things th at Larch does not, unfortunately, do well for us: the first is support simulation and the second is the represent a system ’s structural in formation. As already mentioned, Horn clause logic naturally supports executable specifications. However, Larch must be modified slightly in order to support a Horn Clause Logic based interface language. In particular, Larch does not require initial models for its Shared Language specifications. However, if the Shared Language specifications are to define term equivalence for HCL specifications, they must have an initial model. (Note, an initial model of an algebraic specification is also ’’typ ical,” th at is it contains exactly those term s th at are found on all models of the specification. This is just what we need for a least model of a HCL specification.) Fortunately, modifying Larch to satisfy initial (or least) model semantics is not too difficult; we treat parameterized specifications as formals until all formal param eters are replaced with actuals param eters. At th at point we can take initial model semantics of the data type specifications (the traits) and construct the least model. 4.4 S ta te-D ep en d en t B eh avior Since the spanners represent state objects, the operations on those state objects are state changes or behaviors. In keeping with our Larch approach, state dependent behaviors are specified in the Horn Clause notation. Behavior specifications describe relations between ground terms. These relations can be thought of (loosely) as describing pre- and post-states of observable transitions. In a sequential program the states between a procedure invocation and its return are not externally visible (i.e. are not visible to the calling process). Thus the external specification of a procedure is ju st a relation (predicate) on initial and final states of the procedure. The procedure may execute several internal atomic actions in order to achieve its 24 final states. Because the external view is of only a single transition, we refer to the definition of a process as an action. In the specification of a relation between initial and final values of state variables, initial values are annotated with ’ (read as ”in”) and final values are annotated with ‘ (read as ’ ’out”). Procedure param eters are moded accordingly as ”in” , ’ ’out” or ”in out”. In transitions th at update a process state variable, the state variable must be annotated to m aintain consistency with the single-assignment semantics of the specification language. The ’ ’out” instance of a state variable is treated as a new variable distinct from the in instance of the variable. In the next transition, the out value of the state variable becomes the in value. Because of these constraints, proce dure param eters are logical variables and may be treated functionally. A procedure’s local variables are treated similarly. We do not currently provide for expression of timing properties in our model, but anticipate th at it would not be too difficult to incorporate tim ing constraints, and plan to do so in the future. D urra [?, ?] extends Larch with Real-tim e Logic (RTL) [?] and gains the ability to express and reason about system tim ing properties. We now present the graphical representation between two communicating ARs, A and B. The spanners are annotated with each ARs usage policy, expressed as Clark’s policy terms. The top spanner states that AR B will accept both messages originating in A and those transiting through A that are destined for any hosts in B. B will not provide any transit service, and there are no other conditions specified. The bottom spanner indicates th at AR A will accept any message from B (or from any other region attached to B) destined for A, as long as the message is for research or support. A will also provide transit service for research and support. There are no global conditions specified. 25 Boundary A Boundary B (* ,* ,* ) (* ,B ,-){}{> > spanner_ab(msg_unit) email email r e la y (* ,* ,* ) (* ,* ,* ) re la y { r e s e a r c h , support} <-------------------------------------------- spanner_ba(msg_unit) t r a i t msg_unit rename is _ p a i r as msg_unit w ith p olicy_term f o r d a t a l , msg f o r data2 t r a i t p a irC d a ta l,d a ta 2 ) S o rts d a t a l , d ata2 , p a i r O perations d a ta l data2 -> p a ir; f i r s t : p a i r -> d a t a l; second: p a i r -> data2; s e t . f i r s t : d a t a l p a i r -> p a i r s e t.s e c o n d : data2 p a i r -> p a i r Equations d l , d l ’ : d a t a l ; d 2 ,d 2 ’ : data2; p: p a i r ; f ir s t< d l,d 2 > = d l; second<dl,d2> = d2; s e t _ f i r s t ( d l ', < d l , d 2 > ) = <dl,d2>; 26 t r a i t msg rename s t r i n g as msg --w hat about length? t r a i t policy_term s o r t s policy_term rename 4 _ tu p le as p o lic y term w ith src_term f o r e l e l , d st_term f o r e l e l , condl f o r e le 3 , cond2 f o r ele4 s r c .te r m , dst_term are t r i p l e s condl, cond2 are l i s t s of s tr in g s We now present a specification of the appropriate enqueue and dequeue operations th a t each boundary may apply to the connecting spanner. Boundary_A == o p e ra tio n s en d (in out spanner: spanner_ab; in m: m sg _ u n it); o p e ra tio n r e c e iv e f in out spanner: spanner_ba; out m: msg_unit, s: s t r i n g ) ; body == s en d (in out spanner: spanner_ab; in m: msg_unit) :- [| sp a n n e r' = in s e rt(s p a n n e r,m s g _ u n it)I] r e c e iv e ( in out spanner: spanner_ba; out m: msg_unit) :- [I i f isem pty(spanner) then m = n i l ; s t a t u s = "no_msgs"; e ls e e = h e a d (s p a n n e r); spanner' = t a i l ( s p a n n e r ) ; s t a t u s = "message" f i 1 ] end Boundary_A Boundary B is specified similarly. 27 C h ap ter 5 T h e M eth o d o lo g y This chapter presents the integration of the model, design notation, and tools we have developed into a methodology for developing interconnecting autonomous re gions. The methodology is driven by the characteristics of the class of systems and the needs of the designer. At the heart of achieving the interconnection of ARs is the identification and construction of mechanisms th at realize the dual goals of connec tivity and isolation. To achieve these goals, a good design m ust include, at least, a description of the architecture, the policies governing the system, and a description of the functional components of the system, i.e. the mechanisms to be implemented to achieve the interconnection of the ARs. Next, the designer m ust be able to an alyze the requirements. W ithin our context of connectivity, this implies th at the designer m ust be able to analyze the integration of topology and interconnection policy, and its im pact on both connectivity and isolation. The design of mechanisms must satisfy the topology and connectivity require ments, and must also provide assurance of functionally correctness. Thus, functional component designs need be stated in a formal notation to facilitate proofs of correct ness and to support autom ated im plem entation generation. Assurance of security and integrity of the mechanisms is also im portant. After functional correctness, it is also im portant to dem onstrate that the mechanisms work as anticipated within the context of a specific topology and set of policies. Finally, support is needed to achieve correct implementations of the designs. The designer m ust have tools available th at aid the analysis of the im pact of requirements on systems goals such as connectivity and autonomy. Tools such as theorem provers are needed to support proof of functional correctness, and to aid in the implementation generation process. 28 Given the preceding discussion, the goals of the methodology are to provide the designer with, first, a framework for expressing requirements: a model of the class of systems, a notation for expressing elements of the model, and a notation for expressing connectivity and isolation policies. Second, tools are provided for analyzing the integration of a topology and a set of policies. In particular, a ’ ’nav igation” tool has been prototyped, and other tools are planned. Third, there is a family of tools for formally specifying mechanisms. These include a formal design notation, as described in chapter 4, and planned support tools such as a syntax checker and theorem prover. Fourth, the methodology supports ”proof-of-concept” of designs expressed in the formal notation since the design notation is ’ ’executable.” Finally, the foundations for formal verification of im plem entations and autom ated code generation are present in the methodology. This is the framework, then, for the integration of the specialized model, notation, and tools into a comprehensive methodology. The remainder of this chapter provide a general discussion of the methodology. Chapters 6, 7, and 8 each discuss a major facet of the methodology (analysis, specification, and simulation) in detail. 5.1 A p p lica tio n s o f th e M eth o d o lo g y There are three related applications of the methodology to the development of in terconnected autonomous regions. These are: the initial development of a new system of interconnected autonomous regions; the partitioning of a ’ ’flat” system into an interconnection of autonomous regions; and support of the maintenance and evolution of an existing system of interconnected autonomous regions. These applications correspond to different circumstances under which interconnected ARs are derived. First, the interconnection of autonomous regions can occur when there is a need to achieve connectivity between existing autonomous regions th at may not be connected, or that may have insufficient, suboptimal connectivity. We refer to interconnected autonomous regions derived by interconnecting existing ARs as ’ ’constructed.” The existing adm inistrations have policies th at they m ust enforce if connectivity is to be perm itted. The methodology and tools are used to design mechanisms, such as policy routing protocols and charging mechanisms, to provide the policy support required to achieve connectivity. Tools are also used to analyze 29 the effects of local polices on global connectivity, and to aid in the m aintenance and evolution of the system. Second, the interconnection of autonomous regions may arise in response to the need to restructure an unwieldy, inefficient flat system. The systems resulting from restructuring are referred to as "reconfigured” interconnected autonomous regions. In this case, there is an existing, flat structure, i.e., a single, global adm inistration governing all the resources, th at has become too unwieldy. The system is partitioned into interconnected autonomous regions to facilitate the managem ent of network resources and to improve the overall performance of the system. The decision is made to define regions th at can be adm inistered autonomously, define policies for those regions, then define and develop the necessary mechanisms to achieve the new system structure. Again, the methodology and tools are used to express the reconfigured system, design the necessary mechanisms, and analyze the characteristics of the system. There is, theoretically, the possibility of a third class of interconnected au tonomous regions th at arise ’ ’from the ground up.” T hat is, the case where there are effectively no pre- existing regions or resources, and the system is constructed from scratch. However, we feel th at this will probably never happen in the real world, and so will not consider this case further. To support the interconnection of existing ARs, the methodology should en compass and support a num ber of activities. As already mentioned, the study of connectivity issues and analysis of topology will be essential in concert with the de sign of NW mechanisms. The former requires the use of analysis tools, and the latter necessitates a formal design notation and associated tools. There is also a need to study the functionality of a NW mechanisms within the context of the proposed topology. To perform these tasks, there must be mechanisms for expressing and analyzing policies that effect connectivity. Finally, an integrated ’ ’start to finish” development environm ent th at incorporates the tools to accomplish the preceding tasks with docum entation generation and management, system status modeling, and an integrated user interface. Partitioning an existing system into an interconnection of autonomous regions places many of the same requirements on the methodology as above, plus a few more. Before imposing a new architecture on an existing system, the effects and 30 trade-offs of supporting autonomy should be studied, and hence the methodology should provide support for this activity. As with connecting existing ARs, there will be a need to develop new mechanisms for connectivity and a need to analyze the effect of diverse policies on connectivity. Finally, to support the engineering process required when a system of intercon nected autonomous regions evolves requires support for analyzing and managing updates to existing topology. In particular, a complete methodology will provide a model of the current status of the system, provide support for analyzing proposed changes to the system, and autom atically update docum entation when the system is modified. 5.2 O verview o f th e M eth o d o lo g y Our methodology is predicated on a few im portant underlying assumptions. First, policies m ust be expressed in some symbolic notation such as FOL or C lark’s nota tion in order to be able to support autom ated analysis of the im pact on connectivity. Then, given a notation, the policy expression language and accompanying rules must be incorporated into a ’ ’navigation” tool. The most fundam ental assumption is that the ’ ’system view” is at the level of ARs. While finer levels of granularity can be reasoned about, basic properties are expressed and reasoned about in term s of ARs and their inter-relationships. For example, access control properties are assumed to be expressed in terms of ARs and their hosts, and AR connections. Properties of hosts independent of ARs are easily expressed with existing methodologies and are not of interest in this arena. The methodology addresses the challenges presented above through its compo nents of analysis, specification and simulation. T hat is, analysis of requirements, specifications of mechanisms and proofs of correctness, and simulation of mecha nisms. The analysis m ethod and tools can be used in both the initial design of a system and in support of an in place system. The design notation is built on the foundations of formal specifications, as discussed in chapter 4. It has been dem onstrated elsewhere th at increased formalism in the design process decreases costly design errors. In an effort to integrate the design notation into the entire 31 development process, we have a design notation that is both ’ ’executable” and sup port synthesis into implementations. At the heart of all this is the AR model and graphical notation. Figure 5.1 shows the relationship of the components of the methodology to the m odel/notation and to each other. The model, in concert with the graphical notation, unifies the methodology. First, the graphical notation is the vehicle for expressing systems in the model. After the topology of a system is established, the graphical representation is annotated with each A R ’s connectivity control policies, and the resulting annotated illustration becomes input to analysis tools. Further, it is anticipated that the graphical notation will form the basis for the interface to the integrated, autom ated tool suite. Finally, a complete methodology will include autom ated, life-cycle m anagement tools such as autom ated docum entation generation (e.g. description of the current topology, guide to local policies, current logical connectivity). In particular, the tools for modeling the system state will express its results in the graphical notation. The typical flow of the methodology is depicted below. Particular applications of the methodology may of course, use only a subset of the steps, and may alter the order in which the steps are applied. 1. Construct model of system to be analyzed/built. 2. Express connectivity control policies. 3. Analyze connectivity. 4. Refine model and/or policies. 5. Design mechanisms. 6. Prove functional correctness of mechanisms. 7. Simulate mechanisms and revise as necessary. We discuss each of these steps in turn. C o n str u c t an In itia l T o p o lo g y Constructing a prelim inary topology provides a framework for expressing policy and a context for identifying the ’ ’system” operations and data structures. Note that 32 + ------------------------------------------------ + I DESIGN NOTATION I-form al s p e c if i c a t io n I-im plem entation I s y n th e s is I-sim u la tio n I-theorem proving + ------------------------------------------------ + sim ulate mechanisms in system context I POLICY REPRESENTATION! I -p o lic y model I I - n o ta tio n I I -ty p e of p o lic y I annotate i l l u s t r a t i o n + ---------------------------------------------------+ I AUTONOMOUS REGIONS I I MODEL I I(G raphical N otation) I I - i l l u s t r a t i o n manager I + ---------------------------------------------------+ execute t o o l s in context of system topology topology provides management framework I ANALYSIS TOOLS I I -N avigation I I -Network S tatu s! + + + + LIFE-CYCLE M ANAGEM ENT -c o n fig u ra tio n c o n tro l -document g e n era tio n -d a ta c o l le c t io n -system l i b r a r i e s 33 the initial definition of the topology does not need to be complete or precise; it is expected th at the system topology will evolve throughout the specification pro cess. Also, it is expected th at the system illustration will evolve to reflect changes in the im plem entation of the system. For example, the addition or deletion of au tonomous regions will be reflected in the illustration of the topology, as will changes in connectivity. E x p ress A R P o lic ie s This consists of several steps. The first step is to identify the type, or class, of connection control policy to be represented. While there are a several m ajor types of policies including security, integrity, and usage as well as hybrids, we will concern ourselves only with usage in this chapter. Next, select an appropriate model for the class of policies to be represented, and a convenient notation for expressing policies. As already mentioned, the notation needs to express policy properties in terms of our AR model. A model and notation are essential for unambiguous policy statem ent, and essential if autom ated tools are to be used in the design process. There are a num ber of policy models and languages available, e.g. the Bell and La Padulla model of security and the Biba model of integrity. We shall, throughout this dissertation concern ourselves only with usage policies, and shall relay on Clark’s model and notation. A policy expression notation must embody several key properties. A well-defined syntax is imperative. W ithout a well-defined syntax, it will be difficult to integrate the expressions of policy with the rest of the methodology. The notation must express properties in term s of the model, i.e. in term s of ARs and hosts. This is an underlying assumption of the methodology; without this requirem ent, the policy expressions will have no meaning within the context of the model. Finally, the notation must be rich enough to express key policy requirements, and yet not be overly complex. The final step is to express the policy and integrate it with the topology. Once the policies have been expressed and an initial system topology defined, the policies can be analyzed in the context of that topology. This p art of the process is discussed in the next section. 34 A n a ly z e T o p o lo g y and P o lic ies Ultimately, in the systems th at this methodology is designed to address, there will be a great diversity of usage policies that must be supported. The consequence is a complex web of policies and technologies th at must be ’ ’navigated” if communica tion is to occur. To navigate, we must be able to understand the global im pact of both local and remote policies. To this end, we have developed a prototype ” nav igator.” The navigator determines the logical connectivity of the system based on the topology (expressed in the graphical notation) annotated with each ARs usage policies. The navigator constructs a table of policy routes for each host in each AR in the topology. A policy route is simply a sequence of ARs th at form a path between source and destination ARs. By using the navigator, the designer can determ ine if the collection of policies produces the desired interdependence and isolation. If undesired connectivity is present, or desired paths have been inadvertently eliminated, the policies can be adjusted accordingly and new policy routes generated. Since it is difficult, if not impossible, to determ ine the global im pact of a single policy statem ent, much less a collection of sets of policy statem ents, the navigation tool is an indispensable com ponent of the analysis process. The concept of navigation, along with the navigator tool, is discussed in greater detail in C hapter 6. R efin e T o p o lo g y After establishing a topology and analyzing the proposed policies, it may be neces sary to modify the topology. Changes to the policies may necessitate changes to the proposed topology, for example the addition or deletion of AR connections. This, in turn, may necessitate changes to the policies to account for the change in physical connectivity. In addition, refinement of the policies and topology may result in the identification of ARs not considered in earlier versions. The topology design, policy expression, and connectivity analysis is an iterative process. However, to achieve an ’ ’im plem entation” of the system abstraction, the collection of mechanisms to be implemented in the context of the topology and policies, a system illustration must be fixed. 35 D e sig n in g and S p e cify in g M ech a n ism s The next step is to determ ine the types of mechanisms th at need to be developed in order to achieve the interconnection of the ARs. This will vary somewhat from system to system. For example, if every AR in the system is already using the same flavor of OSI protocol, then protocol mechanisms need only be extended; new protocols do not need to be built. Typically, the designer will be interested in constructing mechanisms to perform functions such as policy servers and policy gateways. The process for specifying a mechanism follows general principles for developing good formal specifications. Recall from chapter 4 th at the design notation supports separation of concerns with respect to underlying, shared d ata structures and external behaviors. Thus the first step is to identify the basic data structures. W here possible, the data structures are fully specified. Otherwise, stubs for the data structure specifications are defined. As the design description is filled out, additional data structures may be identified. Next, the behaviors are defined and specified. Basically this consists of defining the procedures within each AR. This is a cooperative effort with the refinement of data structure specifications and will be discussed in more detail in C hapter Seven. The last step is to complete the refinement of the specification of the data structures. P ro v in g D e sig n P r o p e r tie s Given the formal description of a mechanism, it is desirable to prove th at functional correctness and other properties, e.g., security or integrity, hold of that design. To do so in this methodology, the desired properties are stated in either general first order logic and then translated into the design notation, or stated directly in the formal notation. Then, the general rules of FOL are applied to verify that the property or properties hold of the specification. The details of proving properties in the methodology are examined further in Chapter Seven. 36 U sin g an In sta n tia tio n o f th e O p era tio n s Mechanisms specified with the formal design notation can be, with a modest amount of effort, executed within the context of an AR illustration annotated with a collec tion of connection control policies. Horn clause logic specifications are easily trans formed into Prolog, minus the data type specifications. (However, data structures can be represented syntactically, if desired.) A policy routing protocol is simulated within the context of an illustration in Chapter Eight. The goal is to autom ate the process of transforming the formal descriptions into Prolog so th a t a formal description of a mechanism and an illustration can be given directly to a simulator. 5.3 A p p ly in g th e M eth o d o lo g y to E x istin g A R s In this section, we discuss application of the methodology to the interconnection of existing ARs. We illustrate the steps with a contrived subset of the Research Internet. W hile we are not using actual elements of the Internet, the examples are representative of the concerns and elements of the real Internet. The Research Inter net (RI) is a collection of autonomous networks of several different categories. There are university nets, corporate networks, federal agencies, and regional consortiums th at all wish to interconnect. However, they have a diversity of goals and connection needs. Universities are fairly loose, typically, about the traffic they will carry for other regions, as long as that traffic is for research or support. Corporations are much more concerned with protecting their resources from abuse, and with protect ing proprietary information. Some federal agencies are willing to provide across the board services, while others are not. And, in general, regionals provide the greatest degree of across the board services. S te p 1: M o d e l th e S y ste m In our example, we have two federal agencies, A and C, one corporation R, a uni versity S, and a regional B. In general A will carry any traffic for another agency, and will carry support or research traffic for anybody else, where support traffic is loosely define to be any traffic concerned with either the support of the entire system of interconnected regions, or support of A ’s resources. Regional B will carry 37 traffic to and from A only if the traffic is for support or research (B is implementing this policy constraint at A ’s request). B will carry any kind of traffic for anyone else in the internet. Agency C carries no transit traffic at all and accepts incoming and outgoing mail only between itself and other agencies or regionals. In addition, C charges for all packets. Company R accepts any traffic th a t is not from another commercial net. The University S will accept all traffic via the regional B as long as th at traffic is for research or support. The first step is to identify the potential A dm inistrative Regions to be intercon nected. From the discussion of the RI above, these are clearly the Agencies A and C, the University S, Regional R, and Corporation C. The ARs and their proposed topology are shown below. 38 Agency A +------------- + Agency C + --------------- + - I + - (A1 or A2) < ----------------- and C l I(A1 o r A2) and (BI o r B2) Regional B C orporation R + + + + 1 1 1 1 1 1 1 1 (BI or B2) and I 1 1 1 1 1 1 1 + ------ 1 1 I | (RI or R2) | --------------------+ | | 1 1 1 1 l 1 1 1 1 I I 1 (BI or B2) and (SI o r S2) 1 I U n iv e rsity S +-------------------------------------+ S te p 2: E x p ress C o n n e c tiv ity C o n tro l P o lic ie s The next step is to evaluate the connectivity needs, i.e. determ ine the type or types of policies th at will govern connectivity, and express those needs formally, i.e. express the policies in a formal notation. In the case of the RI, the prim ary concern is with protection of valuable resources that they wish to share w ith other members of the Internet in a controlled way. Examples of shared resources include transit services, propagation of accounting and billing information, and rem ote login to local computers. Thus the Research Internet is prim arily concerned with the support of usage policies governing connections. Note th at while hosts and networks internal to a given AR may also have other concerns such as providing a level of com puter security to protect classified information, this is a local decision enforced by local controls and policies and therefore is not a concern of the Internet as a whole. By way of example, we will state a portion of the policy for Agency A in C lark’s notation. Agency A will carry traffic for any host in any Federal or Regional (F or Re) network (in our example, every AR is connected to at least a Federal or Regional net) talking to any other host in an AR connected to a F /R e via (transiting through) any F or Re AR, as long as the traffic is for research or Internet support. There is no authentication of packets, and no per packet charging. Using C lark’s policy term notation, this part of A ’s policy is expressed as: Ala: [(*,{F,R e,U ,Co},{F,Re}), (* ,{ F ,R e,U ,C o },{ F ,R e» , { re s e a rc h , su p p o rt}, {unauthenticated_U C I, no-per-packet-charge}] The final step is to annotate the topology with the policy. In Chapter 6 we have a complete statem ent of the policy statem ent for the example Research Internet. Each term is labeled for easy reference. For example, the statem ents for A are labeled A la, A lb, and so forth. The illustration is annotated with a simple sentential logic sentence expressing which policy statem ents control a given spanner (AR to AR connection). 40 S te p s 4 an d 5: A n a ly z e C o n n e c tiv ity and R efin e M o d e l and P o lic ie s W hile it would be feasible (though adm ittedly tedious) to analyze the logical connec tivity of our system, modify the topology and policies as necessary, then re-evaluate the resulting paths through the system, this process is best accomplished with the aid of the navigation tool. Thus, we will leave the development of this part of the process to Chapter 6, where the navigation simulator is discussed in detail. S te p s 5 and 6: D e sig n M ech a n ism s and P ro v e F u n ctio n a l C o rrectn ess W ithin the context of the system illustration, we can identify mechanisms required to achieve connectivity control based on usage policies. These mechanisms can then be defined as needed using the formal description notation (FDN). Since the goal of the RI is to support usage policies, and there are currently no mechanisms for making routing decisions based on usage policy information, the first step is to design functions to adm inister the connectivity control information, and to route packets based on th at information. Clark [Cla90] and Estrin et al [Est91] have presented such mechanisms; we will draw on their definitions for examples. Before continuing with the formal design example, we will present an overview of the formal design process. The goal of this process is to assert and show that certain properties hold of our interconnection of autonomous regions. Our ability to argue th at some property holds of the system depends on our ability to carry out the following steps. First, define the function that must enforce or exhibit the desired property in the formal notation. The description should include enough information to completely define the interface to that function. Second, prove that the function exhibits, enforces, or does not violate the stated property, as appro priate. Finally, each element of the system must implement the function such that the implementing mechanism verifiably satisfies the specified function, then all im plem entations, whether technologically diverse or not, will be equivalent. Then, by inductive argum ent, we can conclude th at the entire system exhibits the desired behavior. 41 We have taken this approach for several reasons. First, while we design the mechanisms within the framework of a given system model, these systems are not static. It would place an intolerable burden on system m aintenance if, each time the system changed, the proof that a given property held for the system had to be reproved for the entire system. It is much more efficient to labor within the framework th at all mechanisms implementing a particular function m ust satisfy a particular specification. This goal m andates th at the formal notation support technological heterogeneity, which our notation does do. Then, with each addition of a new element, the only verification required is th at the mechanisms of the new AR satisfy the designated specifications. Next we examine an excerpt from the secure policy route protocol. Recall that a policy route is a sequence of ARs that form a path from source to destination AR. C lark’s proposal assumes an architecture of ARs, Policy Servers, and Policy Gateways. Policy Servers are responsible for distributing policy term s describing their ARs usage policy, and for generating policy route tables based on the policy terms they receive from other policy servers in the system. Policy gateways route packets based on the policy information associated with the packets; the function of the PG is to enforce policy. Estrin and Tsudik have considered mechanisms for securing the protocol. It is a version of their modification of the protocol to include preventative measures for securing the protocol that we consider in this dissertation. The complete protocol and its formal description are presented in Chapter Seven. In the next paragraphs we consider a small excerpt of the protocol specification to illustrate this portion of the design process. A key function of the protocol is the addition of policy route information to a policy gateway’s cache during route setup. For each subsequent packet received for the given connection, the PG will access its cache to determ ine if the packet satisfies the route information in the cache. If there is no route information for the connection, or if the packet does not satisfy the routing information in the cache, the PG is to drop the packet. Since the cached routing information is critical to the enforcement of the routing policies, the PG should add this information to its cache only if the information is ’ ’valid.” A valid route is one that does not violate the local A R’s policies. The function addPRtoCache is described in FDN as follows. I 42 proc addPRtoCache(in ARid: s t r i n g , key: in te g e r) —g e ts a PR from mailbox and adds PR to cache i f v a l id var handle: p a i r ; ECPJ, CPJ: l i s t ; [| receive(boxARid,ECPJ) decrypt(ECPJ,k e y ,CPJ) ~ i f valid(C PJ) then [ |getsource(C PJ,H src) ~ getD est(CPJ,H dst) ~ handle = <Hsrc,Hdst> updateCache(CacheARid,<handle,ECPJ>) I] I] • In C hapter 7 we will formally dem onstrate that this cache update function sat isfies, in conjunction with the rest of the protocol, the assertion th at there is no unauthorized use of valid policy routes. Chapter Seven contains the complete for mal description of the secure policy route protocol. In th at chapter we prove the most critical property, that there is no unauthorized use of valid policy routes, holds for the secure policy route protocol. In addition, the navigator has been formally specified, and th at description can be found in the appendix. The final step is to provide additional assurance by simulating the protocol within the context of the system illustration we have designed. S te p 7: M e ch a n ism S im u la tio n and A n a ly sis The last step is to identify and perform the required analysis, e.g. connectivity, rapid prototyping, penetration testing, performance modeling, of the mechanisms. The type of analysis desired will determine the tools needed to perform the analysis, e.g. simulation tools for performance modeling. The desired analysis of the secure protocol is performance modeling, which is not currently supported, and functional simulation. Functional simulation provides both proof of concept, e.g., the protocol works as expected, and an opportunity to perform penetration testing. To simulate the secure policy route protocol, we transform the formal descrip tion into Prolog, then execute the prolog program. The long term goal is to provide 43 autom ated, or hum an guided autom ation, transformations into prolog. The trans formed specification and an illustration would be inputs to a sim ulator. Thus a single mechanism could be dem onstrated in many different environments. T hat is beyond the current scope of this work, however. In Chapter 8, we present a prolog transform ation of the secure policy route protocol specification and dem onstrate its functionality with in the context of the Research Internet illustration. This completes our discussion of the methodology as it applies to the intercon nection of existing autonomous regions. The next section discusses the application of the methodology to the partitioning of an existing system into an interconnection of regions th at will function autonomously. 5.4 P a rtitio n in g a F lat S y stem The prim ary difference in the development of constructed and reconfigured systems is in the initial stages of development. In the first case, adm inistrations and regional boundaries are already defined, and adm inistrative policies are largely established. So the design process begins with developing the mechanisms to support the policies. In the second case, the development of a reconfigured interconnected autonomous network places a heavy emphasis on the definition of autonomous regions, and on the development of appropriate policies to achieve the desired connection controls. The process for partitioning an existing "flat” system is as follows. The first step is to identify a partitioning of the system into components and resources that can be adm inistered autonomously from the rest of the system. These components will become the ARs. The purpose and definition of each adm inistration should be well-defined. Finally, state policy(ies) each region must support (e.g. usage). Initially, policies are stated in English. The next step is to construct an illustration of the topology, then express the policies in an appropriate notation and annotate the illustration. At this point, application of the methodology to a reconfigured system is identical to the process for a constructed system. Supporting the inevitable evolution of interconnected autonomous regions is an im portant application of the methodology and it is desirable th at the methodology apply to systems th at are not developed with this methodology as well as to those th at are. This is the case. However, when applying the methodology to systems that 44 are developed with other methods, there is a small penalty to be paid in set-up. The policies m ust be stated in a notation th at expresses properties in term s of our model (per the underlying assumption of the methodology), and an initial illustration of the topology must be developed. The process for m aintaining an interconnection of autonomous regions parallels the processes for constructed and reconfigured systems in the obvious ways. 5.5 C h ap ter Sum m ary The desire is to provide a full life-cycle environment for developing, m aintaining and evolving interconnected systems. Our guiding principles are th at the methodology should apply equally well to both building systems of interconnected autonomous regions and m aintaining them. Further, we believe th at formal methods should not only be incorporated and supported in the design and development process, but should also provide the basis for developing the methodology support tools. We feel that we have achieved these goals in a methodology th at not only is flexible and adaptable, but also provides the additional assurance th at each tool in the methodology has undergone a formal design process. The methodology provides flexibility by perm itting the designer to use any com bination of the supporting components (e.g. formal notation, analysis tools, models) and to use components in any order. For example, the designer may choose to first specify desired functions in the formal design notation, then define policies and topology. Alternatively, the methodology may be used to develop mechanisms inde pendent of any particular architecture, or the methodology may be used to express and analyze policies and topology only. The analysis tools may be used after initial design as needs change, as the system grows and changes to explore system design alternatives (e.g. change the topology and autom atically determ ine the effect on connectivity or mechanisms; change pol- icy(ies) and autom atically determine the effect on connectivity and mechanisms). A daptability is achieved by not precluding the integration of arbitrary types of policies and their models. The goal is to support arbitrary policy models and types of policies and to facilitate the addition of new support tools such as simulators 45 and im plem entation synthesizers, and theorem provers. In addition, the m ethodol ogy follows m odular design principles. The m ajor components of the methodology correspond to the prim ary steps in the design process: the topology/illustration component, the policy definition component, the formal notation FDN, and the mechanism analysis tools. 46 C h ap ter 6 N a v ig a tio n Because both the physical topologies created by interconnecting autonomous net works and the policies governing the connectivity between ARs has exploded in complexity, simple inspection is no longer adequate for determ ining if the interac tions of the local and remote policies supply the desired connectivity. This mesh of policies and technologies must be ” navigated” during each phase of the internet life-cycle from design and development, to operation, to m aintenance and evolution. Navigation is the understanding of the global im pact of local policy, and the in teraction of local and remote policies. During design and development navigation provides assurance th at the desired connectivity control has been achieved by the interactions of the asserted policies. Throughout system operation, policies must be accurately taken into account if communication is to take place with a minim um of disruption. Even once the internet is operational, systems will continue to modify their connectivity requirements; thus the ability to navigate is param ount to both achieving and m aintaining the ability to communicate. Finally, as new adm inistra tions enter the system and/or existing systems leave, navigation will be needed to both provide assurance th at the new policies do not introduce unwanted paths or preclude desired connections, and also to m aintain each AR’s ability to find valid connections. Thus, analysis tools to aid our understanding of system connectiv ity, and provide rigorous assurance th at the interactions of the policies express our intentions, are critical to achieving the interconnection of autonomous regions. Unfortunately, local policies often affect more than just the local resources they are designed to control; local policies often have global implications. For example, network paths are often computed by the m etric of shortest delay. However, a 47 node may have a small published delay, yet is only willing to carry traffic on a non-interference basis. Thus, the node is entered into many best paths though it usually dumps the packets. This results in poor quality of service to the end users of paths routed through this node. Local policies can have the unforeseen im pact of precluding desired communication or not providing sufficient controls over valuable resources. They may also place undue burden on internal users. In this section we discuss issues of ’ ’boundary placem ent” , our term for policy design, and connectivity in the context of our model. We then present a tool for analyzing the im pact of local policies on connectivity and apply the tool to a rep resentation of the research internet; this navigation tool works hand in hand with boundary design. 6.1 O verview We refer to the process of policy design as boundary design and placement. This is because policy places logical boundaries around users and resource, independent of physical location or topology. Boundary design is an im portant example of the need to balance autonomy and interdependence when interconnecting autonomous regions. Boundary design issues focus on placement, enforcement and navigation, and representation. In addition to defining and enforcing the boundary th at sur rounds a set of resources, autonomous regions must carefully specify their points of interconnection. As mentioned in Chapter 2, spanners depict points of interoper ability between ARs. In particular, a spanner represents the "intersection” of the policies of adjacent ARs. Boundary design and placement plays an im portant role in both classes of inter connected systems. In reconfigured systems, boundary design and placement serves to distribute the management role and elim inate bottlenecks, while in constructed systems boundaries interconnect existing systems. Poorly designed boundaries re sult in either unwarranted trust or in an overly restrictive system. While boundary placement is well-understood, though not always well-implemented, other areas of boundary design are less well-understood. In particular, research is needed in the areas of enforcement, navigation and representation. It is a goal of this section to address issues of representation and navigation. 48 The navigation issue is basically as follows. Given the complex web created by autonomously defined policy boundaries, how is navigation to be achieved? A first step in solving this problem is the development of a policy representation no tation th at can be easily used to represent arbitrary policies of a given type, e.g. security, usage, or reliability. Next, a m ethod for synthesizing sequences of span ners, or spanner chains, is needed. The navigation tool we have developed relies on Clark’s usage policy notation, and on the graphical representation of an AR topol ogy. Navigation must also address issues such as preservation of navigation data integrity, prevention of unauthorized access or modification of navigation data and the trade-off between assurance and performance. Other issues include determining the appropriate granularity at which to perform navigation. Expression of the topology of AR interconnections is an essential input to the navigation process, for it is only in the context of a given system th at the effect of the policies can be completely understood. Currently, interconnections of au tonomous networks are depicted by hand using the basic icons described in Chapter 2. The ARs and spanners are annotated with their corresponding identifiers and policy statem ents. After the topology is constructed, a textual representation of the illustration is used as the input to the navigation process (along with the represen tation of the policies). Derivation of the textual representation from the illustration is discussed later in this chapter. A useful extension of this work is the creation of an illustration manager tool. This tool would provide autom ated support for expressing AR topologies. W ith such a tool, the designer could create a topology using a combination of built-in icons and text. Predefined icons might include ARs, PGW s, Policy Servers, Hosts, and spanners. As in the current manual process, the illustration is annotated with identifiers and policy statem ents. To facilitate the annotation process, it would be useful if both text and icons could be labeled. Then the text associated with the labels could be ’ ’expanded” (displayed in the illustration) or collapsed (only the labels show) as needed. The illustration manager should support the user-definition of additional icons. Finally, the illustration manager would autom atically create the necessary inputs for the navigation process. It is anticipated th at existing graphical interfaces could easily be adapted to this purpose. 49 6.2 C lark ’s P o licy R ep resen ta tio n N o ta tio n All policies are represented using Clark’s Policy Terms (PTs). Each PT represents the portion of a given ARs policy. The policy term defines a set of logical routes, i.e., a sequence of ARs, between two sets of hosts. These sets of hosts can be thought of as a set of source hosts in the given AR and a set of destination hosts in an end AR. W hile it is conceivable th at in a very simple system, the entire policy of an AR could be represented in a single PT , in general an A R ’s policy will be represented by a collection of policy terms. While we will use these policy terms as a vehicle for performing navigation, they have other applications as well. For example, Policy Terms may also be used in policy routing protocols as the units of routing information exchanged by communication ARs. The syntax of a policy term is: [(Hsrc,ARsrc,ARent), (H dst,A Rdst, ARexit), UCI, Cg, Cbj. Hsrc, and Hdst refer to source and destination hosts respectively; ARsrc and ARdst refer to source and destination AR. ARent and ARexit name the directly connected AR from which a packet may be coming and to which it is going, respectively. Except for policies defined between AR neighbors, ARent and ARexit will not name explicit ARs, rather they will name sets of ARs through which the defining AR is willing to route its packets. In general, each AR or host designator represents a set of A.Rs or hosts that satisfy the policy. For example, if F represents the set of federal agency ARs in an interconnected system, and Re represents the set of regionais, then the set F,Re refers to all ARs th at are either federal agencies or regionals. In addition, we use some special symbols to facilitate policy expression: * is a wild card and matches any other expression. The symbol - indicates that no transit traffic is allowed when it appears in the ARent or the ARexit fields. In addition to expressing the acceptable ARs and hosts, the policy term also supports expression of complex conditions, or type of service, th at must be met. The UCI field is a user class identifier, and Cg represents a set of ’ ’global” conditions th at must be satisfied if a particular AR is to be part of a route. Global conditions include such things as tim e of day and billing arrangem ents. Cb represents bilateral conditions th at must be satisfied between a specified pair of ARs in the route. Bilateral conditions include agreements such as reciprocal arrangem ents to carry the 50 partn er’s traffic if the partner should experience failure, or agreements to exchange accounting information. 6.3 A R ep resen ta tio n o f a research in tern et In this section we consider the application of our navigation tool to an extension of the Research Internet (RI) example presented in C hapter 5. The extended RI example is composed of nine ARs: Federal Agencies A and C; Regional networks B, D and E; Universities S and T, and Corporations Q and R. The topology of the internet is as follows. 51 Agency A + + Agency C + 1 I h o st Ax | |m a il_ relay I 1 1 (A1 or A2) 1 1 1 Usr_svcs | 1 host Cx 1 1 1 and Cl 1 1 I Expt_svcs | 1 1 \ (A1 or A2) and (B1 or B2) \ Regional B C orporation R + + + + I host Bx |(B1 or B2) and I host Rx I (A1 or A2) and D1 Agency D1 + ------------------------------------- 4 host Dx i (RI o r R2) I host Ry I - 4 + -----------------------+ \(B1 or B2) and \( S I or S2) \ \ Univ S 4 ------------------------------------- + D1 and (SI or S2) host Sx Corp. Q 4-----------------------4 I h o st Qx I host Qy | I mailRelayI -------------- + 4 -----------------+ \ (Q1 or Q2) \(S1 or S2) I and El \ and El I \ I \ Regional E + + II II I host Tx I T1 and El I host Ex I \ D1 and T1 \ \ \ Univ T + + 52 Agency A is connected directly to Agency C and Regionals B and D; Regional B is directly connected to Corporation R and University S, as well as to Agency A. Corporation R is connected only to Regional B. S is connected to three regionals: B, D, and E, and university T is connected to two regionals: D and E. Like corporation R, Corporation Q is directly connected to a single regional, E. In the following policy term s, F, Re, U, and Co represent the classes of Federal, Regional, University, and Corporate ARs, respectively. Specifically, F = A,C, Re = B,D,E, U = S,T, and Co = R,Q. The spanners are annotated with expressions in term s of policy term labels, described here in both English and C lark’s notation. Note th at each policy term is actually a pair of terms a and b because communication is bi-directional and each direction may be subject to different requirements. If all policies are symmetrical, as suggested by Clark, then a single policy term could be interpreted as referring to both directions. For this example, we have selected symmetrical policies. Agency A will carry traffic for any host in an AR connected to any Federal or Regional (F,Re) network (in this case the set of hosts th at belong to any of the ARs in the set F, Re, U, Co) talking to any other host in and AR connected to either a federal or a regional via any federal or regional entry and exit AR, so long as the traffic is concerned with research or support. There is no authentication of the UCI and no per packet charging. There are no restrictions on bi-lateral agreements. The corresponding policy terms are: A l a : [ ( * , { F , R e , U f C o } , { F , R e » , ( * , { F , R e , U , C o } , { F , R e » , { re s e a rc h ,su p p o rt} , {unauthenticated_U CI, n o -per-pkt-charge}] A lb : [ 0 , { F , R e , U , C o } , { F , R e } ) , ( * , { F ,R e ,U ,C o > , { F , R e » , { re se a rc h ,su p p o rt} , {unauthenticated_UCI, n o -per-pkt-charge}] A second policy is th at A will carry traffic for user and expert services hosts in AR A to or from any AR connected to either a federal or regional AR. These special service hosts are the only systems th at directly connect to A (i.e. A ’s facilities serve mostly as a backbone network). The corresponding policy term s are: A 2 a : [ ( { U s r _ s v c , E x p t _ s v c } , { A } , { F , R e } ) , ( * , { F , R e , U , C o } , { F , R e } ) , {}, { } ] 53 A 2b: [ ( * , { F , R e , U , C o } , { F , R e } ) , ( { U s r _ s v c , E x p t _ s v c } , { A } , { F , R e } ) , {}, O] The regional consortium network B will forward traffic from or to any directly connected federal, regional, university or commercial network from or to A if and only if it is for research or support (as designated by the UCI. T hat is A requires that the Regional networks only pass to A traffic th at complies with A ’s own policies. The policy term s are: Bla: [(*,{F,Re,U ,Co},{F,Re,U,Co},(*,{F,Re,U ,Co},A ), { re s e a rc h , support}, {unauthenticated_U CI, no-per-pkt-charge}] Bib: [(*,{F,R e,U ,C o},A ), (*,{F,Re,U,Co},{F,Re,U,Co}), { re s e a rc h , support}, {unauthenticated_U C I, no-per-pkt-charge}] B will also pass traffic to or from directly connected university and commercial ARs independent of the designated UCI. The corresponding policy term s are: B2a: [0,Re,U,Co},{Re,U,Co}> , (*,{Re,U,Co},{Re,U,Co}) , {}, {unauthenticated_U CI,no-per-pkt-charge}] B2b: [(*,Re,U,Co},{Re,U,Co}>,(*,{Re,U,Co},{Re,U,Co}), {}, {unauthenticated_U CI, no-per-pkt-charge}] Agency C will not carry any transit traffic. It will only accept and send traffic to and from its mailserver and only from and to hosts in other federal or regional nets. In addition, it marks all incoming packets and charges per kilopacket. The corresponding policy terms are: Cla: [(m a ils e r v e r ,C ,F ) , (*,{F,R e},{F,R e}), {research, support}, {unauthenticated_U CI, incoming-pkts-marked, p e r-k ilo -p k t-c h a rg e } ] Clb: [{ * ,{F,R e},{F,R e}), (m a ils e rv e r,C ,F ), {research, support}, {unauthenticated_U CI, incoming-pkts-marked, p e r-k ilo -p k t-c h a rg e } ] 54 Company R will accept all traffic from or to any federal, regional of university AR via any directly connected federal and regional networks if the traffic is for research; it will not accept traffic from other commercial ARs. No transit traffic is accepted. The policy term s are: Rla: [0 ,{ F ,R e ,U } ,{F,Re,U}) , (*,R,R) , { research } , {}] Rib: [(*,R,R) , (* ,{F,Re,U},{F,Re,U}) , { re s e a rc h } ,{}] University S will carry traffic to or from itself from or to any destination via regionals B and E so long as the traffic is for research or support. S will also accept traffic routed through D (which charges for all traffic) as long as it is strictly for support activities and originates from or is destined for hosts in S. The policy terms for S are: S la : [ ( * ,S ,S ) , (* ,* ,{ B ,E } ), { re s e a r c h ,s u p p o rt} ,{}] S ib : [( * ,* ,{ B ,E } ) , ( * ,S ,S ) , { re s e a r c h ,s u p p o rt} ,{}] S 2 a: [ ( * ,S ,S ) ,( * ,* ,D ) , { su p p o rt} ,{} ] S 2b: [ ( * ,* ,D ), ( * ,S ,S ) , { su p p o rt} ,{}] Regional D will carry anything for anybody, to and from anywhere, but charges outrageous rates per kilo packet. D la: [ ( * , * , * ) , ( * , * , * ) ,{ } ,{ o u tra g e o u s -p e r-k ilo -p k t-c h a rg e } ] D lb : [ ( * , * , * ) , ( * , * , * ) , { } , { o u tra g e o u s -p e r-k ilo -p k t-c h a rg e } ] University T does a great deal of network research. T is also trying to make a name for itself in the network community. So, to generate both traffic for its experiments, and visibility, T will carry traffic for anybody, for any purpose, on a resource avail able basis. If T incurs charges from D for traffic it carries on another A R ’s behalf, the charges are based back to the originator of the traffic. The policy terms for T are: T la : [ ( * , * , * ) , ( * , * , * ) , { } , { re s o u rc e -a v a ila b le , D -ch arg es- r e f le c te d - b a c k - to - s r c } ] T ib: [ ( * , * , * ) , ( * , * , * ) , { } , { re s o u rc e -a v a ila b le , D -ch arg es- r e f le c te d - b a c k - to - s r c } ] 55 Regional E will carry all research and support traffic, at no charge. Ela: [ ( * , * , * ) , ( * , * , * ) , { re s e a rc h .su p p o rt} ,{ n o -p e r-p k t- charge}] Elb: [ ( * , * , * ) , ( * , * , * ) .{ re s e a rc h ,s u p p o rt} ,{ n o -p e r-p k t- charge}] Corporation Q will not carry any transit traffic. It will accept/send all mail to/from its hosts. It will also accept and send traffic through E only th at is either for research or support. The policy terms for Q are: qia: [ ( * , * , * ) , (m ail,Q ,Q ), {},{}] Qlb: [ ( m a il,q ,Q ) , ( * , * ,* ) , {}, {}] q2a: [ ( * , * , E ) , ( * , q , Q ) .{ re s e a rc h ,s u p p o rt} ,{}] q2b: [ ( * , Q , q ) , (* ,* ,E ).{ re s e a rc h ,s u p p o rt},{}] 6.4 T h e N a v ig a to r Currently, the navigator prototype supports usage policies expressed in C lark’s no tation. The designer generates a topology annotated with the usage policy terms (eventually using the illustration manager). The illustration currently is used only to determ ine the input to the navigator. The output of the navigator is a table of Policy route trees. The navigation algorithm generates the policy routes for all the hosts in a given AR to a list of destinations (usually expressed as A R /host pairs). The general algorithm computes all paths from source (ARsrc) to destination (ARdst) for each source and destination pair as follows. 1. Let ARcur be ARsrc. 2. Find all the neighbors of ARcur. Select as the potential ”next AR” in the path the next neighbor in the list of neighbors of ARcur. 3. Determine if the candidate next AR in the route accepts the route by finding all the policy terms of ARnext th at satisfy the following: 56 • packet-source-host is an element of PTHsrc (PTH src refers to the set of source hosts accepted by a given policy term) • packet-destination-host is an element of PTH dst • packet-ARdst is an element of PT(A R dst) • packet-ARsrc is an element of PT(ARsrc) • ARcur is an element of PT(A R ent) Create a list of all the policy terms found for each neighboring AR. 4. For each neighbor th at accepts a possible route from source to destination, add the neighbor and the applicable UCI, Cg and Cb to the policy route and compute a subroute from ARsrc to ARdst through ARcur and th at neighbor. The subroutes are computed by letting ARcur be set to the accepting neighbor and repeating steps 2, 3, and 4 until the destination is reached. The navigation algorithm was initially defined in our formal description notation (FDN). We then implemented a prototype of the algorithm in Prolog, in keeping with our methodology. At the heart of the algorithm is the com putation of sub-paths. T hat is, for each neighbor of the current hop in a given path, we must determine if there is a sub-path through that neighbor to the destination. To accomplish the subroute com putation, the algorithm createPrH d finds all the possible routes from one source host to one destination host. The algorithm finds all the term s for a given neighbor AR th at accepts a route from the source to the destination. From the list of accepting term s, and the neighbors, the sub-route com putation then determines the rest of th at path from the source AR and the neighbor of the current AR to the destination. For each neighbor that is accepted by one of the policy term s that perm its a path from source to destination, subRoute finds all the sub-routes from th at AR th at accepts packets from the source routes to the destination. subRoute recurses on the list of AR term s and neighbors until all sub-routes are found. Thus we have a depth-first construction of the policy route table. Excerpts of the navigation prototype are expressed here in Prolog. The complete prolog program, and the formal description of the algorithm, can be found in the appendix. 57 The top level procedure is CreatePolicyRouteTable. It has as its inputs the AR for which the table is to be computed, the hosts in the source AR, the neighbors of the source AR, and the list of destination A R/H ost pairs. The CreatePolicy RouteTable recurses through the destination list and computes a complete policy route for each host in the source AR. CreatePolicyRouteTable uses CreateHPRTbl to compute the sub-lists of routes from a single host to a single destination; accept- ingPtList determines which, if any, of the policy term s belonging to an AR in a potential route will accept a packet from the designated source to the designated destination. Finally, createN extARlist returns the list of exit ARs specified in a set of policy terms. CreatePolicyRouteTable(A Rsrc,ARsrcHList, ARNeighbors, DstARhList, PRTbl) *1 compute a p o lic y ro u te t a b l e f o r a given AR and a * /, s p e c if i e d d e s ti n a ti o n l i s t I ’ /. in '/, ARsrc: s t r i n g , ARsrcHList, '/, ARNeighbors: l i s t (of s tr in g ) '/, Dst ARhList: l i s t (of p a irs ) '/, out '/, PRTbl: l i s t (of h o st p o lic y ro u te s ) * /. var '/. PktSrcH: s t r i n g , PRTblHead, PRTblTail: l i s t (of h o st '/, p o lic y ro u te s) ( ARsrcHlist \== [], head(ARsrcHList,PktSrcH ), createHPRTbl(ARsrc, PktSrcH, DstARhList, ARNeighbors, PRTblHead), ta il(A R s rc H L is t,A RTail), CreatePolicyRouteTable(ARsrc, ARTail, DstARhList, ARNeighbors, PRTblTail), PRTbl = [PRTblHead,PRTblTail] I t r u e , PRTbl = [ ] ) . 58 s u b R o u t e ( A R e n t , A R s r c , N e x tA R , P k t S r c H , P k t D s t H , P k tD s tA R , ARL i s t , A P T L , PR) '/, c o m p u te t h e s u b r o u t e s fr o m one s o u r c e h o s t t o one '/, d e s t i n a t i o n h o s t •/ . ’ /. i n '/, A R e n t , A R s r c , P k t S r c H ,P k t D s t H ,P k t D s t A R : s t r i n g '/, A R L i s t : l i s t ( o f A Rs) % o u t '/, PR: l i s t ( o f PRs) • / . */. v a r * / , A PTL: l i s t ( o f p o l i c y t e r m s ) */. P R H ead , P R T a i l , P R D o w n L in k: l i s t • / . ( APTL \ = = [ ] , ( N e x tA R \ = = P k tD s tA R , '/, n o t a t d e s t i n a t i o n , so l o o k fr o m N e x tA R t o */, d e s t i n a t i o n , i f n o n e f o u n d , t h e n s k ip t o n e x t AR g e t A R N e ig h b o r s ( N e x t A R , N e x t A R L is t ) , c r e a t e P R H e a d (N e x tA R , A R s r c , P k t S r c H , P k t D s t H , P k tD s tA R , N e x t A R L is t , P R d o w n L in k ), ( P R d o w n L in k \ = = [ ] , PRHead = [ [ A R e n t ] , P R d o w n L in k] I t r u e , PRHead = [ ] ) I t r u e , PRHead = [ N e x t A R ] ) , t a i l ( A R L i s t , A R L i s t T a i l ) , c r e a t e P R H e a d ( A R e n t , A R s r c , P k t S r c H , P k t D s t H , P k tD s tA R , A R L i s t T a i l , P R T a i l ) , PR = [P R H e a d ,P R T a il] I t r u e , t a i l ( A R L i s t , A R L i s t T a i l ) , c r e a t e P R H e a d ( A R e n t , A R s r c , P k t S r c H , P k t D s t H , P k tD s tA R , A R L i s t T a i l , P R ) ) . T o use th e n a v ig a to r several d a ta files m u st be set up. T h e in fo rm a tio n fo r these files is d ra w n fro m th e illu s tra tio n of th e system . (E v e n tu a lly , th e illu s tra tio n w ill be th e o n ly in p u t to th e n a v ig a to r.) F o r each A R in th e system , create a file of 59 neighbors of the AR, ARneighbors, and a file containing the list of policy terms ARterms. Then run the navigator for each AR with its desired list of destinations. A partial list of the data files for the Research Internet are: A n e ig h b o r s = { B , C , D } B n e ig h b o r s = { A , C , D } C n e ig h b o r s - { A } Aterms = { [(* , {F,Re,U,Co} ,{F,Re» , O , {F,Re,U,Co>, { F ,R e» , { r e s e a r c h , s u p p o r t } , { u n a u t h e n t i c a t e d . U C I , n o - p e r - p k t - c h a r g e } ] To compute all the paths from A to all hosts in S, the input data would be: A R s rc = A A R s r c L i s t = { A x ,U s e r _ S v c s ,E x p t _ S v c s } A R n e ig h b o rs = { B , C , D } D s t A R h L is t = { ( S , S x ) } 6.5 A p p lica tio n o f th e N a v ig a to r to th e research in tern et ex a m p le We have used the annotated illustration from the previous section as input to the prototype navigator just described to simulate the connectivity th at results from the collective policy terms of the ARs in our fabricated Research Internet. Note that the annotated graph is an essential part of the system description. Because policy term s often apply to more than a single external organization (e.g. policy terms th at apply to a group of external organizations such as F,Re) the current topology of the system determines the actual connections th at can be made. In this section we describe the results. The particular example is small in size, for the sake of exposition within the confines of this dissertation. However, the navigation sim ulation approach in general, and the algorithm in particular, are intended to function on internets with very large numbers of ARs; in fact, it is in large internets th at the need for formal representation and autom ated tools is most evident. 60 Below are the policy route tables for a subset of the ARs. Each line in the PR table lists the destination followed by a colon and then the policy route and qualifiers. Because the prototype is an implementation of an algorithm expressed in a formal notation, the actual output format is cumbersome for hum an readers. Specifically, a policy table is represented as a linked m ultilist. The sequence of ARs traversed is embedded in the list of terms th at describe a given route. Also, there is no compaction of resultant UCI and Cg requirements. For the sake of readability, we have chosen to represent the policy tables in this chapter in a condensed form. The PR tables are used as follows. When a host requests a route to some destination, th at host’s AR consults its P R tables to select an appropriate PR. The destination AR is used as an index into the table. A particular PR can be used if there is a m atch between the source User Class Identifier and the UCI in the PR. The conditions (the set of Cgs) m ust also apply. ARsrc is known since in Clark’s scheme the source AR is the one to select the PR. In other words, a P R is only included in the PR table if it accepts this AR as the source AR. ARent and ARexit do not need to be checked at route selection; as with ARsrc, they were checked during the chaining process th at went into the creation and checking of the policy route table. In summary, ARdst in the index into the policy route table, and each entry includes the ordered list of ARs in the route and the lists of required UCI’s and conditions. We have included three of the policy route tables generated for our example internet: the tables for A, S, and Q. P o l i c y R o u te T a b l e f o r AR A B: [B ] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - u c i , n o - p e r - p k t - c h a r g e } [B ] { } { u n a u t h e n t i c a t e d - u c i , n o - p e r - p k t - c h a r g e } C: [C ] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - U C I , n o - p e r - p k t - c h a r g e ( A ) , in c o m i n g - p k t s - m a r k e d ( C ) } D: [D ] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( A ) , n o - p e r - p k t - c h a r g e ( A ) , o u t r a g e o u s - p e r - b i t - c h a r g e ( D ) } 61 R: [B,R] {research} {unauthenticated-UCI(A,B),no-per-pkt-charge(A,B)} S: [ B ,S ] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( A , B ) , n o - p e r - p k t - c h a r g e ( A , B ) } [ D , E , S ] { s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( A ) , n o - p e r - p k t - c h a r g e ( A , E ) , o u t r a g e o u s - p e r - b i t - c h a r g e ( D ) } E : [ D , T , E ] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - U C I( A ) , n o - p e r - p k t - c h a r g e ( A , E ) , r e s o u r c e - a v a i l ( T ) , D - c h a r g e s - b a c k - t o - s r c ( T ) } T : [ D , T ] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( A ) , n o - p e r - p k t - c h a r g e ( A ) , o u t r a g e o u s - p e r - b i t - c h a r g e ( D ) , r e s o u r c e - a v a i l ( T ) , D - c h a r g e s - b a c k - t o - s r c ( T ) } [ D ,T ] { u n a u t h e n t i c a t e d - U C I ( A ) , n o - p e r - p k t - c h a r g e ( A ) , o u t r a g e o u s - p e r - b i t - c h a r g e ( D ) , r e s o u r c e - a v a i l ( T ) , D - c h a r g e s - b a c k - t o - s r c ( T ) } Q: [ D , T , E , Q ] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( A ) , n o - p e r - p k t - c h a r g e ( A , E ) , o u t r a g e o u s - p e r - b i t - c h a r g e ( D ) , r e s o u r c e - a v a i l a b l e ( T ) , D - c h a r g e s - b a c k - t o - s r c ( T ) } P o l i c y R o u te T a b l e f o r AR S B: [B] { r e s e a r c h , s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( B ) , n o - p e r - p k t - c h a r g e ( B ) } [ D ,A ,B ] { s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( A , B ) , n o - p e r - p k t - c h a r g e ( A , B ) , o u t r a g e o u s - p e r - b i t - c h a r g e ( D ) ] [ E , T , D , A , B ] { s u p p o r t } { u n a u t h e n t i c a t e d - U C I ( A , B ) , n o - p e r - p k t - c h a r g e ( A , B , E ) , o u t r a g e o u s - p e r - b i t - c h a r g e ( D ) , 62 re so u rc e -a v a ila b le (T ) , D -charges-back-to-src(T ) ] A: [B,Aj { research ,su p p o rt} {unauthent icated-UCI(A,B ),n o -p e r-p k t-c h a rg e (A, B)} [D,A] {support} {unauthenticated-U C I(A ),n o -p e r-p k t-c h a rg e (A ), outrageous-charge(D )} [E,T,D,A] {support} {unauthenticated-U C I(A ),n o -p er-p k t-ch a rg e(E ,A ), D -ch arg es-b ack -to -so u rce(T ),r e s o u r c e - a v a il( T ) , outrageous-charge(D )} D: [D] {support} {outrageous-charge(D)} [B,A,D] {support} {unauthenticated-U C I,no-per-pkt-charge(A ,B ), outrageous-charge(D )} [E,T,D] {support} { n o -p e r-p k t-c h a rg e (E ),r e s o u r c e - a v a il( T ) , D -c h a rg e s-b a c k -to -src (T ), outrageous-charge(D)} R: [B,R] {research} {unauthorized-U CI(B), no-per-pkt-charge(B )} [D,A,B,R] {} {} (This ro u te , and th e n ex t, w ill be elim in a te d with th e a p p lic a tio n of a Cg f i l t e r as S re q u ire s support only routed through D, and R w ill accept re s e a rc h only t r a f f i c . ) [E,T , D, A, B, R] {} {} T: [D,T] {support} {outrageous-charge(D ), re s o u r c e - a v a il( T ) , D -ch arg es-b ack -to -src(T )} [E,T] { research ,su p p o rt} { n o -p e r-p k t-c h a rg e (E ), re so u rc e -a v a il(T )} [B,A,D,T] {support} {unauthenticated-U CI(A ,B), no -p er-p k t-ch a rg e(A ,B ), outrageous-charge(D ), r e s o u r c e - a v a il( T ) , D -charge-back-to-src(T )] 63 E: [E] { rese a rc h ,su p p o rt} {no-per-pkt-charge(E )} [D,T,E] {support} {outrageous-charge(D ),r e s o u r c e - a v a il( T ) , D -c h a rg e s-b a c k -to -src (T ),no-per-pkt-charge(E )} [B,A,D,T,E] {support}{unauthenticated-U C I(A ,B ), n o -p er-p k t-ch a rg e(A ,B ,E ), o utrageous-charge(D ), r e s o u r c e - a v a il( T ) , D -ch arg es-b ack -to -src(T )} Q: [E,q] { research ,su p p o rt} {no-per-pkt-charge(E )} [D,T,E,Q] {support} { o u tra g e o u s -c h a rg e (D ),re s o u rc e -a v a il(T ), D -c h a rg e s -b a c k -to -s rc (T ), n o -p e r-p k t-c h a rg e (E )} [B,A,D,T,E,Q] {support}{unauthenticated-U C I(A ,B ), n o -p er-p k t-ch a rg e(A ,E ,B ), o u tra g e o u s-c h a rg e (D ),re s o u rc e -a v a il(T ), D -ch arges-back-to-src(T )} P o licy Route Table f o r AR Q E: [E] { re se a rc h ,su p p o rt} {no-per-pkt-charge(E )} [E] {} {no-per-pkt-charge(E )} S: [E,S] { research ,su p p o rt} {no-per-pkt-charge(E )} [E,T,D,S] {support} { n o -p e r-p k t-c h a rg e (E ),re s o u rc e -a v a il(T ), D -ch arg e s-b a c k -to -src (T ), outrageous-charge(D)} [E,T,D,A,B,S] {support} { n o -p e r-p k t-c h a rg e (E ), r e s o u r c e - a v a il( T ) , D -c h a rg e s -b a c k -to -s rc (T ), outrageous-charge(D ), unauthenticated-U C I(A , B)} T: [E,T] { research ,su p p o rt} { n o -p er-p k t-ch arg e (E ), re s o u rc e -a v a il(T )} D: [E,T,D] { research ,su p p o rt} { n o -p e r-p k t-c h a rg e (E ), 64 re s o u rc e -a v a il(T ),D -c h a rg e s -b a c k -to -s rc (T ), outrageous-charge(D )} A: [E,T,D,A] { r e s e a r c h , support} { n o -p er-p k t-ch arg e (E ,A ), re s o u rc e -a v a il(T ),D -c h a rg e s -b a c k -to -s rc (T ), o utrageous-charge(D ),unauthenticated-U CI(A )} B: [E,T,D,A,B] { r e s e a r c h , support} { n o -p er-p k t-ch arg e(E ,A ,B ), r e s o u r c e - a v a il( T ) 3D -c h a rg e s -b a c k -to -s rc (T )3 outrageous-charge(D ),unauthent icated-U CI(A , B)} From this example we observe several properties that we believe to be generally true. First, the logical connectivity that is achieved is generally much less than one would expect from observation of the physical connectivity. Second, some nodes are logically (in terms of num ber of hops in their allowed routes) farther apart than their physical connectivity would suggest. For example, regions Q and B must traverse five hops in the policy route between them, where as is term s of strict AR connectivity they are only three hops away. We also note th at, as is expected by the use of symmetrical policy term s, th at the policy routes generated for corresponding ARs are symmetrical. Note th at since S does not carry any transit traffic, Q is forced to route all of its traffic through D. Adding to Q ’s woes it the fact that all the charges T incurs by routing Q ’s traffic through D are reflected back to Q. Q and S may wish to strike an agreement whereby S will carry transit traffic for Q, as long as the traffic is for research or support. In exchange Q may agree to establish a grant to support S’s network research activities (this is an out-of-band arrangem ent). S will not charge for carrying Q ’s traffic, but S will mark all of Q ’s packets for accounting purposes. Now S m ust add a policy term to its set of PTs to perm it Q ’s traffic. The policy term m ust be carefully constructed not to add any undesired connectivity (i.e. it should not allow transit traffic other than Q ’s to cross S). S will want to run the navigator with its new PT to ensure th at the PT performs as expected. S will then publish the PT across the internet. This is an example of how the process of synthesizing policy route tables makes explicit the implications of each A R’s independently constructed policy term s. It is 65 difficult to fully understand the consequences of a P T a priori w ithout simulating how it interacts with the policy terms of other ARs in the internet. We have proposed navigation as a means of analyzing the combined effect of PTS and therefore as a support tool for an AR to use in its policy definition when connecting to an internet. W ith larger, more richly connected internets, it will be critical to have such a tool since the interaction of PTs will not be traceable visually or manually. To apply this tool it is essential th at all known ARs and their connections in the internet be accurately represented by boundaries and spanners. Otherwise, path could exist th at do not get accounted for in synthesizing the P R tables. This can lead to faulty analysis of resulting connectivity. Another way to view the specification of the navigation tools is as a guide for internet navigation mechanisms. In practice, the policy term information would be distributed (and periodically modified) among the connected ARs, each of which would want to run a navigation algorithm to synthesize their respective PR tables. For each packet destined for a remote AR, the P R table would be consulted and an appropriate PR selected. In other words, in the implemented system, navigation still needs to be performed, and would be performed in the background. The for mal design provides a means of increasing our assurance of the correctness of the algorithm. As a part of the process of increasing assurance, this specification could also be used to synthesize an im plem entation (given meaning preserving transfor m ations on the specification into an im plem entation language), or to formally verify the correctness of an implementation. 66 C h ap ter 7 V erification o f a P o licy R o u te P ro to co l A num ber of basic mechanisms are needed to achieve the interconnection of au tonomous Systems. Such mechanisms include policy servers, policy gateways, and protocols. Formal design notations are an im portant tool for the development of these mechanisms. In this chapter, we specify one such mechanism, a secure pol icy routing protocol, to dem onstrate the use of our design notation, FDN. In the discussion of the secure policy route protocol, we prove that a key property of the protocol, namely th at there is no unauthorized use of valid policy routes, holds. Finally, we assert an approach to proving properties about the interconnection of autonomous systems. Our approach to generating formal descriptions is based on the underlying phi losophy expressed by G uttag [GHW85] of separation of specification concerns. These are the specification of underlying data structures and the specification of program behaviors. The process for creating a formal description begins with defining, or at least identifying, the prim ary data structures underlying the program to be spec ified. Next, the prim ary behaviors are identified. Based on the identification of principal behaviors, new data structures may be identified and all the data struc tures can be refined. Next the behavior descriptions are refined; this may result in the definition of additional behaviors. The subsequent refinement of data structures and behaviors continues until there is a completely specified set of behaviors, i.e. an algorithm or program. The final p art of the process consists of stating and proving th at desired proper ties hold of the formal description. In particular, we are interested in showing th at the operations described in FDN satisfy certain invariants on the data structures. 67 Thus, a formal statem ent of the properties th at must hold of the d ata structures, or states, of the system must be given. We use general first order logic (FOL). It must be shown th at the behaviors specified in FDN alter the data structures only in ways th at produce new instances of the structures that satisfy the stated invariants. This last step may result in additional refinements of the behavior description. 7.1 Form al D escrip tio n o f a S ecure P o licy R o u te P ro to co l To achieve the interconnection of autonomous regions, protocols that support and enforce locally defined policies m ust be defined. Routes must be selected based on param eters such as security or integrity privileges if such policies are to be enforced. In this dissertation we have constrained our view to usage policies only. Thus internet designers are concerned with protocols that make decisions based on such param eters as type of service, cost, and m utual support, as well as the traditional metrics of connectivity and congestion. T hat is, a policy routing protocol is needed to support the complex web of policy param eters imposed by the interconnected autonomous regions. In chapter 6 we presented a brief discussion of Clark’s policy term notation for expressing usage policies. In th at chapter we mentioned th at policy term s could be used for routing control. This, then, is the essence of C lark’s policy routing protocol. C lark’s policy is summarized as follows. ARs wishing to communicate exchange policy terms describing transit and end traffic they will carry or accept, respectively. Each AR then synthesizes and m aintains a policy route table. W hen a host in one AR wishes to send a message to a host in another AR, the source AR selects a potential route from its policy route table and attem pts to set up the selected route. Upon successful set up completion, the source AR policy server returns the route handle to the source host. The source host then attaches the handle to each packet it transm its. The transit and destination hosts use the handle to retrieve the route information for that connection. The protocol relies on each AR in the system having communicated its policy (expressed in C lark’s policy term s) to the other ARs in the system. Each AR 68 then constructs a table of potential routes (i.e. sequences of ARs) based on its current set of policy terms. (The AR will use the navigation algorithm to construct the policy route table.) The protocol relies on the existence of a Policy Gateway (PG) and a Policy Server (PS). The policy server is responsible for m aintaining an A R’s local policy terms (PTs), distributing the A R’s PTs and creating the table of policy routes. The policy gateway is responsible for policy enforcement during communication. Given a consistent set of policy terms and routes, the protocol for sending a message is as follows. 1. A host requests from the PS a route to send a message to a given destination. 2. The policy server selects a potential route from the table of routes. 3. The source AR (ARsrc) initiates route set up by distributing to every AR in the selected route control information about the route. 4. Each AR in the route receives a control packet. It checks the information to determ ine if it still accepts the specified route. If so, the route control inform ation is stored in cache. If not, the control packet is dropped and no further action is taken. 5. A fter successful completion of route set up, ARsrc returns to the source host the handle for the route. 6. The host attaches the handle (source and destination host names) to each packet in the message and sends the packets. 7. Each AR in the route examines each incoming packet. If the AR has valid control information stored in cache for the incoming packet, the packet is for warded to the next hop in the policy route. Otherwise, the packet is dropped. Because the ARs using the protocol are interested in protecting their resources from abuse, it is im portant th at the protocol itself be resistant to hostile attacks and accidental misuse. In particular, the protocol should not contain flaws th at could be exploited to attack the resources of any AR using the protocol. The prim ary security concern in a policy routing protocol is the prevention of unauthorized use of valid policy routes. Estrin and Tsudik [ET91] consider several extensions to the protocol designed to prevent unauthorized use of valid PRs. These extensions are: 69 1. Signing of the control information distributed during route set up (step three above). This requires that a some sort of encryption key scheme be in place (Estrin and Tsudik consider both public and private key schemes). The source AR generates a session key and includes the session key in the control packet. The source AR then ’ ’signs” the control information. For each AR in the route, the source AR encrypts the control packet with the appropriate key for th at AR and sends the packet. 2. W hen route set up is complete, the source AR returns to the host the control packet and the session key (step 5 above). 3. The host signs each packet it sends out with an encrypted handle, where the handle is the pair consisting of the name of the source and destination hosts (step 6 above). 4. In the secure version of the protocol, each AR in the route m ust now verify not only that it contains a valid control packet in its cache, but also th at the packet is properly signed (step 7 above). If there is no control packet in cache, or if the packet is not properly signed (i.e. the AR cannot decrypt the handle, or the source and/or destination hosts specified in the encrypted handle do not m atch the A R’s control information) the packet is dropped. It is the secure policy route protocol th at we specify with our formal design notation. W hile functional correctness is always desirable and im portant, where the security of a mechanism is critical, the additional assurance afforded by formal methods is essential. The next sections present state diagrams of the m ajor transitions and a formal statem ent of the protocol expressed in FDN. 7.2 T h e S p ecification As a first step, we describe the state transitions of the m ajor functions in the pro tocol: route set up, packet forwarding and (host) request for route set up. 70 Route Request re c e iv e ro u te s e t up req u est no ro u te ro u te & A R list = n i l / / + + / I compute h o s t 's |L I c o n tro l pkt & I I r e t u r n to host] + ------------------------------- + + ------------------------------------------+ > |Check P o licy Route I /IT a b le f o r ro u te I / +--------------------------------+ L — 0 / \ / \ ro u te & \ A Rlist "= n i l \ + ------------------------------------------------------------+ I compute j t h c o n tro l packet I I f o r j t h AR in ro u te & send I I to j t h AR I + --------------------------------------------------------------- + 71 Route Set Up re c e iv e encrypted c o n tro l packet >+-------------------- + I check packet I /I s ig n a tu re I / +-------------------- + s ig n a tu re / | not v a l id / I v a lid s ig n a tu re / v / + -------------------------------------------- + / I decrypt packet & I / I check ro u te v a l i d i t y I + + < +------------------------------------------+ I r e j e c t I / +-------+ <-----------------------Q in v a lid / ro u te / v a lid ro u te L + + I add encrypted c o n tro l| I inform ation to cache I + + 72 Packet Forwarding re c e iv e msg packet +------------------------+ ) > I decrypt handle I +----------------------- + “member(handle,cache) v < 0 to Route Setup I I member(handle,cache) + --------------------------------------------------------------------------- + I get c o n tro l inform ation from cache I I decrypt c o n tro l inform ation I g et se ssio n key I decrypt encrypted packet sig n a tu re I v a l id a te s ig n a tu re + --------------------------------------------------------------------------- + I I r e j e c t | s ig n a tu re \ +------------+ “= handle \ s ig n a tu re = handle \ + -----------------------+ I send packet I + ----------------------- + 73 Host Message Transm ission re q u e s t ro u te 0------------------------------ >0-------------- \ re c e iv e ro u te | \ c o n tro l packet I \ communication I +------------------------------------------------ + denied / I form s ig n a tu re I / I append s ig n a tu re to header I / +--------------------------------------------- + / / L msg = n i l / ------------- — ».Q I r e j e c t I I +---------------+ | msg "= n i l v + ---------------------------------------------------+ I get next message packet I I append header I I tra n s m it packet I + ------------------------------------------------------+ We now define the prim ary data structures needed to achieve the protocol. The most critical of the data structures used is the cache th at each AR uses to store the route control information. We have defined the cache to be a table of elements, where an element has the structure of a pair. type t a b l e ( e l e m e n t ( d a ta l ,d a t a 2 ) ) s o r t s elem en t, t a b l e , d a t a l ,d a t a 2 o p e ra tio n s f i r s t : element -> d a ta l second: element -> data2 d a ta l data2 -> element new: -> ta b le i n s e r t : element t a b l e -> t a b l e d e l e te : element t a b l e -> t a b l e member: element t a b l e -> boolean empty: t a b l e -> boolean - ( - ) : t a b l e d a ta l -> data2 eq u atio n s d l : d a t a l , d2: d ata2 , e l ,e 2 : elem ent, t : t a b l e f i r s t ( < d l ,d2>) = dl seco n d (< d l, d2>) = d2 d elete(e,n ew ) = new "member(e,new) m e m b e r(e ,d e le te (e l,t) = (member(e,t) .and. " (e = e l)) m e m b e r ( e ,in s e r t( e l,t) = (e=el .o r. mem ber(e,t)) empty(new) " e m p t y ( i n s e r t ( e , t ) ) i n s e r t ( e , t ) = ( i f f i r s t ( e ) = dl then second(e) e l s e t ( d l ) ) new(dl) = n i l The actual instantiation of d a tal and data2 will be appropriate types th at reflect the structure of a packet handle (a pair of strings th at represent the names of the source and destination hosts) and the encrypted control information (a list of integers, where each integer is the encrypted numeric representation of a given control data item). 75 The complete description will require data types for policy term s, packets, mes sages, handles, and various identifiers. These can be found in the appendix. We now give an informal operational description of the relevant portions of the protocol, and formally define several properties that must hold of the specification. Operationally, the protocol is modeled in the environment of a collection of ARs communicating via mailboxes. Each AR consists of a collection of operations: route set up, cache update, and packet forwarding. To ”communicate” an AR uses the transm it packet operation to write a packet to another ARs mailbox. The receiving AR must then read the packet from its mailbox. Thus the only communication mechanism is store and forward; we do not consider the use of this protocol for real tim e communication. The complete im plem entation of a simulation of the protocol is discussed in C hapter Eight. The property we wish to assert for the function that updates a cache is that, for every AR th at receives an encrypted control packet (E C P J), then th at control packet is entered into the cache only in the case th at the control packet is valid, i.e. th at all packets in the cache are valid. Note th a t for a mechanism to preserve this invariant over the cache data structure, the mechanism must exhibit the behaviors of first checking the validity of the control information, and then only in the case where the information is valid updating the cache. Further, the cache should only be modified with exactly the information found in the valid control packet. If the control information is invalid, then there should be no change to the cache. Furtherm ore, only those valid packets th at are actually received should be entered in the cache. We also would like to assert that all valid control packets are inserted into the cache, however there are two problems with this assertion. First, it is overly restric tive in th at it is not necessary for every valid control packet th a t is received to be placed into the cache in order for the security property to be satisfied. In fact, the update function th at never alters the cache trivially satisfies the security property. Second, in most real-world implem entations, there will not be unlim ited cache stor age available. Thus, rather than preclude useful implem entations th at may not be able to store all valid packets that are received, we write a looser assertion. Thus, the property th at the description of the update cache operation must satisfy is stated in general FOL as: 76 F o r a ll ARid: ARidType (member(ECPJARid,CacheARid) -> (valid(decrypt(ECPJARid,KeyARid), ARid) .an d . receive(m ailboxA Rid, ECPJARid))) In this specification, receive is a two-place predicate th at returns the contents of the mailbox specified by the first argum ent in the second argum ent. The predicate valid (specified below) is true if the route control information satisfies the policy requirem ents of the AR indicated by ARid. valid operates on plaintext only, so the encrypted control packet m ust be decrypted using the key for ARARid as indicated by KeyARid, The predicate decrypt is defined to be the inverse of any appropriate encryption algorithm. Member is an operation on the data structure cache that returns true if the element is in the cache and false otherwise. The preceding invariant states th a t the cache is updated only with valid infor mation that has been received. The specification also asserts th at if the cache is updated, then the information must be valid. Operationally, we first check the va lidity of the control data and if the validity holds, we update the cache. If not, the cache remains unchanged by the receipt of an EC PJ. As noted, the specification of update cache depends on the predicate valid, specified as: F o r a ll ARsrc,ARcur,CPJ,PRTable (valid(CPJARsrc,ARcur) <-> E x is ts PT (member(PT,PRtablearcur) .and. CPJARsrc = [ARent,ARexit, Skey,H src,H dst, ARsrc, ARdst, conds] .and. PR = [A Rent,ARexit,Hsrc,H dst,ARsrc,ARdst, conds] .and. accepts(PT,PR ))) Recall th at policy term s (PT) has the form [(H srcSet, ARsrcSet, A RentSet), (H dstSet, ARdstSet, ARentSet) , conds)] where HsrcSet denotes the set of source hosts perm itted by the policy term , etc. The predicate accepts holds only if Hsrc is contained in HsrcSet, ARsrc is contained in ARsrcSet, and so forth. 77 The critical sub-operation of the packet forwarding operation is the function that ”sends” the packet to the next hop. Note that send is a ’ ’memoryless” function on ’ ’mailboxes.” Its correctness depends only on its current effect on a given mailbox and not on previous operation on that or any other mailbox. We wish to assert, then, that send must satisfy the property th at for any packet it sends, the control data for the packet is in the cache and th at the packet is signed with a valid signature. Note that the security of this operation is dependent on the assumption of an uncorrupted cache. The specification of the property the forward packet operation must satisfy is as follows: F o ra ll cu r, ARnext:ARidType E x ists s rc ,d s t,d a ta ,E C P J c u r,S k e y ,E s ig (send(mailboxARnext,pkt) -> (pkt = [< s rc ,d st,E s ig > ,d a ta ] .and. mem ber(<<src,dst>, ECPJcur>, cachecur) . an d . elem ent(skey,decrypt(E C P J,ARkeycur)) .and. < src ,d st> = decry p t(E sig ,S k ey )) In this specification, the predicate element is an operation on data structures of type list, element returns true if the session key Skey is in the list of information comprising the control packet and false otherwise. The specification of the forward packet property asserts that the predicate send holds only in the case th at the conditions validating the packet hold. Operationally, however, we will first check the validity of the packet, then send the packet if the checks hold. If the checks do not hold, there will not be any changes to any of the mailboxes in the system. Note th at an implementation of this specification that occasionally (or even always) does not send a valid packet still satisfies the security requirement. W hile it is not desirable to have a ’’lossy” packet forwarder, it is not a violation of the stated security property not to send valid packets; if there is no transmission of packets, then trivially there is no unauthorized use of a valid PR. These segments of the specification are w ritten in arbitrary first order logic. The next step of the specification process is to transform the general FOL into FDN, however, for the sake of brevity, we will omit this step here. The complete FDN specification is given in the appendix. 78 7.3 V erifying a S ecu rity P ro p erty There are a num ber of relevant properties one would like to prove about a secure policy routing protocol. Of these, we believe that dem onstrating th at there is no unauthorized use of valid policy routes is mandatory. This assertiona implies th at a message will be sent from source to destination only if there is a valid policy route and the source is authorized to use that policy route. T hat is, we need to show th at a valid P R can be used only by the hosts authorized to use th at PR, and that the packets sent by a host not authorized for th at route will not be forwarded. A valid P R is one th at is asserted by a legitim ate AR policy controller based on the policy term s the PC has received from the other ARs; policy controllers are trusted to create only those routes that are specified by the policy terms the PC has in its possession. We will dem onstrate th at the above property holds by showing th at no AR forwards a packet to the next AR in the P R unless (1) the current AR holds a policy term th at accepts the forwarding of packet to the next AR and (2) the encrypted signature of the packet matches the signature established for the current session and held in the current (forwarding) AR. (Note that there will be no session information in the case where the current AR does not accept the route, as discussed earlier. Thus, these two properties provide sufficient assurance th at there is no unauthorized use of valid policy routes.) This implies th at we must show for each AR in the route th at any received packet is forwarded only if the routing control information, i.e. th a t A R’s portion of the policy route, is valid and the signature of the packet is valid. We can show th at these properties hold since, for every ARj in the route, the routing control information for a packet is placed in A Rj’s cache only if the routing in the control packet is accepted by ARj for the specified source, destination, entry and exit ARs. Furtherm ore, the signature of both the packet and the control information are protected against forgery for as long as the keys are uncompromised and each AR in the route validates the signature of the packet against the encrypted signature in the cache. We now present the formal statem ent of the property that there is no unautho rized use of legitim ate policy routes. A uthorization is manifested as the presence of a policy route in the policy gateway’s cache, and legitimacy is manifested by the 79 presence of a policy term (or term s) that accepts the policy route. Thus, the formal statem ent of the policy is: F o r a ll ARsrc, ARcur, ARnext, p k t , PR ("(send(mailboxARnext,pkt) .and. "authorized(pkt,P R )) .and. (E x ists PT(member(PT,PRtableARcur) .and. acc epts(P T ,P R )))) The predicate authorized is defined as follows. F o r a ll p k t ,ARsrc,ARcur,PR,ARkeyARcur (a u th o r iz e d ( p k t,PR) <-> (pkt = [< s rc ,d s t> ,E s ig ,d a ta ] . a n d . member(<src,dst>,ECPJ>.cacheARcur) .and. CPJ = decrypt(ARkeyARcur,ECPJ) .and. CPJ = [ARent,ARexit, Skey,H src,H dst, ARsrc, ARdst, conds] .and. PR = [A Rent,ARexit,Hsrc,H dst,ARsrc,ARdst, conds] )) Together, these invariants assert th at no packet is sent to the next hop in a legitim ate route if the packet is not authorized to use th at route. Recall th at a policy route is distributed across the sequence of ARs making up the route. Thus the predicate accepts applies to th at portion of the route stored in the current AR, as denoted by ARcur. Note th at the restriction th at the route must be in the cache of the current AR prevents a host from by-passing route set up and using a PR saved from a previous authorized communication. A final comment on the specification of the invariants is th at they are somewhat stronger than they need to be to preclude unauthorized use of valid PRs. Together, these invariants also preclude attem pts to utilize invalid policy routes. This is a property that one would reasonably expect to hold of the protocol. Before proving th at the specification satisfies the security property, we first con sider what it means if the protocol violates the security property. In this case, one or more of the following would be true for the protocol: an AR would forward a packet for which there was no E C PJ in the A R’s cache; the EC PJ in cache corresponding to the packet was not valid; the signature of the packet did not m atch the signature 80 contained in the EC PJ for the packet. This implies th at we m ust show th at both (1) only valid control packets are in the cache and (2) the forward packet operation forwards the packet only if there is a control packet in the cache and the signature of the packet matches the signature found in the control information for the packet. The FDN description of the cache update behaviors is proc addPRtoCache(in ARid: s t r i n g , key: i n t e g e r ) :- - g e ts a c o n tro l packet from th e mailbox and, i f th e c o n tro l -in fo rm a tio n i s v a l id , updates th e cache var Handle: p a i r , ECPJ, CPJ: l i s t [I receive(boxARid,ECPJ) .and. decrypt(EC PJ,key,CPJ) .and. i f valid(C P J) then [ Igetsource(C PJ,H src) .and. getDest(CPJ,Hdst) .and. Handle = <Hsrc,Hdst> . a n d . updateCache(CacheARid, <Handle, ECPJ>) I] I] The FDN description of the forward packet behaviors is 81 proc fw dPkt(in ARid: s t r i n g , ARkey: i n t e g e r ) :- - - a packet i s e x tra c te d from th e mailbox of th e c u rre n t AR. - - i f th e AR accepts th e packet ro u te , then th e AR sends th e —packet to th e next hop in th e ro u te . var pk t: l i s t , box: d a ta , IPheader: l i s t , Handle: p a i r Skey: in te g e r , ECPJ, CPJ: l i s t , s r c , d s t: s t r i n g [ | — re c e iv e g ets th e c u rre n t item in th e mailbox receive(boxA Rid,pkt) .and. h ead(pkt,IP header) .and. f i r s t ( I P h e a d e r , src) .and. second(IP header,dst) .and. handle = < src,d st> . an d . getECPJ(cacheARid,Handle, ECPJ) . a n d . i f ECPJ <> n i l then [ I decrypt(ECPJ,ARkey,CPJ) .and g etsessionkey(C P J, Skey) .and. th ird (IP h e a d e r,E sig ) .and. d ecrypt(E sig,S key,S ig) . a n d . i f s ig = handle then [ |getNextAR(CPJ,NextAR) .and. send(boxARid,pkt) —accounting fu n c tio n s , i f any I] I] □ . T hat these descriptions satisfy the specified properties is im m ediate from the spec ifications. To show th at the desired security property holds for a particular systems of ARs implementing the specified operations, first note that the policy route is distributed across the caches of the ARs in the route. Thus, proving th at the algorithm holds for the initial (originating) AR and then showing that if the specification holds for the nth AR in the route, it must hold for the n + ls t AR in the route is sufficient to show inductively that the specification holds for routes of arbitrary lengths. 82 7.4 D iscu ssio n The question ’ ’how do we assert th at certain properties hold of interconnected, autonomous regions” must be addressed. W hile this is a difficult question, and no universally satisfactory answer (if the current history of formal m ethods is any guide) may be found, we felt it was im portant to at least present an approach that we feel is a viable option for increasing assurance that desired properties do hold of a given interconnection of systems. The basic approach is this. First, formally define the behaviors of a mechanism, such as a secure policy route protocol and formally state the properties these be haviors must satisfy. (Note th at at some level, every mechanism, or collection of operations, can be viewed as an atomic operation. Thus the top level view of an interconnection of ARs is as a collection of operations. T hat is, there are ’ ’system- level” behaviors such as policy servers and protocols. It is at this level th a t we wish to state and prove properties. So, we need to show, somehow, th at the prop erties hold of the operations of the system.) Next, prove that the desired property holds of the mechanism. Finally, since every im plem entation in the interconnection is required to satisfy the specification, then inductively we argue that the desired properties hold across the entire interconnection. The addition of new elements does not require reproof th at the system satisfies the desired properties, only dem onstra tion th at the region entering the interconnection implements the mechanism in a way th at satisfies the mechanism’s specification. This strongly requires th at the specification language used to describe mech anisms must support technological heterogeneity since the systems in any given interconnection will be non-uniform in their underlying technologies, and all im plem entations of the same mechanism must (provably) satisfy the same properties. This is perhaps the strongest motivation for basing the FDN on the Larch approach to specification. We believe th at this is a worthwhile approach to proving properties of intercon nected autonomous regions for several reasons. First, because the topology of this class of systems is dynamic, the ability to prove th at properties hold of these systems should not be tied to any given configuration. Any approach th at ties the proof of a property to a specific configuration of a system is probably not well-suited to this 83 class of system s-it would be a considerable burden to be forced to reprove the entire system each tim e a change in the topology is desired. It is much more efficient if we can simply prove the property once, then assert that every new region added to an interconnection must exhibit the specified behavior for th at mechanism. O ther approaches to proving properties of communicating systems [?, ?, Goown] rely on m aintaining and reasoning about histories of systems states or events. We feel th at this approach has several significant disadvantages. First, this approach requires the use of ”meta-variables” for storing and pointing to elements in the history. It is somewhat unsatisfying to reason about properties of the system using entities outside the system. For systems on the scale of interconnected autonomous regions, the burden of m anipulating such histories would be phenom enal and, if the histories were to be implemented, the storage and associated overhead would be phenomenal. Finally, as would be expected, the histories approach adds additional complexity to the specification and verification process. 84 C h ap ter 8 S im u latin g Form al D escrip tio n s This chapter discusses the combination of a system topographical representation with the formal description of the system operations to achieve the simulation of a particular ”im plem entation” (or instantiation) of a system. Introduction-W hy are we interested in simulation? Simulation is a easy way to provide a ”Proof-of-Concept” ; satisfies need to dem onstrate th at the ’’right” func tions have been designed for the mechanisms before the expense of implementation. In a security conscience environment, penetration testing plays an im portant role in the development process. Simulation provides an early opportunity to perform some prelim inary penetration testing. Simulation is also used for performance modeling. The simulation of the secure policy route protocol. Results of Simulating the Secure Policy Route Protocol The process: Currently, we hand draw the particular instantiation of the topol ogy, translate the description to prolog, then construct the script. Need to talk about the script, and how to construct it. then run the simulation with the script. Short summary of the protocol, refer to specification in chapter 7. Discuss overview of the prolog code. Example excerpts of the code, complete program is in appendix. Describe script used. Sample Topology and Policies-an ” Execution” of the protocol Discussion of the output 85 R eferen ce List [AE88] S. Anderson and D. Estrin. Representing and analyzing usage policies for interconnected autonomous networks. Technical Report TR-88-55, University of Southern California, Computer Science D epartm ent, Los Angeles, CA 90089, 1988. [Cla90] D. D. Clark. Policy routing in internetworks. Internetworking Research and Experience, 1(1):35— 52, September 1990. [EM85] H. Ehrig and B. Mahr. Fundamentals of Algebraic Specification I. Springer Verlag, Berlin, 1985. [Est91] D. Estrin. Policy requirem ents for inter adm inistrative domain routing. Computer Networks and ISDN Systems, 1991. [ET91] D. Estrin and G. Tsudik. Secure control of transit internetwork traffic. Computer Networks and ISDN Systems, 1991. [GHW85] J. G uttag, J. Horning, and J. Wing. Larch in Five Easy Pieces. Digital Equipm ent Corporation, 1985. [Goown] Don Good. Unknown. Technical report, University of Texas, Austin, Unknown. NEED MORE INFORMATION!!! [Llo84] J. W. Lloyd. Foundations of Logic Programming. Springer Verlag, 1984. [Pos81] Jon Postel. Internet protocol. RFC 791, DARPA, anonymous ftp from nic.ddn.m il, September 1981. [SH89] J. Scheid and S. Holtsberg. Ina jo specification language reference m an ual. Technical report, Unisys, Culver City, Ca., 1989. 86 [Unkwn] Unknown. Unknown. Technical report, Unknown, Unknown. NEED M ORE INFORMATION!!! 87
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
PDF
00001.tif
Asset Metadata
Core Title
00001.tif
Tag
OAI-PMH Harvest
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-oUC11255819
Unique identifier
UC11255819
Legacy Identifier
DP22858